SBC for v18: Always Connected

[JLSeagull]

As of yet this cannot be done via 3CX, not for the 3CX SBC host at least.

Do bear in mind that, should you wish to upgrade the 3CX SBC Host OS from Debian 9 to Debian 10 and keep the configuration supported, you would have to redeploy using the corresponding ISO depending on whether you're running the 3CX SBC on a Raspberry pi or on x86 architecture.

• If x86-Based, you would have to use the 3CX ISO for Debian 10. This cannot be done yet as the 3CX SBC is not included in the current Beta/Alpha ISO's. It will be added to the 3CX ISO once the stable build of v18 is officially released.

• If ARM-Based(Raspberry Pi), you would have to redeploy using this guide which also contains the ISO: https://www.3cx.com/docs/installing-pbx-raspberry-pi/

Thank you very much, @ChrisC_3CX !!!

 

[Ruymar Castro]

Hello @Nick Galea , reading your article I had a question, does the SBC in the V18 version not work on the RTP connection? And another question, in case of internet connection loss and loss of communication with the 3CX in the cloud, do I still try to communicate between the endpoinds behind the SBC? And finally, can we hope that one day the 3CX SBC will contemplate survival?

 

[NickD_3CX]

Hello @Nick Galea , reading your article I had a question, does the SBC in the V18 version not work on the RTP connection? And another question, in case of internet connection loss and loss of communication with the 3CX in the cloud, do I still try to communicate between the endpoinds behind the SBC?

Hi! I think I may be able to answer your questions. The SBC communicates with the 3CX Server over a single port using TCP and UDP (default 5090). The TCP is a TLS 1.2 connection. All SIP and RTP packets received by the SBC and encapsulated and sent over the TCP/UDP channel that has been established, but if you are monitoring the traffic on a network level, they will not appear as RTP packets nor will you be able to decode them, as they are encapsulated and encrypted.

In regards to if Endpoints that are configured behind an SBC can still make calls between themselves even if the SBC connection is dropped, the answer is no.
The SBC acts as a proxy of sorts, but it must have a connection to the Server in order to initiate calls. To be specific, all SIP messages are always sent to the Server in order to establish a call.
RTP packets though between IP Phones behind the same SBC are sent directly between the endpoints, saving considerable bandwidth (except in cases where Recordings are enabled).

Also the SBC helps overcome NAT/Port Forwarding issue in networks where you may not have a lot of control or don't want to go through the pains of settings up IP Phones as Remote STUN.

And finally, can we hope that one day the 3CX SBC will contemplate survival?

I apologize, I didn't quite understand this question, but on top of everything, the SBC can also be configured in in a HA Cluster, for those that view the SBC as a "single point of failure":
https://www.3cx.com/docs/sbc-high-availability-cluster/

 

[Ruymar Castro]

Hi! I think I may be able to answer your questions. The SBC communicates with the 3CX Server over a single port using TCP and UDP (default 5090). The TCP is a TLS 1.2 connection. All SIP and RTP packets received by the SBC and encapsulated and sent over the TCP/UDP channel that has been established, but if you are monitoring the traffic on a network level, they will not appear as RTP packets nor will you be able to decode them, as they are encapsulated and encrypted.

In regards to if Endpoints that are configured behind an SBC can still make calls between themselves even if the SBC connection is dropped, the answer is no.
The SBC acts as a proxy of sorts, but it must have a connection to the Server in order to initiate calls. To be specific, all SIP messages are always sent to the Server in order to establish a call.
RTP packets though between IP Phones behind the same SBC are sent directly between the endpoints, saving considerable bandwidth (except in cases where Recordings are enabled).

Also the SBC helps overcome NAT/Port Forwarding issue in networks where you may not have a lot of control or don't want to go through the pains of settings up IP Phones as Remote STUN.


I apologize, I didn't quite understand this question, but on top of everything, the SBC can also be configured in in a HA Cluster, for those that view the SBC as a "single point of failure":
https://www.3cx.com/docs/sbc-high-availability-cluster/

@NickD_3CX,
Thank you very much for the information and knowledge shared.

As for the question you didn't understand, I was referring to the 3CX SBC in case of communication failure with the cloud PBX to allow communication between the endpoints behind the SBC to which it is registered.

 

[NickD_3CX]

As for the question you didn't understand, I was referring to the 3CX SBC in case of communication failure with the cloud PBX to allow communication between the endpoints behind the SBC to which it is registered.

With an SBC that isn't possible, as I explained the SBC requires a connection to the 3CX Server in order for IP Phones behind it to initiate calls.
If you want to have this, then you should consider installing a "small" 3CX Server on-premise instead of an SBC, then Bridge the on-prem Server with the Cloud 3CX Server.

This would require a 2nd license key, but would achieve what you want.