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.
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.
|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.
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|
*above amounts include overhead. Results taken from an actual bulk test.
**1 extension with 5 BLF lamps configured will consume approximately 50Kb/s.
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:
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:
You can immediately notice that the jitter starts at 1-2 ms, goes up to 12 and fluctuates between 15 and 18ms.