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).
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.)
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.
Check if your NAT is set up for symmetric port forwarding.
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.
Your ITSP may not be supporting re-INVITE or your ITSP account may be mis-configured.
ITSP may not be supporting session timer. Find another ITSP if possible.
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.
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.
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.
If you are behind a NAT make sure that "Server Behind NAT" is checked in the _Internet Calling > NAT Traversal_ page.
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 :