One way audio for incoming calls

[Anonymous]

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.

[Anonymous]

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.

[Anonymous]

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. 

[c_stemp]

Juad,

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.

Charles

[Anonymous]

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.

[Anonymous]

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.

[Anonymous]

Aaron, can we get the configurations of the devices involved in order to confirm the routing and IP addressing setup? Thanks

Jay

[Anonymous]

Thanks for reviewing these Jay.

[Anonymous]

Aaron, in the debug you provided, what was the extension of the actual phone that answered the call and had one-way audio? Thanks

[Anonymous]

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.

[Anonymous]

Hi Jay, In comparing 7100 configuration from problem site with other sites configuration I noticed the following difference:

Other sites have the following entry for extended InterVLAN ip access list where the Source is VLAN1 and Destination is VLAN2 then another entry where Source is VLAN2 and Destination is VLAN1 (see example below):

ip access-list extended InterVLAN

remark Voice / Data VLAN Traffic 

permit ip 10.59.2.0 0.0.0.255  10.59.22.0 0.0.0.255    

permit ip 10.59.22.0 0.0.0.255  10.59.2.0 0.0.0.255

At the site we are having one-way audio extended InterVLAN access list differs because it does not show VLAN1 (10.59.8.0) or VLAN2 (10.59.28.0) for either source or destination:

ip access-list extended InterVLAN 

remark Voice / Data VLAN Traffic 

permit ip 10.59.0.0 0.0.0.255  10.10.20.0 0.0.0.255    

permit ip 10.10.20.0 0.0.0.255  10.59.0.0 0.0.0.255  

The firewall is not on so I don't know that this might even be a problem but just throwing it out there.

[Anonymous]

The reason I ask is that 7102's IP address is on the same subnet as the 7100. Since you were talking about remote sites, I was assuming they would be separated.

The firewall config would have no bearing on traffic unless the firewall was turned on.

Thanks

Jay

[Anonymous]

Hi.  Yes, the 7102 extension is on the same subnet/ location as the 7100.

[Anonymous]

Aaron, if you're experiencing one-way audio on the same subnet as the 7100, I would recommend opening a ticket with support. This is likely going to require DSP captures and packet captures to nail down the source of the audio loss, since the 7100 isn't running a firewall and there can't be a routing issue. Thanks

[Anonymous]

I have seen similar behavior in a couple of scenarios.  Not sure which one is pertinent for you but might be worth checking into.  It seems your issue maybe time related as in it happens after sitting in queue for awhile.  It maybe related to the RTP port being shutdown somewhere along the way due to the length of time the port has been open.  I had this situation start occurring on me after the Voice Vendor moved us from one switch platform to another switch platform without notifying me of the change until after the fact.  The new platform had a different port timeout then the orginal one, but since the provider could not fix the issue I set all the phones to remote phones so they perform keep-alives more often, not the best solution but it got management off my back until we can get the numbers ported to a carrier that works correctly. 

Second possibility with 11.4.5 code on the 7100 the command "ip rtp media-anchoring" was removed from the 7100 meaning that it does not keep itself inserted in the middle of a call anymore so if the call is moved to a device that is no longer directly connect the RTP stream breaks.  This type of scenario is common when calls are being moved between B2BUA since you want to create a break point between your network and the carrier as an example, and since you specifically mention an SBC between you and your providers 908E this is very possible.  If the problem started being reported after updating to 11.4.5 but not before downgrade your 7100 to 11.4.4 and see if your problem goes away. 

John Wable