3cx SBC for Debian - question about 'ID' field in 3cxsbc.conf

[floppyraid]

Greetings all,

If you know the answer to this, skip everything below: How is the "ID" field used in the 3cxsbc.conf? Is there any plan in the future for this field to behave differently than it currently does? Also any other good tidbits/nuances regarding performance/limitations/potential problems running multiple Debian SBCs would be very appreciated.

My versions are:

root@sbc:/# apt list |grep 3cx
3cxpbx/custom 15.0.61335.0 amd64
3cxsbc/custom,now 1.0.61335 amd64 [installed]
root@sbc:/# uname -a
Linux sbc 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux

---

I'm trying to mitigate potential problems using w10 for SBCs by migrating all of them to Debian.

I've got 2 SBC's up and running fine on the same network (1 Debian SBC for testing and our actual production 3cxSBC on a Windows VM) but I was curious about this ID field.

Earlier during setup I modified /etc/3cxsbc.conf on our debian box so that the ID wouldn't be identical to the default one in our 3cxsbc.conf on our Windows SBC (by default it is 123456). The tunnel between the SBC and the 3cx server would not establish, it had these errors (the fqdn and ip have been sanitized):

INFO | 20170720-115352.467 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/Dns.cpp:123 | [DNS] Resolved host name a.very.valid.fqdn to [123.456.789.000]
NOTICE | 20170720-115352.467 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:235 | Making TCP connection to [ V4 123.456.789.000:5090 TCP ]
NOTICE | 20170720-115353.468 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:757 | Sending keep-alive. Stats: KA sent: 1, KA recv: 0
DEBUG | 20170720-115353.556 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/security.cpp:1072 | Ready to send, send q size = 1
NOTICE | 20170720-115353.556 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:609 | Tunnel connection to [ V4 123.456.789.000:5090 TCP ] is accepted
ALERT | 20170720-115353.556 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:660 | Sending first packet from [ V4 0.0.0.0:51592 UNKNOWN_TRANSPORT ] to [ V4 123.456.789.000:5090 TCP ]
INFO | 20170720-115353.630 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/security.cpp:1300 | Keep-alive received
WARNING | 20170720-115353.714 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:631 | Tunnel connection to [ V4 123.456.789.000:5090 TCP ] is disconnected; error: Connection is terminated by peer - while begin to read a packet from tunnel
ERR | 20170720-115353.714 | 3CXTunnel | TUNL | 139768861243200 | /home/repomaster/root15/Sources/Projects/3CXSBC/TunnelTcp.cpp:262 | Bridge [3CX Session Border Controller] failure 'Connection is terminated by peer - while begin to read a packet from tunnel' on TCP connection: TunnelTcp:rocess

If I set it back to the default ( ID=123456 ) the tunnel establishes and everything works fine. What is this field and how is it used?

Thanks!

 

[AlexDBarrett]

We have found the SBC to be unreliable, to the point it has lost us clients.
Go for a VPN if possible or STUN.

 

[DSXVOICE]

And on the other hand, Raspberry PI / Debian SBC's can be like toasters - we have several hundred deployed.

It's an engineering choice.

--------------------------------------------------------------------------
About VPNs

VPN's are a safe choice, but in a large multi-site deployment they can expose you to security issues if they aren't properly filtered. We use pfSense with good results. Generally our rule is a site with less than 20 workstations is SBC-based. We also consult the client's engineering staff and let them make the choice when they have a strong preference. Enterprise shops get nervous about VPN's into their networks.

--------------------------------------------------------------------------
About NAT/STUN

Just recently NAT/STUN deployments have become more practical due to uCSTA. Using uCSTA, Remote commands to re provision and reboot the phone come via SIP formatted messages. The old method required a local connection between PBX and phone. Consequently, you can now do these things via a NAT connection. If you are deploying Yealink S series phones and can deploy a known good VOIP router, STUN is worth considering.

Just carefully validate the router in use: The problem is that most routers choke at some point handling the RTP connections - so you wil. begin to get one-way audio complaints after anywhere from 3-20 simultaneous calls in progress. The fun part is that some routers use a roll-over table, so when the session table overflows it will use the first table spot - the result is that the media for the new call gets connected using the RTP connections for a call in progress and people end up making new friends unexpectedly

Don't gamble on this - it's an unreported issue with many routers.

The only two routers we consider known good for NAT are DrayTec and SimpleWAN.

-------------------------------------------------------------------------
About SBC deployment

There are two fields commented out of the CONF file that make it look like the settings are not necessary - don't be fooled - they are.

LocalSipAddr = 192.168.1.115 # local SIP (UDP/TCP) address (def: 0.0.0.0)
LocalSipPort = 5060

Set the values to local IP & SIP Port.

Make this setting on the PI to prevent startup issues

• sudo raspi-config
• select: Wait for network at boot and then: Slow wait for network connection before completing boot
• click ok, finish and restart the Raspberry Pi

Take a look at "Monit." It installs on the PI and will report on everything down to the temperature of the bathtub.

Once you get a PI working perfectly you can just copy the SD card to make clones.

Also use a thing called "HTOP" to watch the SBC performance. PI's have a bad reputation because the earlier SBC software was single threaded and the prior version PI CPU's were not exactly made to have a tow-hitch attached. But the V3 PI has quad cores and the V15+ SBC software uses 3 of the four cores.

------------------------------------------------------------------------------
On SBC Hardware

If you have everything current, a Raspberry PI 3 can handle anything less than 30 phones unless you have a boatload of BLF's on the phones (it's the signalling for the BLF's that burden the SBC.) So above 20 phones look at Debian SBC's like the Intel NUC. A NUC can handle 50+ phones with one hand behind its back.


Best,

Kirk

 

[accentlogic]

We have been running the Debian SBC since they were released, and have found them very reliable. We do add third party monitoring to each SBC so that we are alerted if they go offline, but so far it has always been an ISP or local network issue.

I noticed the SBC ID as well, and also found changes break it. I do have an enhancement request in Ideas to make the SBC an object so that phones will associate with an SBC using the current IP address of the SBC, rather than manually entering it on each phone. See https://www.3cx.com/community/threa...-controllers-sbc-an-object.47583/#post-192007

Using a VPN is great, if that is an option. For clients hosting their own that is normally what we do. But if we are cloud hosting for the client it does not scale well.

We considered using STUN, but according to 3CX we are supposed to open ports 14nnn on the remote firewall to each phone. That just isn't possible in same cases, and does not scale well. Not to mention potential security issues. To be honest, we have done some testing using STUN with no firewall rules, and have never noticed an issue - but not willing to use it in production if it's not supported.

https://www.3cx.com/blog/docs/provisioning-a-remote-extension/

Notes when using Remote Extension with STUN:

1. Please make sure that your Remote Location has Static NAT implemented as well to the phones and that the SIP port and RTP port range for each phone as specified in Extension Settings >> Provisioning tab is correctly forwarded to the IP address of each phone
2. If you have multiple IP Phones on the same remote network configured with the same SIP and RTP ports, you might have an audio problem caused by the way certain routers implement NAT. In this scenario, each phone must have a different SIP Port and a range of RTP ports must be configured per phone. To do this, click on the Provisioning tab, change the SIP and RTP ports and perform a re-provision of each phone from the Phones node.

 

[floppyraid]

I noticed the SBC ID as well, and also found changes break it. I do have an enhancement request in Ideas to make the SBC an object so that phones will associate with an SBC using the current IP address of the SBC, rather than manually entering it on each phone. See https://www.3cx.com/community/threa...-controllers-sbc-an-object.47583/#post-192007

+1 for reading comprehension. Thanks.

 

[DSXVOICE]

And by the way, FloppyRaid? Really? That is as useful as Static RAM

 

[OCWI]

To DSX's point the Pi's are EXTREMELY reliable. Especially when compared to their windows counter part.

Network boot setting is critical. Offsite access is handy should you need to make a change. We have been using dataplicity to monitor and access our pi's. It works well. We have similarly lost clients over the windows SBC reliability. The Pi was a good switch for us.

We have so far NOT found it necessary to un comment the local sip addr and ip. DSX, is this still relevant to do or no? We have alot of deployments at this point problem free without doing that step?

 

[DSXVOICE]

The pain comes when the SBC reboots. There are times when - for whatever reason - the lack of those settings results in the SBC not starting the tunnel.