Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

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

Discussion in '3CX Phone System - General' started by floppyraid, Jul 20, 2017.

Thread Status:
Not open for further replies.
  1. floppyraid

    Joined:
    Jul 20, 2017
    Messages:
    4
    Likes Received:
    0
    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:

    ---

    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):

    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!
     
  2. AlexDBarrett

    Joined:
    Jan 25, 2011
    Messages:
    71
    Likes Received:
    9
    We have found the SBC to be unreliable, to the point it has lost us clients.
    Go for a VPN if possible or STUN.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #3 DSXDATA, Jul 21, 2017
    Last edited: Jul 21, 2017
    LyonAdmiral likes this.
  4. accentlogic

    accentlogic New Member

    Joined:
    Nov 14, 2013
    Messages:
    181
    Likes Received:
    77
    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.
     
  5. floppyraid

    Joined:
    Jul 20, 2017
    Messages:
    4
    Likes Received:
    0
    +1 for reading comprehension. Thanks.
     
  6. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    And by the way, FloppyRaid? Really? That is as useful as Static RAM ;)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #6 DSXDATA, Jul 21, 2017
    Last edited: Jul 22, 2017
  7. OCWI

    OCWI New Member

    Joined:
    Jan 17, 2017
    Messages:
    161
    Likes Received:
    46
    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?
     
  8. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.