Support required - Handsets and Desktop Apps stopped working but Mobile App ok

Status
Not open for further replies.

Rickster

Customer
Joined
Jan 3, 2021
Messages
6
Reaction score
1
Hi, I'm looking for some support on solving our current 3CX issue. We are an affiliate level partner and 3CX is a small part of our business. We have used 3CX for nearly 10 years now without many issues. Our instance is hosted at IONOS along with a dozen customers running similiar 3CX instances . None of our customers have any issues and the only change we've made lately was to upgrade to v18 (which we've done across the board to all our customers instances). The situation is that none of the desk phones in the office or at home work properly i.e they don't ring and you can't hear audio if you try to make a call. However, we've found that the mobile phone 3CX App appears to work fine (using office wifi) so we're getting by with that for now. The firewall check on the 3CX system passes just fine. With 3CX being a small part of our business and it rarely ever going wrong we don't tend to keep up with the skills required to delve into things when it does go wrong. I want to know who's best to contact for support in this situation. Our phones are Yealink which show up as unsupported (but that should not stop them working) and our SIP provider is SureVOIP/Suretec (again unsupported but worked fine before). I was reluctant to open a paid for support ticket from 3CX as they state they won't entertain unsupported phones and providers. Thing is we have a dozen custers using 3CX with unsupported phones and the same unsupported provider which are running perfrectly fine. Any advice would be much appreciated :)
 
What provisioning method are you using for the affected IP Phones? Since they are remote it should either be via STUN or the 3CX SBC.

Regarding the unsupported message, why is that, are you running old firmware or custom templates? Running an unsupported config indeed doesn't necessarily mean that it won't work, but it can mean that you might experience unexpected behavior as it involves a configuration scenario not tested by us.
 
So I compared the settings between our instance and our customers and noticed in the network settings>firewall section they had the Send Media to IP and port of REGISTER checked whereas ours didn't. So I set that the same and also went around updating the firmware on all the handsets. I also gave each office handset a seperate range of RTP ports (we'd had SIP ports set differently prior but not RTP). Rebooted everything and we now seem to be working again.

NB: We use custom templates cos we need to turn of Trusted certificates in order for the phones to register. I've since tried to use normal templates but the phones seem not to trust the Let's Encrypt cert. Is there a work around for this?
 
Last edited:
I also gave each office handset a seperate range of RTP ports (we'd had SIP ports set differently prior but not RTP). Rebooted everything and we now seem to be working again.
This is probably what did the trick for you as I'm assuming they are configured as STUN phones.
Apart from this, you may also want to configure the Firewall at the location where the IP Phones are to forward those ports to each phone too, then there should be a problem at all.



NB: We use custom templates cos we need to turn of Trusted certificates in order for the phones to register. I've since tried to use normal templates but the phones seem not to trust the Let's Encrypt cert. Is there a work around for this?
If they are older models, then this might be the case. also make sure you are running the latest recommended firmware for your models:
https://www.3cx.com/support/phone-firmwares/
 
Last edited by a moderator:
Thanks Nick, We are still having some glitches so I will make the adjustments in our local firewall (pfSense) although I've never had to do that before with any other instance/customer system. I'm guessing normally the phones make the RTP port choice request to the 3CX system rather than the 3CX system blindly trying to get through on whatever port it chose cos otherwise it can't work and none of our other customers would work (as they are setup with no port forwarding and only unique SIP ports) Will report back...
 
Thanks Nick, We are still having some glitches so I will make the adjustments in our local firewall (pfSense) although I've never had to do that before with any other instance/customer system. I'm guessing normally the phones make the RTP port choice request to the 3CX system rather than the 3CX system blindly trying to get through on whatever port it chose cos otherwise it can't work and none of our other customers would work (as they are setup with no port forwarding and only unique SIP ports) Will report back...
Not doing it per the KB I linked to is a bit of a gamble as you are relying on the uPNP function of the remote location firewall to do it's thing.
Some handle it better than others, but if you want peace of mind, you should do the firewall rules.
 
Ok so tried allocating separate SIP ports and RTP ports, phones on static IP's and firewall rules put in place - Result = even worse than before \o/. So decided to install SBC service on one of our servers and put all the handsets behind that. All working now :)
Hadn't thought about putting an SBC border controller in as last time I looked I remembered it needed a piece of hardware to run on but now it runs on windows so gave it a whirl. Will probably keep with this method as it's bound to happen again and we don't really have the time to deep dive into it everytime. Thanks for all the help.
 
Ok so tried allocating separate SIP ports and RTP ports, phones on static IP's and firewall rules put in place - Result = even worse than before \o/. So decided to install SBC service on one of our servers and put all the handsets behind that. All working now :)
Hadn't thought about putting an SBC border controller in as last time I looked I remembered it needed a piece of hardware to run on but now it runs on windows so gave it a whirl. Will probably keep with this method as it's bound to happen again and we don't really have the time to deep dive into it everytime. Thanks for all the help.
SBC is a real life-saver in these kind of scenarios! Good decision if you ask me! :)
 
Status
Not open for further replies.

Forum statistics

Threads
111,974
Messages
590,083
Members
164,901
Latest member
Silent_Guru