New 3CX SBC for V15 Vs V14 SBC (Session Border Controller)

The 3CX Session Border Controller in V15 includes major audio improvements.Want to connect one or more small remote offices to the main HQ? Wanna do this at minimum cost without bridging to another PBX? Reduce network overhead, and encrypting voice traffic in the process?

3CX is offering a new update of its popular SBC, this time for Windows and this version seems to have spent a good amount of time pumping heavy iron at the gym because the new features and improvements are awesome!!

Let’s have an inner look at SBC15 improvements one by one. And we will compare each improvement with how it used to work in the SBC14.

Multi Threading

V14 SBC was single threaded. This means that internally only 1 task can be done at a time and the SBC had to wait for that task to finish before it can start another task. Now V15 is multi threaded. This means that you can have multiple threads in parallel which results in significant performance gains. As a result V15 SBC can support more calls, more phones behind the SBC, makes better use of the network and works faster and better. Packet loss is reduced, RTP packets coming with a wrong timestamp obliterated.

Before 3CX V14 was supporting up to 5 phones and struggled if those phones had BLFs configured. Also you could reliably pass approximately 10 simultaneous calls.

V14 V15
Number of Sim Calls 10 100
Number of Extensions 5 50
Number of BLF laps 25 (5 BLFs on each phone) 250 (5 BLFs on each phone)

V15 raises the bar by supporting 50 phones behind the SBC. Each extension can have BLFs now and we have successfully made tests of 100 simultaneous calls via SBC.

Network Considerations

The number of simultaneous calls also depends on the network bandwidth you have between your remote office and your HQ. Below is a table which you can use to calculate how many simultaneous calls you can handle to maintain good audio quality assuming the network is used only for SBC and VoIP Calls.

No. of calls PCMU G729 GSM G722
1 69.6 Kb/s 17.52 Kb/s 21.68 Kb/s 71.2 Kb/s
10 696 Kb/s 175 Kb/s 218 Kb/s 712 Kb/s
50 3480 Kb/s
3.48 Mb/s
876 Kb/s
0.9 Mb/s
1084 Kb/s
1.08 Mb/s
3560 Kb/s
3.6 Mb/s
100 6960 Kb/s
6.96 Mb/s
1752 Kb/s
1.75 Mb/s
2168 Kb/s
2.17 Mb/s
7120 Kb/s
7.12 Mb/s

*above amounts include overhead. Results taken from an actual bulk test.

**1 extension with 5 BLF lamps configured will consume approximately 50Kb/s.

Audio Improvement

Audio has been improved drastically. There were 2 elements that contributed to this improvement.

When we introduced multi-threading, shortly after we questioned ourselves. “Why not use a separate high priority thread to pass Audio?. That’s what we did, and the Audio was not being processed sequentially anymore. This fired up the quality and improved packet flow. Since RTP is controlled by a separate thread, automatically we reduced the number of dropped packets.

However the quality was still jittery at times. This was a result of using TCP and due to our network algorithms which waited for TCP chunks to be filled up with data before sending them out, the Audio remained jittery. But we had encountered this problem before – in the PBX Tunnel. So we solved this problem in the same way – Audio passes in UDP like this it inherits the speed advantages of UDP which are natural for Audio delivery and eliminate the checking features that the TCP Protocol comes with.

The below is a chart taken with 5 phones on v14 and v15.

Number of phones = 5 SBC14 SBC15
Called max RFC3550 jitter (ms) 51.25 13.45
Called mean RFC3550 jitter (ms) 27.52 2.63
Called max delta (ms) 415.37 126.88

Conclusion: Jitter reduced by 60%

Max RFC3550 jitter: Max value of RTP stream jitter per call and calculated according to RFC3550 standard like in wireshark. Indicates unstable delays in media flow. A bad value would be something greater or equal to 40ms. V15 SBC reduces this by 78.58 % and brings the value down to a mere 13.45ms.

Mean RFC3550 jitter: Mean value of RTP stream jitter per call and calculated according to RFC3550 standard like in wireshark. If the value is above 20ms you will have unstable delays in the media flow. We have brought this down from 27.52 to 2.63!!

The Max delta is the time between consecutive RTP Packets. Large values (above 150ms) indicate overload in IP network and CPU. We can see that the final result is a whopping 288ms bringing the Called delta from a staggering 415 to an awesome 126.88ms!!!

This is how a call looked like in V14 SBC:

3CX Session Border Controller V14

Note that jitter starts at 6ms and as time goes by, it goes up to 24 and spikes up to 38.02.

This is how a call looks with SBC15:

3CX Session Border Controller V15

You can immediately notice that the jitter starts at 1-2 ms, goes up to 12 and fluctuates between 15 and 18ms.

Conclusion: Audio is music to the ears!!

Liked this article?

Get notified of new articles
or share
You might also be interested in:
  1. Charles

    Hey Nicky

    Is it possible to use v15 SBC with a v14 3CX instance?

    July 21, 2016 at 3:57 pm
    • Yes you can – but you will gain very little. The SBC cannot do miracles on it’s own. It needs intelligence also from the server. Now the v14 does not have the additions we put in V15 so with your approach, you will be putting new wheels on the car, but the engine is the same as before. You will see improvement yes, but not the massive improvement spoken about in this post.

      July 21, 2016 at 4:15 pm
  2. and what if one has 10 BLF keys? Most clients have 10 BLFkeys per phone.

    What is ETA for v15 for Android SBC?

    July 22, 2016 at 9:58 am
    • Yes you can – use simple proportion. Check the codec you using, and calculate to see if you have bandwidth for the number of phones you have with 10 blf’s each. The problem of the blf’s was bandwidth related. RPI SBC will come later – no eta for now.

      July 22, 2016 at 10:54 am
  3. Pingback: 3CX Session Border Controller (SBC) v15 offers MORE – Mear Technology Blog

  4. If the remote place has an PSTN Gateway, when some remote extension from this place use the gateway the audio will stay local?

    August 4, 2016 at 6:17 pm
    • @Calouro Good question! Yes the audio will remain inside the network of the SBC. Audio goes to the pbx when you have recording enabled OR if the option “PBX Delivers Audio” is checked on at least one of the participants of the call. Ensure you test this properly because we do not test nor support PSTN gateways configured remotely from the pbx. What model is the PSTN gateway under question?

      August 4, 2016 at 10:03 pm
  5. @Nicky,

    I am trying to test it but I receive the following error:

    “ERR | 20160804-163246.382 | 3CXTunnel | TUNL | 24356 | TunnelTcp.cpp:155 | Failed to resolved DNS SRV record for tunnel connection to ***”

    *** is my FQDN.

    My ISP provider block ping requests, may that be the cause? But, I can resolve IP from FQDN without problem, Android extensions can use tunnel without problem.

    My Gateway is Grandstream GXW4104.

    You can see some info here on my trying to keep gateway audio local:

    Thanks for care.

    August 4, 2016 at 10:40 pm
    • Its ok – That error simply means that you do not have DNS SRV records. Example _sip._tcp.FQDN
      Without SRV records the tunnel will still work. It just needs to resolve the fqdn (A record.

      August 4, 2016 at 11:05 pm
  6. @Nicky,

    I tested it right now, and the audio still go to 3CX Server and return back to extension, this time over SBC tunnel.

    I can provide access to my network anytime (since I am a home user) if you want to check this and make your product better.


    August 4, 2016 at 11:36 pm
    • @Calauro not all gateways work the same way. I asked you for the model and you did not reply. IF the gateway does not work like the IP Phones, then it will not proxy the audio locally. In any case, you are saving enough bandwidth by keeping the audio locally on the phones. It’s ok if audio goes up and down for PSTN Calls. PSTN Gateways are NOT SUPPORTED in remote locations. We do not need to check why the audio is not passing from the SBC for a PSTN gateway because it is not a supported configuration. Deeper manual configurations are required for this to work.

      August 5, 2016 at 4:25 pm
  7. @Nicky

    I see.

    I told you before, its a Grandstream GXW4104.

    The gateway and another two ATAs are on another house connected by VPN to another house where is located the 3CX Server, another gateway and one more ATA.

    On the link of the forum there are more details too.

    Thanks anymway.

    August 5, 2016 at 5:14 pm
  8. Matt

    Where can we download 3CX SBC v15? I have looked in the partner area, website, etc and it is always the v14 download. I am really wanting tof test the new v15, if I could ever find the download. Thanks!

    August 12, 2016 at 6:13 pm
  9. Mike

    What is the recommended hardware for an SBC for a 10 person office? 25 person? 100 person?


    August 17, 2016 at 2:12 am
    • Charalambos Eleftheriou

      @Mike, The spec of a machine for the Windows SBC should be the same spec as a machine that is configured for 3CX Phone system for the size of the simultaneous call license. But if you have a site with 100 extensions then you should consider installing a 3CX Phone system on this site and bridging your systems together, as you would need a few SBC machines to cope with this.

      August 18, 2016 at 3:18 pm
  10. andy

    Where is the new SBC version 15? I spent 20 minutes trying to find it before caller support who emailed me the link. It would be nice if marketing would keep the downloads page up to date.


    August 26, 2016 at 8:31 pm
    • andy

      I now see the link in this blog. It should be on the download page where we call go and look for the downloads. :)


      August 26, 2016 at 8:36 pm
  11. Terry

    So existing was only 5? Wow that was a well kept secret that would have been nice to know!

    September 20, 2016 at 11:50 pm
  12. Hello,

    is it possible to set up multiple instances of the SBC on the same machine but running with different settings/ports?

    We need this on order to connect multiple, autonomous, hosted 3CX systems to a single site.


    September 27, 2016 at 12:49 pm
    • You can but it is not supported. Our installation creates one instance and registers 1 service.
      However you can install on a machine, get the files, and do the same thing our installation does manually.
      Copy the files in a folder, Register the service and tell it to load configuration from the config file. And then edit the config file to make sure that you do not have multiple sbc services conflicting on the same source port.
      There will be 1 side effect – You will loose PNP Provisioning like this because for PNP to work, the SBC needs to listen on port 5060.

      September 27, 2016 at 5:28 pm
  13. Bora

    Hi, instead of SBC, can you VPN tunnel between two sites with 100 extension?

    October 19, 2016 at 3:51 am
    • Yes of course – You can use VPN.. That makes these extensions all local..

      October 19, 2016 at 10:08 am