Versions Compared

Old Version 9

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Panel
  • Begin by deleting all the default entries in "Intranet subnets" as they are almost always wrong.
  • In "Intranet subnets", add as many entries as required to describe the local private network that sipXecs is a part of.  For example, if your sipXecs  is part of the private network 10.10.10.0/24 then you need to have a single "Intranet subnets" entry of "10.10.10.0/24".
  • In "Intranet Domains", the default provided is almost always all you need - leave it as is.
  • [xecsuserV4r2:Important] Make sure that 'Use external SBC for Internet Calling' check box is disabled. This setting may only be only useful when using a session border controller other than sipXbridge.


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

...