...
| Panel |
|---|
|
Step 2 - configuring public IP address of sipXecs
...
| Panel |
|---|
|
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.
...
| Panel |
|---|
|
High Availability Consideration: If the sipXecs deployment is a High-Availability (HA) one, firewall rules need to be created to allow each sipXecs server's Public Port and SIP Port and RTP port range. Also, NAT forwarding rules must be created to forward each Public Port and SIP Port and RT Port range to the IP address of their corresponding sipXecs. For example:
- If sipXecs Server 1 has Public Port of SIP Port of '5060' and RTP port range for [30000-31000[ then ports 5060 and [30000-31000[ must be allowed and forwarded to the IP address of Server 1.
- If sipXecs Server 2 has Public Port of SIP Port of '11060' and RTP port range for [31000-32000[ then ports 11060 and [31000-32000[ must be allowed and forwarded to the IP address of Server 2.
- If sipXecs Server 3 has Public Port of SIP Port of '12060' and RTP port range for [32000-33000[ then ports 12060 and [32000-33000[ must be allowed and forwarded to the IP address of Server 3.
...
- Carefully review the configuration steps contained in this guide
- Phone's outbound proxy is configured with routable IP address associated with sipXecs and that address can be pinged from a machine inside the remote network
- Phone is configured with the proper SIP domain, SIP username and SIP password
- If sipXecs is behind a local NAT, ensure that the pinholes and port forwarding rules have been created as per configuration step #5.
- Verify that STUN and ICE (if supported) are disabled in the remote phone
- Verify that SIP ALGs are disabled in both the remote and local NATs
- Verify that the 'Use external SBC for Internet Calling' checkbox is unchecked in 'System->Internet Calling'
- Review the alarm history and look for reported NAT traversal-related failures. The alarm history can be found in sipXconfig under 'Diagnostics->Alarms->History'. Be sure to select a wide-enough date range to cover the last reboot of the box.
...
- 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
...