Phones go to no service once a week randomly

Status
Not open for further replies.

webworld

Titanium Partner
Advanced Certified
Joined
Aug 30, 2011
Messages
7
Reaction score
1
My yealink t54w and Polycom VVX350 phones randomly will go to "no service" - have about 60 phones in total . 3CX is hosted remotely in a datacenter. I have sonicwall TZ670 at my local site which is configured correctly for 3CX - SIP ALG off. consistent NAT enabled. Firewall checker passes.

When the no service occurs, the 3CX services keep running and any existing calls show as connected.. If I restart services, then system is restored and phones work. So it appears as though 3cx doesn't know that the phones are in no service mode. Any ideas out there. I'm restarting services constantly until we identify cause. UDP/TCP timeout issues? Internet is 200/200 fiber and is rock solid. I have set up with a ping tool and doesn't show any latencies.

mark
 
Since these devices are remote it means you should either have them provisioned via STUN or 3CX SBC, which of the two is it? If you are using STUN, I highly recommend you switch to using the 3CX SBC instead as there's a good chance you're facing this issue due to the configuration requirements that come with using the STUN provisioning method. To use the 3CX SBC you will of course need a host to install it on.

If for any reason you must use stun, at least make sure you've taken all the necessary steps.

If you made sure all this applies and need assistance please do provide additional information about your setup
 
Last edited by a moderator:
If you are using phones behind a Sonicwall router stun will be a real pain. Use the 3CX sbc or setup a site to site vpn between the office and cloud pbx.
 
Thank you. I am using STUN. I have 23 customers with sonicwalls and 3cx offsite. The only customer that is having this issue is the largest and has 3 separate sites with phones. I have never had any config issues and any issues with any sonicwalls. but there is always a first time. I did notice thou that all local UDP ports on the phones are set to 5065. Not sure why or if it even matters. Appreciate your input greatly and thank you once again.
 
  • Like
Reactions: ChrisC_3CX
I did notice thou that all local UDP ports on the phones are set to 5065.
If IP Phones on the same site all use the same source port for SIP then that would explain it as it would very likely affect registration as in your case. I'd definitely recommend you try configuring each of them with a unique SIP port and RTP range, and then reprovision them again to see if that fixes it. You would of course have to forward the corresponding ports to each phone on the remote sites firewall.
 
  • Like
Reactions: pmterp
what UDP/RTP port ranges can I use if I have 60 extensions? By the way I have 3 sites for this company. Main site 50 phones, 2nd site 5 phones, 3rd 5 phones. When 3cx functionality is lost, all 3 sites' phones go to no service. FYI, all separate ISP's, no VPN between sites.
 
Last edited:
If you have so many remote extensions I would strongly recommend using the 3CX SBC. especially for the site that has 50 IP Phones.

The ports just need to be unique

For instance:

1st Phone
SIP PORT: 5065 UDP
RTP Range: 14000-14019 UDP

2nd
SIP PORT: 5066 UDP
RTP Range: 14020-14039 UDP

3rd
SIP PORT: 5067 UDP
RTP Range: 14040-14059 UDP

4th
SIP PORT: 5068 UDP
RTP Range: 14060-14079 UDP

and so on...

They only need to be unique per site so for site 2 you can start over and then again for site 3. I have to mention though, that, if all sites deregister at the same time, there's a good chance something on the PBX end is happening instead but you still have to get STUN misconfiguration out of the way so that we can eliminate it contributing to the issue.

If the issue persists I might recommend running packet captures on the PBX to see if anything particular happens with the traffic during those times.
 
Last edited by a moderator:
Adding more to this thread..... We dug deeper into this issue and exported local logs on 2 of the extensions. Interesting enough, the log reveals some DNS issues. See attached. Root of issue?
 

Attachments

Status
Not open for further replies.

Forum statistics

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