Troubleshooting

Firewall Port Randomization Prevents Outbound Call from Succeeding

Some firewalls (in my case pfsense and m0n0wall) randomize outbound ports that can cause problems for some ITSPs. That is, if the source port for the REGISTER does not match the source port for the INVITE you may get an error 403.

The solution in pfsense is here: http://doc.pfsense.org/index.php/Static_Port

Basically you configure manual outbound NAT and specify the static port option. (tip courtesy of Jonathan Petersen).

Outbound call does not complete

Phone rings but no media or calls drop after a few seconds. Make sure your trunking gateway configuration has sipxbridge specified as the SBC. Otherwise, sipXecs will directly send the request to the ITSP. SipXbridge will not have a chance to re-write the request and hence your call will not complete even if your ITSP is doing hosted NAT compensation. (It might work on random occasions.)

Inbound call does not complete

Make sure your ITSP did not directly send the call setup request to port 5060. That would bypass sipXbridge altogether. Make sure you have mapped firewall port 5080 to LAN port 5080 so sipxbridge has a chance to rewrite the inbound request from the ITSP. Get a sniffer trace on your sipXbridge box and make sure the request is being routed through sipxbridge.

Cannot hear auto attendant prompt when call is answered by Auto Attendant

Check if your NAT is set up for symmetric port forwarding.

No MOH heard for SNOM phone

This is caused by a bug in SNOM firmware that does not properly set the port when transferring the call to the park server. Set the "reject stray packets flag" to false in the NAT traversal settings.

Dropped call on hold

Your ITSP may not be supporting re-INVITE or your ITSP account may be mis-configured.

Call dropped after 1/2 hour

ITSP may not be supporting session timer. Find another ITSP if possible.

SipXBridge stops registering after a while

The IP address that sipXbridge used to REGISTER is different than that returned in the Contact header of the response. If your public address changed, you need to be using STUN. Otherwise this is a protocol error. Inform your ITSP.

Call forwarding call setup not working

Check to see if your ITSP wants to see the same From header as the initial call setup. Read the material above on _P Asserted Identity_ setup. If your ITSP does not support P-Asserted-Identity, uncheck default asserted identity in your advanced ITSP section and leave the Asserted Identity field blank. See step 8 in the setup section above for details.

Call forwarding media path not working

Your NAT may be doing NAT compensation and creating a media deadlock. Turn on _RTP keepalive_ in the advanced section of the ITSP setup screen. Experiment with different settings. _Replay last sent packet_ is a good bet.

Signaling OK but media not OK

If you are behind a NAT make sure that "Server Behind NAT" is checked in the _Internet Calling > NAT Traversal_ page.

Problem reporting

Discuss problem on user list. Make sure there really is a problem and not just a misconfiguration. Detailed analysis will require a sipx-snapshot (wireshark traces do not suffice). Do NOT post excerpts of traces on the mailing list. They are not much use.

To take the snapshot :

1. Set logging levels of sipxbridge to DEBUG if necessary. Configuration problems require only INFO level logging. Logging levels of sipXecs Proxy server to INFO, Loging level of sipXecs Registrar to INFO
2. Clean out the log directory.
3. Shut down the system.
4. For deep signaling issues (if asked for such information), edit _etc/sipxpbx/log4j.properties_. Add the line *log4j.category.org.sipfoundry.sipxbridge=trace*. This turns on detailed stack logging. Set the logging level to DEBUG on sipXbridge for stack logging to be enabled
5. Restart the system.
6. Run the problematic call flow.
7. See [(!)missing link] for a GUI interface that allows you to take a snapshot. Alternatively you can use sipx-snapshot from the command line. Note that sipxsnapshot does not transmit any private data. It is absolutely required that this information be available to debug problems.
8. If the problem includes media issues such as one way speech, you would need to include a wireshark trace with your porblem report. You can filter the wireshark trace for RTP only. You can capture the trace using *tcpdump -n -nn -s 0 -i any -w sipx-tcpdump.cap* . You would also need to include a detailed trace for the media relay. For this edit _etc/sipxpbx/log4j.properties_. Add the line *log4j.logger.org.sipfoundry.sipxrelay=trace* (note: for version 4.0.4: *log4j.category.org.sipfoundry.sipxbridge.sipxrelay=trace*.) Save this and restart the media relay before running your test. It will generate a lot of logging information.
9. Open an issue and attach the snapshot, log files and pcap trace there or mail the list and ask for help on where to mail the snapshot.