Hi. For about two weeks now, callers have been complaining of one way audio when calling one of our centers. I have opened a support request with our ISP and they said that they see no signs of one way audio and asked for more details and call samples which I have provided them and am waiting on their response. The ISP delivers SIP to a 908e Access Router that sends it over to Netvanta 7100 through PRI trunk. The staff assigned to answering the phones say it appears to be happening more in the early morning. The problem is intermittent so I haven't been able to reproduce it during a debug capture. Everything had been working fine before and there were no changes made. The 7100 is running R11.4.5.E and the 908e is running R10.9.0. Adtran IP 712 phones show up as v2.4.1 and Polycom SoundPoint shows up as 3.3.5.0247; I guess that is the firmware running on the phones. I'm looking for steps on troubleshooting one-way audio on my end. Thank you.
Update: I was able to reproduce the problem after many tries. The calling number ends in 5534 and the destination number ends in 3460. The Ring Group is set to ring 8 times after which the caller is sent to the Call Queue. After some time of being in the call queue, one of our representatives picked up my call but could not hear me and I could hear her. I ran a debug during the call using ISDN L2 Formatted and SIP Stack Messages. Please see debug attached. Appreciate the help.
Update - 2: Our ISP detected errors and dropped packets on one of four T1 lines. Could this be causing one-way audio? VOIP is layered on top of our data but we have three T1s that are functional. I know that is the first thing I checked when one-way audio was first reported but I did not see any problems then.
Looking at your debugging and not having a full knowledge of your network, this is my observation. Your sip end points are showing the SDP profiles with media IPs for other networks. Either the adtran needs to be doing media anchoring which will rewrite the TX sip invites sent out to use the egress interface IP as the media IP assuming ip media-gateway primary is applied. If you are not wanting to do anchoring, make sure you have routes for those other networks. 1 way audio would be caused if the anchoring failed to write due to load or there are missing routes.
Hi, I got the following update from our TelCo after giving them the same debug info.
The corresponding call was found on the provider network. The RTP capture on the customer side of the provider SBC facing your Total_Access_908e_3rd_Gen/R10.9.0 has RTP packets flowing in both directions, however there was no audio on the packets flowing from the provider SBC Media IP to your Adtran 908e at Site A. The originating side of the call was from your other Site B, but the RTP captures for the provider SBC on that side of the call were not enabled. I have referred the ticket out to my 3rd level support to enable historical captures on provider SBC facing your ADTRAN_Total_Access_908e_2nd_Gen/A2.06.00.E at Site B. Once they have been enabled, we will request new occurrences of one-way audio.
I'm still trying to decipher what exactly they mean. I reproduced the one-way audio issue by calling from Site B to Site A. I guess what they are saying is that Site A is good but the Provider Media Gateway is not sending audio so they want to rule out a problem at our Site B? This of course does not happen only when calling from our Site B to Site A, it happens intermittently when any outside party calls Site A; I just happened to use Site B to try and reproduce the issue.
Hi, By other networks do you mean 10.59.8.1? 10.59.8.1 is the 7100 Primary IP (VLAN1)? 10.59.28.1 is the 7100 Secondary IP (VLAN2); RTP streams go from provider media gateway to the 908e and then from the 7100 to the user. RTP from the user goes out to the 7100 then to the 908e then out to the provider media gateway. I just reproduced the problem and captured traffic flowing to the 908e and can see that RTP is making it to the 908e from the provider. RTP is not making out to the user though I don't know what may be causing it yet. Nothing has changed to my knowledge other than minor changes to the Call Queue; members were provided SPRE codes to log in and out from the Ring Group and Call Queue. One user did mention that the problem started happening around the time they began using the SPRE codes but that seems unlikely; still, I disabled the Call Queue to see if this may have anything to do with the problem.
Hi. I'm not 100% sure but I think it was 7102 as I immediately stopped the debug right after the clerk hang up on me when she was not able to hear me. Debug shows 7102 as the last extension that interacted with my call coming from ******5534. That is not the only phone experiencing the problem however. All four extensions that are part of the Ring Group/ Call Queue have reported the issue and it has been confirmed that it is happening to at least three of the four extensions.