One Way Audio Path After Retrieval from Hold

[itsthephoneguy]

I have two control units connected by a voip line. When connected, if a user places a connected call on hold and then attempts to retrieve it, the user who placed the call on hold can hear the person at the far end, but the far end user can't hear the user who placed the call on hold. This system is almost entirely comprised of IP Phones (VOIP exts). Any ideas on a resolution?

 

[BoyRacer1001]

Sounds like a diect media issue - possibly a mismatch on the IP phones or trunks.
oing on/off hold the phones have to recreate the speech path, which could fail one way with a direct media mismatch.

 

[IPhello]

Don't know what release you are running, but this is a known issue and was fixed in 3.2(53). I would try reading this.

http://support.avaya.com/elmodocs2/ip_office/tech/Global_IP_Office_Technical_Bulletin_Number_73.pdf

 

[jameshen]

We had this exact same issue running 3.1.65

Check your VoIP tab for your Extensions. The "Default" setting for "Allow Direct Media Path" is ENABLED.

One of the installers had disabled that setting on all of our extensions. With that setting disabled, it didn't matter how we configured the VoIP lines. We still had the one-way voice problem after placing calls on hold.

After re-enabling the default on the extensions, we had no issues placing calls on hold across the VoIP lines.

Enjoy...

 

[itsthephoneguy]

jameshen

You are correct. All VOIP extensions have Allow Direct Media Path DISABLED. This was done to stop a "Dead Air" issue on calls between extensions over VOIP lines. If a user called an extension over the VOIP line, ringing could be heard on both ends, but upoin connecting there would be silence. How will making the changes to 802.1Q effect that?

 

[jameshen]

Turning off 802.1Q will fix the dead air issue, without having to disable "Allow Direct Media Path" on the extensions. And, restoring "Allow Direct Media Path" to its default setting will fix the hold issue.

I know..I know..everytime you change an extension it causes the dreaded reboot. So just test it on a couple phones at first. Add a test user at each site, but don't allow it to automatically create the extension. If you manually add an extension, you can tweak the settings and still merge the changes. (If you try to change an existing extension, its going to want a reboot.) Then change the 802.1Q setting on each test phone and login with test user/extension. Once you finish testing, you'll know if its worth the pain of changing all the extensions and doing a full reboot.