SBC Error log and dropped calls

[edokim]

I keep seeing the following error on the SBC log. The errors are reported all the time, only the ip and port numbers change.

ERR | 20171223-095747.448 | 3CXTunnel | TUNL | 8364 | Rtp.cpp:143 | Error reading from RTP socket 584, {RS:58680}: error 10054
ERR | 20171223-095747.541 | 3CXTunnel | TUNL | 7504 | Bridge.cpp:712 | Has no registered RTP session for local destination 192.168.1.162:30638
​

We have the PBX on Google Cloud, and this SBC on a dedicated windows pc. Is this related to dropped calls?

Thanks in advance for the feedback.

 

[eddv123]

Hi edokim,

See this forum post:
https://www.3cx.com/community/threads/3cx-tunnel-session-border-controller.49855/#post-202570

It certainly covers the "Error reading from RTP socket " message you are seeing for the "has not registered RTP session for local connection" please try:

* Change FQDN to Public IP in the configuration file.
* Turn off Windows Firewall on 3CX server (if using Windows based 3CX System)
* Re-install SBC software and don't use encryption
* uncomment the localSipAddr

Also what version of the 3CX SBC software are you running ? I did see a forum post that explained that an upgrade of the software shifted some of these issues.

 

[edokim]

Hi eddv123,

Based on previous research, I had already adopted your four suggestions. With regard to your linked post, the OP seems to have resolved the issue through the update to the SBC. We have the latest version, 3CXSBC15.5.7503.

The PBX on the Google Cloud, and the SBC is running on a dedicated windows pc.

Other people have suggested not using the SBC and simply going with a Microtik router. Your thoughts?

 

[eddv123]

Hi Edokim,

If you are talking about direct STUN I would only ever recommend RPS/STUN/Direct SIP for a single home user - that being said this method still does not give you the security you would get from an SBC as it is a direct SIP extension.

The 3CX SBC is a far better option as it includes features such as added security and Encryption of traffic, the 3CX tunnel (tunnels all traffic over port 5090), plug and play provisioning of phones and no need for "PBX deliveres audio.

What I mean by this is that all traffic is passed back to the PBX and then back out again (with the SBC traffic is passed locally). This is why direct SIP extensions often experience issue with call transfer, and latency.

 

[sip.bg]

Hi Edokim,

If you are talking about direct STUN I would only ever recommend RPS/STUN/Direct SIP for a single home user - that being said this method still does not give you the security you would get from an SBC as it is a direct SIP extension.

The 3CX SBC is a far better option as it includes features such as added security and Encryption of traffic, the 3CX tunnel (tunnels all traffic over port 5090), plug and play provisioning of phones and no need for "PBX deliveres audio.

What I mean by this is that all traffic is passed back to the PBX and then back out again (with the SBC traffic is passed locally). This is why direct SIP extensions often experience issue with call transfer, and latency.

I'm not sure 3CX SBC adds encryption of the traffic -- such feature is not documented anywhere.
It looks only traffic been encapsulated into single port, may be more similar to IAX from Asterisk world.
Security may be achieved on some phones using TLS for SIP traffic and SRTP for audio on the basis of SSL certificate. The other option is to use IPsec site-to-site VPN.

 

[eddv123]

I'm not sure 3CX SBC adds encryption of the traffic -- such feature is not documented anywhere.

You are specifically asked to enable/disable encryption on installation of the SBC!!

And read:
https://www.3cx.com/docs/3cx-tunnel-session-border-controller/

"Enable Encryption to add an extra layer of security by encrypting all calls passing through the 3CX SBC"

https://www.3cx.com/blog/news/3cx-sbc-notification/

Point 2: "Encryption can be turned on"

 

[edokim]

Thanks for the feedback. We have about 12 phones at the remote site, and are currently using an SBC. We keep getting the errors on the SBC logs, though, and some dropped calls (not many, but enough to be an issue). I am not even 100% sure if these two are related, actually.

@eddv123, the bandwidth advantage you mention with keeping internal calls local to the LAN is definitely a big plus for the SBC, as bandwidth at the site is an issue. But having a dedicated machine and the current troubleshooting it entails are minuses.

@sip.bg, is keeping the traffic local for internal calls possible with a Microtik and no SBC? We currently have a Zyxel USG50 as a firewall, and I suspect the errors from the SBC are being caused by an incorrect configuration. I have been researching Microtiks and there seems to be an active and helpful community. I am considering with a MT for QoS and a friendlier firewall UI (through WinBox).

Encryption for this case is secondary to functionality and practicality of the implementation.

 

[sip.bg]

Thanks for the feedback. We have about 12 phones at the remote site, and are currently using an SBC. We keep getting the errors on the SBC logs, though, and some dropped calls (not many, but enough to be an issue). I am not even 100% sure if these two are related, actually.

@sip.bg, is keeping the traffic local for internal calls possible with a Microtik and no SBC? We currently have a Zyxel USG50 as a firewall, and I suspect the errors from the SBC are being caused by an incorrect configuration. I have been researching Microtiks and there seems to be an active and helpful community. I am considering with a MT for QoS and a friendlier firewall UI (through WinBox).

Encryption for this case is secondary to functionality and practicality of the implementation.

With Mikrotiks you can achieve either layer 2 connectivity, i.e. the same as LAN, with the help of EoIP tunnels, so the PBX sees all phones appearing as new local ones, before assigning them to extensions, exactly the same as operation in LAN, including common DHCP server, etc.

Also you can have layer 3 connectivity, i.e. standard VPN, based on PPTP, L2TP, SSTP, OpenVPN or GRE tunnels. Then you need static routing between LAN segments without NAT and probably DHCP server with Option 66 for remote sites.

All tunnels -- layer 2 or 3 can use IPsec encryption -- recommended. You need at least one of the sites to have static public IP address, presumably the central one -- of the PBX.

MikroTik routers at remote sites can be placed also behind other existing routers or provider modems, into local network of such router and build again a VPN tunnel. Then you use the MikroTik router as gateway for the IP phones or add static route to PBX via MikroTik for 3CX softphones in Windows PCs. This network topology resembles much the one used with 3CX SBC, but MikroTIk router builds a site-to-site VPN to central site with PBX.

 

[edokim]

@sip.bg, I will do more research based on your feedback regarding the connectivity. I am still not clear on whether or not the internal traffic can be kept locally without an SBC. Our PBX on the GCP, and one of the remote sites has bandwidth issues, so this is important.

 

[sip.bg]

With MikroTiks and possibly with other routers too (Cisco, etc., but on much higher price), you can achieve whatever network configuration you want -- Layer 2 connectivity, i.e. equivalent to LAN for remote sites, Layer 3 connectivity without NAT, i.e. VPN -- probably most easy to implement and trivial NAT with STUN for remote sites.
Layer 2 and Layer 3 without NAT means you provision phones as part of your local network of the PBX and you don't need SBC. This also means local traffic will not leave the local network segment you use. I personally don't recommend using SBCs, if you can use routers you want in your sites.

 

[eddv123]

the bandwidth advantage you mention with keeping internal calls local to the LAN is definitely a big plus for the SBC, as bandwidth at the site is an issue. But having a dedicated machine and the current troubleshooting it entails are minuses.

Hi edokim,

I would agree that most people do consider having a device used to run the SBC at the remote site as a disadvantage, mostly as it offers another point of failure. That being said I think the PRO's in favor of the SBC far outweigh the Con's.

If Bandwidth is a concern then the SBC would be the way to go. You can use this helpful 3CX bandwidth calculation to workout how much is being taken up:
https://www.3cx.com/blog/docs/bandwidth-utilised-for-voip/

 

[edokim]

Thanks for the feedback. Any ideas on what may be causing the errors above? Seems that with every call the same flavor of errors get generated. Reviewed and tinkered with the firewall settings, but no joy. On the plus side, no dropped calls last week. Maybe they are not related?