Intermittent one way audio (and it isn't the network, probably)

[Jeremy Parr]

Ok, I know, been posted millions of times before, the one way audio issue that is always due to network issues. In this case I have my doubts - but would love to be proved wrong.

Two sites, and an IP Office at each site running 11.1.1.1.0.18. At site A we have 9608 stations, and at site B we have 1408 digital stations. Connecting these sites is an IPSec tunnel across the internet, with full access between the VLANs on both sides. We can ping all day long with <1% packet loss, at about 15ms. A SIP trunk is set up to connect the two sites. With or without "Re-invite Supported" and "Allow Direct Media Path" we sometimes experience one way audio. It always exhibits itself as site A not being able to hear site B.

I've deployed a 9608 at site B, registered to the phone system at Site A, and this seems work 100%, haven't had any issues with audio path.

In another failure mode I've seen, calling from Site B to Site A, I'll dial the extension number, hear ringing in the phone I'm dialing from, the remote phone will ring, but despite being answered I'll continue hearing ringing in the phone I called from - with obviously silence at the remote end.

We have a single IPSec tunnel between the sites, no failover. All inspection etc has been turned off on the IPSec tunnel, so we shouldn't have anything being blocked. In another thread here I see reference to someone experiencing similar issues, and apparently identified it as a bad VCM card.

https://www.tek-tips.com/viewthread.cfm?qid=1715305

Any suggestions would be appreciated, very much banging by head against a wall on this one.

 

[Jeremy Parr]

Also, interestingly, I'll see alarms in the IP Office Status tool for the SIP trunk between the sites - despite having a ping running at the same time with zero loss.

 

[critchey]

If it is a VCM channel issue I would expect to see VCM channel congestion in system status. You can look there to see if there has been any VCM congestion.

Have you tried turning off "allow direct media path" on the 9608's extensions on Site A and testing afterwards? If that works it 100% points at a networking issue but is usually a good test.






The truth is just an excuse for lack of imagination.

 

[Jeremy Parr]

I didn't turn off direct media path on individual phones, no. Wouldn't unchecking "Re-invite Supported" on the SIP trunk accomplish the same thing?

 

[critchey]

No they are different settings. Taken from manager help:

Allow Direct Media Path
Default = On
This settings controls whether IP calls must be routed via the system or can be routed alternatively if possible within the network structure.

If enabled, IP calls can take routes other than through the system, removing the need for system resources such as voice compression channels. Both ends of the calls must support Direct Media and have compatible VoIP settings such as matching codec, etc. If otherwise, the call will remain routed via the system. Enabling this option may cause some vendors problems with changing the media path mid call. Disabling the extension’s Requires DTMF setting above allows it to attempt direct media even if the other phone has differing DTMF settings.

If disabled, the call is routed via the system. In that case, RTP relay support may still allow calls between devices using the same audio codec to not require a voice compression channel.


Re-Invite Supported
When enabled, Re-Invite can be used during a session to change the characteristics of the session. For example when the target of an incoming call or a transfer does not support the codec originally negotiated on the trunk. Requires the ITSP to also support Re-Invite. This setting must be enabled for video support.


The truth is just an excuse for lack of imagination.

 

[jamie77]

If you have SIP between the site, is ALG disabled? It shouldn't matter as its over an IPSec, but SonicWalls used to mess with SIP inside a VPN. Cuased all sorts of issues.

I would be getting a pcap from either or both systems of a failed call cpaturing the SIP trunk (assuming you are not encrypting this). See if the speech is not reaching the other end, or the the local IPO is just not sending it.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer