...
High Availability Consideration: If the sipXecs deployment is a High-Availability (HA) one, Remote NAT Traversal can still work but the HA brings about a few complexities with respect to step 2. Basically, Step 2 has to be repeated for each server found under "System->Servers" and each server must be configured with unique a 'Public SIP Port" value and non-overlapping RTP port ranges as defined by the 'Start RTP port' and 'End RTP port' fields found under the 'Advanced Settings". So for example, if the HA deployment has 3 servers, the following settings could be used:
- sipXecs Server 1 has Public Port of SIP Port of '5060' and RTP port range for [30000-31000[
- sipXecs Server 2 has Public Port of SIP Port of '11060' and RTP port range for [31000-32000[
- sipXecs Server 3 has Public Port of SIP Port of '12060' and RTP port range for [32000-33000[
...
| Panel |
|---|
|
Step 4 - Restart the required services
NOTE: This step is only required if the sipXecs is deployed inside a private network. If you left the 'Server behind NAT' checkbox unchecked in Step 1 above then you can skip steps 2 through 5 completely and move on to Step 6 immediately.
...
- Go through the general troubleshooting tips found at the top of the 'Troubleshooting' section.
- Power down any other phone that is registering against the same SIP user as the problematic remote phone. As an example if the problematic remote phone is registering against SIP user 200@example.com and so does a local phone then that local phone should be turned off to keep logs unambiguous.
- Turn on DEBUG logging for the SIP Proxy and SIP Registrar. This can be done though sipXconfig by navigating to 'System->Logging Levels->Show Advanced Settings'. Once you have selected the DEBUG logging level, a purple banner will appear to restart those services much like what is shown in configuration step #4. Do restart the services
- Once the SIP Proxy and SIP Registrar are back to a running state, log into the sipXecs shell and execute the following command:
No Format tail -f /var/log/sipxpbx/sipXproxy.log | grep "REGISTER sip" | grep "<user>@<SIP domain>" > regdebug.log where: <user> is the SIP username against which the remote phone is trying to register <SIP domain> is the SIP domain configured in the remote phone trying to register - Reboot the remote phone and wait for it to try to register. After it has failed to register, go back to the sipXecs and hit ctrl-c to stop the command and execute the following command:
No Format wc -l regdebug.log
- If the command returns '0' then it means that the REGISTER requests emitted by the remote phone are not reaching sipXecs and that you have network connectivity issues. Re-verify the configuration of the local and remote NAT making sure that any SIP ALGs are disabled and that pinholes and port forwarding rules have been applied to the local NAT in accordance with Step 5 of the configuration guide.
- Else, if the command returns a non-zero value, it means that packets are reaching the sipXecs as they should. Proceed to execute the following command:
No Format grep -i received regdebug.log | wc -l
- If the command returns '0', it indicates that either the phone is not a remote phone or that it has STUN enabled or that the remote NAT has a SIP ALG turned on - double-check these elements.
- If the command returns a non-zero value, things appear to be working fine from the Remote User NAT Traversal point-of-view. Refer to the general registration troubleshooting guide found here for additional help.
Problem #2 - Remote Worker registers but cannot make or receive calls
...