Troubleshooting Remote SIP

Troubleshooting Remote SIP Connections

Things to check if a remote phone or SIP Provider is not working. This can no audio, one way audio, poor audio quality, dropped calls, or other intermittent behavior.

When an issue is reported, we advise to start by ensuring the following settings are correct:

1. External IP or External Host are properly set in PBXSetup=>SIP
2. Extension is configured as a WAN phone (Under advanced in Edit Extension page).
3. ACL under Networking->Access Control->Access Control List make sure that the Remote IP address isn't being blocked.
4. The appropriate port forwards are configured in the Main Site Router Port Forwarding

• If you are troubleshooting a remote phone and you have a network available that you are certain works for registering remote phones to other systems, this network would be a good place to attempt to register the remote phone from. If it works, then the problem is most likely with the Remote Site Router as opposed to the router in front of the PBX. If it doesn't work then it's most likely an issue with the Main Site Router or and ACL issue.

• If you are troubleshooting a SIP Provider, try registering a remote phone and ensure that it works. This will help to discern that everything we expect to work with regards to the Main Site Router and PBX settings are correct.

• The PBX has a TraceRoute feature you can use to check for packetloss between the Main Site and the remote SIP public IP address. 0-5% dropped packets can bee acceptable, 5-10% can lead to poor audio quality, and anything greater than 10% may lead to dropped calls. By using TraceRoute or WinMTR you can demonstrate this loss to the end user and the ISP so they can work to resolve it. [Note] With sporadic issues you may need to test this multiple times, as there will be periods when it tests fine, other times it will show jitter. NOTE: You may need to run WinMTR in compatibility mode if you are using Win7 or Win 8 (http://www.sevenforums.com/tutorials/316-compatibility-mode.html)

• You can also use the following links to verify the bandwidth as well as packetloss/jitter at the Main and Remote sites. We advise allotting 100-200k up and down per call, any less and you could run into issues.

http://myspeed.visualware.com

http://myvoipspeed.visualware.com

A great resource for checking the SIP compatibility of a router, as well as instructions for changes that may need to be done on the router such as disabling ALG or SPI.

Router Compatibility Guide

http://support.vocalocity.com/kb/router-compatibility-guide-and-recommended-equipment-list/

Phones Losing Registration every 2-5 minutes

Inconsistent NAT will cause a phone to lose registration at a specific interval, typically 2-5min. When this occurs, the phone will not be able to receive calls, but it can still make calls. If you are not able to replace the router with one that handles NAT more consistently, we have found that you can log into the phone and set UDP Keepalive Message to Yes. (If you are editing the Default Phone Template, the field will be called Keepalive, and needs to be set to 1 for enabled). If that does not work, you can also try to lower the Register Expire Time to stop the phone from losing registration. Both fields are found under SIP Account=>Account 1. We would advise to set the Register Expire Timer to a value below the interval you are seeing the phone lose communication. (eg. If the phone drops out every 2 minutes, set the value to 110 seconds, or tweak if that value does not fix the issue).

Hung Channels

In some circumstances, when signalling fails to terminate a call properly, you can end up with channels that appear to be connected.  If you have a call limit on a sip provider or a remote phone these hung channels can cause the counter to be incremented and if you get enough channels like this equal to your call limit you might not be able to make calls.  In order to prevent this from occurring you can set RTP Timeout and RTP Timeout On Hold under PBXSet->SIP->Advanced.  Note there are a couple of nuances to using these settings.  If you do not have music on hold and set RTP Timeout on Hold, then the call will drop after the specified number of seconds on hold due to lack of RTP traffic.  It's a good idea to set these to something beyond a reasonable hold time.  RTP Timeout itself could be set to something like 10-20 seconds and it generally won't effect anything, (except you will never have hung channels).  RTP Timeout on hold is better at a setting like 300 seconds so that you don't hang up on people that you put on hold if you haven't properly set your music on hold.  (Note setting music on hold to use silence file is okay, you just need a file). 

Remote phone rings, answer, no one there, no audio at all

It has come to our attention that some routers use the default ports set in the phone for RTP (1000-1012). If you are having problems with audio, or a call ringing and not actually answering when you pick up, you can log into the phone via IP address and try the following:

• Navigate to Phone Settings
• Click Basic
• Click Call
• Change the RTP Port from 1000-1012 to something else not used, perhaps 5000-5012.
• If you want set this field in the global template for all phones you need to modify the field BeginPort="1000" EndPort="1012" and change the ports to something unused that is not 1000-1012.

After rebooting PBX Remote Phones do not recover quickly

Remote phones are able to be addressed by the PBX because they register with it.  After registration, the NAT port on the remote phone's router stays open as long as the PBX is sending packets to the phone to ensure it is reachable.  In some routers, when the PBX reboots, it stops sending packets for long enough for the NAT timer to elapse and the remote router closes the port down.  The PBX is only able to reach the phone again at this point after it reopens the NAT port, which will be done when the phone re-registers.

For HD Phones:

If you have a particular remote phone that you have found has this issue, you can adjust the registration timer on the phone. It is located under SIP Account->Account 1 and it is called "Register Expire Time" the value is in seconds. As you will see the default is set to 60 minutes. This could be a long time if the router has a short NAT timer. So you could set it to 60 seconds or 120 seconds and that should recover from a PBX reboot much more quickly.

You could also change this in the global template if you using the PBX to configure remote phones.  

Phantom Calls

The symptoms here are a remote phone that receives calls and when answered no one is there, no audio. Many times, the CID displayed won't match up to any extensions on the PBX (we've seen calls from 100 often). What's most likely happening is that someone malicious is sending packets to 5060, and they are getting to the phone and making it ring. Here are a few things you can try to alleviate this.

• Ensure that Guest Calls is disabled in the PBX. (Found under PBX Setup=>SIP=>Advanced)
• Ensure that 5060 is not forwarded in the router at the remote site
• Log into the phone and under Phone Settings=>Basic=>Call there is a field Local SIP Port. Change this to something like 5092 (an unused port not typically associated with SIP) If you do this, you'll have to set AutoDL Config to No if the phone can download programming from the PBX, otherwise the field will get overwritten.​​
• If you have a lot of remote phones and do not want to disable automatic configuration of the remote phones in question then you could try two additional solutions
  • 1) Another solution could be to force the router to use 5060 for a nonexistent address. So forward 5060 on the router to an address that is not in use outside the dhcp pool, then the router will have to pick a different port to NAT.
  • 2) You can change the local port in the global configuration. It will change all phones but it shouldn't matter.
    
    Under PBXSetup->Phone Global
    Edit the global phone configuration template:
    
    Enter 5092 where you see the highlighted text:
    

Once all of this is done, the user won't get any more calls from malicious individuals sending packets to 5060.

Please note that if this issue is occurring it's a good idea to replace your router as it has a pretty big security flaw.  This should be pretty rare. NAT should not open a port to ANY IP, only the IP that was initially contacted should be able to respond. This is the case with most routers.