Gather Data

1. Identify if the issue is only occurring on a single DID or multiple DID. It is important to get this information from the client as they may have numbers that are originating from different carriers. If multiple DIDs are affected, are they all from the same carrier? if not then focus investigation on the termination side of the call. If this is a single DID, focus investigation on the origination side of the call for Inbound.
2. Is this only happening with Inbound or Outbound Calls?
3. Obtain call traces and two QoS links for each call.
4. Identify the Carrier. It is usually on the 2-3rd switch logic. You can search the call trace using 'gateway' keyword.
5. Below is an example of an outbound call which shows the termination connection where the call was sent to depicted below.
   

Identify The Source of Audio Speech Path Issue

1. Open the call trace
2. Make note of the Codecbeing offered.
   1. Click the 1st or 2nd invite, make note of the 'm' value in the SDP
      
   2. Click the 1st 200 OK to the origination and make note of the 'm' value, this is the value that the termination has offered and agreed to use, which you'll see an ACK response just below the 200 OK which means origination agreed to to use this Codec
      
3. Make note of the RTP Stream IP
   1. Click the 1st or 2nd invite, make note of the 'c' value in the SDP (c=is the RTP stream ip)
      
   2. Click the 1st 200 OK from the termination or other side of the call trace. This could be a connection trunk for BYOT or this could be the domain where the user device is registeredfrom. Make note of the 'c' in the SDP, this is the RTP stream IP 
      
4. Now go to the end of the trace, and click on the switch logic just below the BYE or use the search feature and search for 'CB2BProxySessionStateDisconnecting'.
   1. The 2nd small arrow represents the Bitrates used for 711 codec which is basically 64Kbps + header so 68Kbps is the expected value. If this value is below 80 percent for a call that has a duration of at least 10 seconds of call, then that is suggesting an issue. (You can use this KB from Cisco as a reference for the other codec)
      
      FYI, Above example shows that we don't have an issue with the call as it is merely just a representation of how the RTP stream converge on NS switch
5. Once you have identified the troubled RTP stream, now open the QoS link for that side of the call. If PDV value is greater than 200+ then that's red flag, this suggest that the issue from the client or side of the call where this value is high. You my have to run a pingplotter in this case. If there's a big difference between received packets for caller and calledthen you know there's a packet lost.
   
6. Listen to the Audio to see who experienced the call quality issue. If the issue is clear on Voipmonitor, again, refer to the PDV source value and focus on investigation on that side of the call. For WLP, you may have to have them run a PCAP on the firewall or device. For CP/Direct, see if you can capture a PCAP from the device or engage their Managed IT.
7. Document your findings and escalate to T2 and higher if you're still unable to resolve the issue.
   1. Inbound or Outbound?
   2. RTP Stream IP and Codec for the Origination?
   3. RTP Stream IP and Codec for the Termination?
   4. Who experienced the one-way audio? Orig or Term?
   5. What are the PDV and Jitter Values?
   6. Provide the call traces and QoS links
   7. Provide any PCAPs from the Client Side