Speech path issues on SIP Trunks
If users are experiencing speech path issues on SIP trunks, please check the following:
SIP Settings
- Navigate to SIP Settings page, verify the parameters under NAT settings.
- Ensure External IP is configured with the correct external IP address.
- Check that Local Networks is properly configured.
Port Forwarding
Typically, the UCx server is deployed behind a router that implements NAT/PAT between the UCx server and the Internet. In order for the UCx system to properly establish voice path for SIP trunks calls in all possible scenarios, it is necessary to enable port forwarding of RTP ports to the UCx server. This is done on the router. The RTP port range (by default 10000 to 13999) must be forwarded to the IP address of your UCx Server (by default 192.168.1.200).
| Rule Name | Port Number/Port Range | Port Type |
|---|---|---|
| RTP (media) | 10000 - 13999 | UDP |
Firewall
If there is a firewall implemented on the network, ports 10000-13999 need to be opened.
SIP ALG
If SIP ALG exists on any router or firewall in the network, make sure they are all disabled. See Unexpected call failures and registration problems for details.
Choppy Voice from Packet Loss on SIP Trunks
By default, the UCX sends SIP media (RTP) packets associated with SIP trunks with a special marking in the IP packet that routers can use to treat them with a higher priority as they traverse the internet. This prioritization marking is commonly referred to as DSCP (Diff Serv Code Point) tagging. By default, the UCX sends the SIP media packets with the industry standard DSCP value of EF (Expedited Forwarding). Some Internet Service Providers do not support the use of the EF value for DSCP and may actually treat it as lowest priority, which will cause intermittment packet loss and impact voice quality. In these circumstances, use the Other SIP Settings in the SIP Settings to change the DSCP for the SIP trunk media packets.
Call Forwarding Incoming SIP Trunks
When a call arrives on a SIP Trunk and is immediately forwarded back out to another SIP trunk connection, the resultant call will likely expereience one-way or two-way speech path issues. To resolve this refer to the Inbound Routes documentation for a method to anchor the call to the UCX prior to forwarding.