Provisioning and updates - issues with new router

[InSite TJW]

We have a 3CX PBX in 'the cloud', a session border controller (SBC) running on a Linux Virtual Machine on-site, a large number of Fanvil X3G IP phones and four Yealink CP920 conference phones. We recently moved to new premises - before the move everything seemed to be working. Now we seem to be unable to provision the CP920s so have been forced to use the standard X3G phones in the conference rooms as a temporary measure. We have recently taken delivery of a new batch of X3G phones with the factory firmware version 2.4.0.5487 and I am unable to provision these too. If I manually upgrade the firmware on the new X3Gs using the phone's web interface and new firmware downloaded from 3CX I can provision them, but in the old building I was able to provision a batch of factory-firmware phones then update the firmware in a batch using the 3CX management console. That batch upgrade saved a fair bit of time last time a firmware update was released, but I missed three phones which are still on (3CX-branded) 2.10.0.6586; if I select these and request the firmware update from the Management Console they reboot but don't install the update - in the old building that would have worked.

The only big change in our environment is the router, in the old place internet access was provided as part of the office lease. We now have a router ordered through the ISP. I therefore suspect there is a router configuration issue but I have no idea what or how to go about identifying what needs to be changed. The only other change we have made is the network address used by the phone system (it was 10.80.22.0 255.255.255.0, the subnet mask is unchanged but the addresses start with 172).

Please help us work out why we are having these issues.

 

[Lee Cramman]

Apologies for leaving this hanging for a few days - I haven't had time to be online.

The methods of deploying SBC's have changed in the last few weeks with the most recent updates. The current 3CX instructions refer to a bang up-to-date install which has confused a few people not on the most recent version.

You can manually edit the config file for your SBC but I've found unexplained issues when I've done it that way in the past so my personal rule is to redeploy the SBC. If you don't want to re-install then you could try uninstalling 3cxsbc, renaming the config file and then re-installing.

 

[InSite TJW]

Apologies for leaving this hanging for a few days - I haven't had time to be online.

Not to worry, I'm the same sometimes. Thanks for coming back to assist now that you have time.

The methods of deploying SBC's have changed in the last few weeks with the most recent updates. The current 3CX instructions refer to a bang up-to-date install which has confused a few people not on the most recent version.

That explains it; thanks. Our PBX has now updated and the 'Add SBC' button has appeared, but our existing SBC (that still appears to be working, since people are still making calls) is not listed. Is that normal and if I try to install a second SBC using the new method do I risk killing the current setup?

You can manually edit the config file for your SBC but I've found unexplained issues when I've done it that way in the past so my personal rule is to redeploy the SBC. If you don't want to re-install then you could try uninstalling 3cxsbc, renaming the config file and then re-installing.

By 'redeploy' do you mean reinstalling Linux as well as the SBC software? I can do that for the new SBC if that's what you recommend, it's just a bit of a pain to get a static IP as the Linux installer tries to use DHCP. The important thing is keeping the old SBC and the deployed phones running until I can migrate to the new private subnet.

 

[Lee Cramman]

Yes, that's what I meant. I don't know if it's officially recommended, I've just found it more reliable that way (it probably speaks more of my lack of vi skills than anything else...).

Your old SBC should be listed (although ours required a reboot of the SBC box before it would list properly). It will be functioning as a 'legacy' SBC and upgrading it is as simple as ticking it and clicking 'push config' on the SIP trunks page. Your phones will lose connectivity while services restart. Other than the very brief outage caused by the reboot / services restarting it was completely painless for us. The new SBC shouldn't interfere with the old one as long as it doesn't try and occupy the same IP address.

The deployment method for a new SBC is very much simplified / streamlined. Basically, before you configure your SBC you just add the details for the new SBC under SIP trunks. Then when you install the new SBC you just need to tell it your FQDN and authentication key ID. It should come online and be visible under SIP trunks in a few seconds.

It's been a while since I've installed a new SBC (which speaks volumes about their reliability) but I thought you had the chance of setting a static IP at install? If not you could make a DHCP reservation before the install starts, you could interrupt the 3cxsbc initial config process, manually change the IP and then start the config again or you could switch switch to another terminal window before completing the initial config, change the IP and then switch back to the config screen.

 

[InSite TJW]

Your old SBC should be listed (although ours required a reboot of the SBC box before it would list properly). It will be functioning as a 'legacy' SBC and upgrading it is as simple as ticking it and clicking 'push config' on the SIP trunks page. Your phones will lose connectivity while services restart. Other than the very brief outage caused by the reboot / services restarting it was completely painless for us.

Thanks, I'll try rebooting the legacy SBC when I get the chance (probably Friday when most of the people using the phones go home early) and hopefully it'll then appear on the management console.

The new SBC shouldn't interfere with the old one as long as it doesn't try and occupy the same IP address.

The new SBC will be on a different VLAN and subnet so the private IPs won't conflict. Due to NAT they'll presumably have the same public IP though. I can shut one down at a time so they're not running at once but does the PBX allow two different SBC entries with the same public IP? I just want to make sure the new one works before killing the old one.

It's been a while since I've installed a new SBC (which speaks volumes about their reliability) but I thought you had the chance of setting a static IP at install? If not you could make a DHCP reservation before the install starts, you could interrupt the 3cxsbc initial config process, manually change the IP and then start the config again or you could switch switch to another terminal window before completing the initial config, change the IP and then switch back to the config screen.

It's the Linux (debian 9) installer that tries to auto-configure the network using DHCP. When it tries to do that I have to hit the 'Cancel' button to be given the option to configure the network manually. It's a little awkward that's all, hence I was wondering whether I could get away with just reinstalling 3cxsbc.

 

[Lee Cramman]

The new SBC will be on a different VLAN and subnet so the private IPs won't conflict. Due to NAT they'll presumably have the same public IP though. I can shut one down at a time so they're not running at once but does the PBX allow two different SBC entries with the same public IP? I just want to make sure the new one works before killing the old one.

AFAIK you can run multiple SBC's behind a single public IP without issue - https://www.3cx.com/community/threads/multiple-sbcs-behind-internet-connection.52494/

 

[InSite TJW]

AFAIK you can run multiple SBC's behind a single public IP without issue - https://www.3cx.com/community/threads/multiple-sbcs-behind-internet-connection.52494/

Thanks. I'm now running two SBCs without any new issues. The old one still doesn't show up on the SIP Trunks page, but the new one does. It doesn't seem to matter which SBC I use though, the provisioning problems are the same on both. Since I've now installed a second SBC, I think that rules out the change of IP (without reinstall) on the old one as the cause.

 

[ashahrukh]

Thanks