SBC advance configuration documentation?

[dandenson]

(PBX is hosted on GCE)

I've got a site that has some occasional network connectivity issues, ie a few dropped packets every now and then. I have a raspberry pi SBC installed which has helped a lot, but...

before SBC, some phones wouldn't ring because they lost connectivity. Some would
after SBC, overall calls are more reliable but when there is an issue, NO PHONES RING

I believe this can be traced down to the SBC tunnel needing to reconnect.
In the SBC config file I see:
ReconnectInterval = 30

Is this safe to change? I don't have an issue with bandwidth utilization so can this safely be moved down to 5 seconds?

Additionally, I have the option to put in a Peplink router with WanSmoothing which provide a resilient tunnel on-net for the PBX. Would changing the SBC to point to the LAN address by updating TunnelAddr to the LAN address be appropriate?

Thanks.

 

[cobaltit]

I've never changed any settings in the SBC but I would imagine they are all safe to change unless otherwise documented (such as the logging level). I don't see why you couldn't change that although it may not do anything. I'd first confirm if when inbound calls fail that waiting 30 seconds and then retrying the call actually works. Otherwise changing it may not produce the desired result.

No idea what WanSmoothing is since I'm part of the Peplink marketing team but I can't imagine it's going to accomplish anything. The basic issue is you are dealing with UDP traffic so the only real fix (other than getting a better internet connection) would be to do SIP over TCP.

 

[dandenson]

yes, waiting some seconds does resolve the issue. I am monitoring the site's connectivity and I see a latency spike and then calls wont go through. Really need some sort of BFD like keep alive on the tunnel.

WanSmoothing creates a tunnel using 2 or more internet connections and duplicates the packets on each. If a packet is lost on the primary link, it just uses the backup link's copy so no packets get lost ever.

And I would love to be doing SIP over TCP, but the Yealink templates don't support that and I'm trying to avoid using custom templates if at all possible considering the unsupported nature of do it.

 

[eddv123]

I would agree, I too have known issues with the Raspberry Pi variant where it goes into a sort of lock-out mode and a simple restart of the services enables calls to go through again.

It would be useful to know if you are hitting anywhere near the 20 extension mark on this SBC, if I recall however some of these sites were no where near the max number of extensions or BLF's.

You can log from the pi, this can be done in the 3cxsbc.conf which can be found if you navigate to: C:\ProgramData\3CXSBC\3cxsbc.conf

Change the DEBUG to VERBOSE then run the below commands:

1) Edit file /etc/3cxsbc.config and uncomment the # File section.
2) Stop the 3cxsbc service (service 3cxsbc stop)
3) Stop the rsyslog service (service rsyslog stop)
4) Delete file ls -l /var/log/ (rm /var/log/3cxsbc.log)
5) Recreate /var/log/3cxsbc.log (touch /var/log/3cxsbc.log)
6) Start the rsyslog service (service rsyslog start)
7) Start the 3cxsbc service (service 3cxsbc start

You can tail -f the logs so that it saves to a txt file - your SD card should be fine to support his.

 

[cobaltit]

@dandenson

Ok I figured it was something Peplink proprietary but wouldn't that require a Peplink at both ends (as well as two internet connections). If you are on GCE I don't see how you could setup that WanSmoothing feature.

 

[dandenson]

eddv123, I'm running v15.5 of the sbc, systemd based and the configs are a bit different.

I have 10 phones and 13 extensions counting the smartphone APPS

I changed the reconnect interval to 5 and now I see 'Keep-Alive received' every 5 seconds, before it was 30. The SBC says it's sending a keep alive about once per second.

Change it to 3 and I'm getting them in 3 seconds.

So there has been some change here.

I'll leave it at 5 and see if that improves things.

 

[dandenson]

cobaltit, running Peplink's fusionhub in a GCE instance. The GCE instances have private LAN between them. The peplink units (BR1 for example) have LTE connectivity for the second link.

This is how I'm running ATA's right now since they don't support the SBC, configuring them as LAN because the LAN IP of the PBX is reachable through the peplink tunnel.

I'm running some phones this way as well, but I want the SBC to keep the audio local.

 

[dandenson]

I feel like I'm really working around the SIP over TCP template issue here. The request for this from many users has fallen on deaf ears though.

 

[cobaltit]

No, you're really working around a poor internet connection. If the drops aren't in the last mile moving the GCE instance to another region might help.

You can also provision the phones, web into them and switch from UDP to TCP and then remove the provisioning URL to confirm that SIP over TCP is going to actually solve the issue before bemoaning lack of SIP over TCP in the template. Just because the vocal minority have requested it doesn't make it that important. I don't have a single install using SIP over TCP nor do I have a use case for it. I do look forward to SIP over TLS which is definitely something very important in today's world although though the catch is most SIP trunking providers (myself included) are probably farther off from offering TLS than 3CX is.

 

[dandenson]

it's not google's connectivity, it's the docsis node or neighborhood the customer is in. I have other customers as close to across the street without these problems.

graph below is the site in question (red) and the jitter (shaded red) and other sites nearby. The blue one is across the street and down 1 block. The other 3 are just a few blocks away. It's this specific site.

And yes, while this is primarily a connectivity issue, TCP erases that issue.

Any alteration of the phone's config outside of the template becomes a maintenance issue down the road and more manual interventions. TCP is a standard option even within 3CX, it's just not in the templates for one specific brand for no known reason.

Keeping the SBC session alive is next on the list. if it takes a leisurely 30 seconds to reconnect then that's a pretty big window for a customer complaint. Seems that changing this to 5 seconds has worked as I have no call issues since I made the change.

Ultimately I'll probably have to experiment with connecting the SBC across a resilient tunnel.

 

[cobaltit]

TCP is a standard option even within 3CX, it's just not in the templates for one specific brand for no known reason.

Which template in 3CX has TCP support? Yes 3CX does support it, but I don't know of any PBX or even hosted service that TCP is the default (unless TLS is). The only times I see TCP brought up is when someone has an underlying network issue, a firewall issue, or some unsupported phone with a wonky SIP stack. It's definitely low on the list in the big picture of things 3CX needs to do or should have done. So it's there if you need it but it's not common enough that they are going to bake it in. Heck even templates are still in their relative infancy for 3CX!

If you are smart enough to have diagnosed the network condition and to setup your Peplink VM etc, then custom templates shouldn't scare you. It's the folks that can't spell VoIP and then try to do all sorts of custom stuff that shouldn't touch templates. So clone the template, make the one line change to TCP (and Opus since you seem to be fond of that as well) and call it a day. Next time 3CX updates the templates, compare the settings and update your custom template till 3CX supports both TCP(TLS) and OPUS and then you are all set!

 

[dandenson]

"It's definitely low on the list in the big picture of things 3CX needs to do"
In your opinion. I frequently chat with a few people that are not using 3CX because of a short list of reasons with this being a substantial part of. Maybe you aren't aware, but SIP/TCP is actually more used these days since Microsoft and Verizon use it exclusively with zero support for SIP/UDP. By the numbers, we are in the minority with SIP/UDP. Also, it's a single variable in a template and a single option in a UI to add, so pretty low development overhead.

"The only times I see TCP brought up is when someone has an underlying network issue, a firewall issue, or some unsupported phone with a wonky SIP stack"
It's like you're on my side here. TCP solves annoyances and issues with common network and internet problems that are very often out of the phone admin's control. I can't control jitter on the provider's network, I can't control a small amount of packet loss that is enough to mess with SIP/UDP. That doesn't disqualify a site from having VoIP service when there are standard, well supported solutions available that need a single line in a config to use and instantly solves these problems with no negative side effects.

I'm not afraid of custom templates, I'm using them now. I don't like custom templates because any issue whatsoever will cause the custom template to be blamed and the entire issue unsupportable. Then when 3CX updates a template the custom template needs to be revisited adding maintenance overhead.

If I wanted maintenance overhead I'd be using FreePBX.

 

[cobaltit]

In your opinion. I frequently chat with a few people that are not using 3CX because of a short list of reasons with this being a substantial part of. Maybe you aren't aware, but SIP/TCP is actually more used these days since Microsoft and Verizon use it exclusively with zero support for SIP/UDP. By the numbers, we are in the minority with SIP/UDP. Also, it's a single variable in a template and a single option in a UI to add, so pretty low development overhead.

So I saw it's a low on the list and you come back with 'I talk a few people'. Few means not many. You can look in the ideas forum and I'd be surprised if SIP/TCP was in the top 50 requests sorted by popularity. And pointing to a proprietary platform which is using TLS and not just TCP and their target is enterprises which require it for security isn't really proving anything. Also I'm not sure who you are lumping into a minority. MS and Verizon vs 3CX? Most every hosted PBX provider or SIP standard PBX offering (FreePBX, etc) either only support SIP/UDP or default to SIP/UDP. And even though the change in the template and the UI is minor, you seem to have forgot the testing step. And you'll probably say at this point that MS and Verizon use the very same Yealink phones which is true. However they also use specific firmware which they have tested. 3CX is working with the lowest common denominator here which is SIP/UDP. They've supported SIP/TCP for a while now but it seems the next official ready for the masses option is going to be SIP/TLS bypassing the significantly less requested and less used SIP/TCP.

It's like you're on my side here. TCP solves annoyances and issues with common network and internet problems that are very often out of the phone admin's control. I can't control jitter on the provider's network, I can't control a small amount of packet loss that is enough to mess with SIP/UDP. That doesn't disqualify a site from having VoIP service when there are standard, well supported solutions available that need a single line in a config to use and instantly solves these problems with no negative side effects.

I've never disagreed with you that SIP/TCP can solve certain issues. But SIP/TCP isn't going to stop packets from dropping. It will help your signaling information get through in your specific case but your still going to have audio issues from the RTP dropping so you're still going to get complaints. And jitter really isn't an issue for the SIP side so much as the RTP side which is still UDP.

I'm not afraid of custom templates, I'm using them now. I don't like custom templates because any issue whatsoever will cause the custom template to be blamed and the entire issue unsupportable. Then when 3CX updates a template the custom template needs to be revisited adding maintenance overhead.

You can't have your cake and eat it to. Either SIP/TCP is rock solid and ready to go or it isn't. Whether you make a custom template or 3CX releases a template the changes are the same and the results will be the same. So either it hasn't been tested and that's why they haven't enabled it, or it has been tested and found faulty so they haven't enabled it, or as far as 3CX is concerned, it just isn't worth the time and effort to introduce it in the mix when SIP/TLS is in testing/development. The point you've spent more time bemoaning the lack of one-click SIP/TCP than it would have taken making the change in the custom template, especially considering you clearly already have experience making custom templates. And the administrative overhead is really minimal, especially if you are billing for it .

If I wanted maintenance overhead I'd be using FreePBX.

And yet here you are using 3CX so clearly the pros outweigh the cons

The takeaway here is that you are barking up the wrong tree as you have seen with your comment regarding certain feature requests falling on deaf ears. 3CX has a roadmap that only they know and for the most part they do what they want to do regardless of what has been requested. Folks clamored for years to have more flexibility with phone provisioning and then once that feature arrived there was probably 2x the posts complaining that this feature or that knob, etc wasn't available in the provisioning page. You can't please all the people all the time and 3CX does a pretty good job for the market it targets.

Anyways, we're just nitpicking talking points and spouting opinion. I agree with you that it would be great if 3CX supported more things and I've been equally frustrated and lost opportunities because it doesn't. I've never lost an opportunity due to lack of SIP/TCP and while I'd probably be clamoring for it right with you 2-3 years ago, it's wasted effort now. I think your energies are better served putting the screws to Comcast or whoever the cable provider is verse complaining about the lack of SIP/TCP here. Best of luck resolving the issue however you are able to do it. Happy Holidays and keep fighting the good fight!