One-Way VoIP Audio Fault

Publication Date:  2015-07-24 Views:  163 Downloads:  0
Issue Description
An office connects the U1910 to carriers through SIP trunks in the UC project. When an intra-office user makes an outgoing call, both the calling and called parties can hear each other. When a mobile user from carrier A makes an incoming call, both the calling and called parties can hear each other. When a mobile user from carrier B makes an incoming call, one-way audio occurs. When a mobile user from carrier C makes an incoming call, neither the calling or called party can hear each other. The following figure shows the network diagram.



Handling Process
The ISP modifies the network configuration to ensure that the local terminal can send and receive RTP data streams properly and RTP data streams can be sent to the peer terminal. The fault is rectified.
Root Cause
One-way VoIP audio faults generally occur in the voice data exchange phase after calls are set up. The PBX generally has nothing to do with the faults. The fault location method is as follows:

1. Check the local terminal. Capture packets on the local terminal and verify that RTP data streams can be sent and received properly.

2. Check the network. Capture packets on key network nodes and verify that the RTP data streams sent by the local terminal can be properly forwarded to the peer terminal.

3. Check the peer terminal. Capture packets on the peer terminal and verify that RTP data streams can be sent and received properly.

4. Check the RTP data stream encoding format and packetization duration supported by the carrier networks and terminals.

The following describes analysis on the packets captured on the local terminal.
The following figure shows the RTP data streams captured for the incoming call made by the mobile user from carrier A.



From the preceding figure, the local terminal sends and receives RTP data streams properly. Both the calling and called parties can hear each other.
The following figure shows the RTP data streams captured for the incoming call made by the mobile user from carrier B.



From the preceding figure, the local terminal sends and receives RTP data streams properly. However, one-way audio occurs. You must check whether the network forwards RTP data streams to the peer terminal properly. Based on the packets captured on the ISP side, RTP data streams are received properly but fail to be forward to the carrier network. Therefore, the mobile user cannot hear any voice.
The following figure shows the RTP data streams captured for the incoming call made by the mobile user from carrier C.



From the preceding figure, the local terminal sends RTP data streams but no RTP data stream is received. Therefore, the intra-office user cannot hear any voice. Based on the packets captured on the ISP side, RTP data streams are received properly but fail to be forward to the carrier network. Therefore, the mobile user cannot hear any voice.
Finally, the ISP finds that the input and output paths for RTP data streams are different for calls from mobile phones. As a result, data packets are rejected and users cannot hear any voice.

Suggestions
In the early phase of fault location, it is found that G729 media in INVITE messages from the ISP does not contain the packetization duration parameter. As a result, 60 ms is used as the ptime value to send RTP data streams to the IP phone. However, the IP phone uses the default duration 20 ms based on the G729 protocol. Fault location personnel suspected that this is the cause of the fault. In fact, terminals support parsing of RTP data streams using various ptime values. The ptime value does not determine whether a user can hear voice. Instead, the ptime value determines the voice delay and noise. The fault is finally located based on the method described in the preceding sections.

END