Use "Hold" to recover audio

[drichter12]

We have an issue we can't seem to isolate. This is a new install and we are getting intermittent calls with no audio "have verified all gateway settings" and have found that on those calls you can place the call with no audio on hold and then take it off hold and the audio is there.

System Info:
3 MXe Controllers being used as trunking gateways and 1 MXe Server for ACD/Agents. All systems are running 9.0.2.18.

Anyone have any ideas?

Thanks,

Dale

 

[tlpeter]

Routing issue
When you put the call on hold and then get the call back the mxe does the routing

ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[YnotPhone]

Is the dead audio at the beginning of the call, or does the audio quit in the middle of the call?
Technically Hold does nothing to the audio, other than suspending a call temporarily before retreiving it back to a set.


When using analog telephone trunks, there is an Answer Supervision Timer that can prevent audio from establishing a call at the beginning, after answering the call.

 

[drichter12]

Additional info:

The "no audio" condition is at the beginning of the call. We have alsso tried just waiting for audio to start coming through and it never does.

The issue occures on about 1 out of 10 calls and does not trace back to only one controller or T1.

We have verified gateway address and subnet on each E2T card as well as each RTC card.

We have verified no routing loops on network.

All inbound calls are on PRI.


Thanks,

Dale

 

[kwbMitel]

Is the problem global or only affecting certain sets. Are the sets IP or TDM?

I've seen issues with phones using headsets that cause your symptoms.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[drichter12]

All phones have headsets and are 5324IP sets.

The phones are at 2 different locations with the equipment at a 3rd and the problem is global.

Dale

 

[IrwinMFletcher]

Let me guess, SIP trunks?

 

[drichter12]

There are some SIP trunks involved. We have sip trunks between the IVR (Voice4Net) and the Mitels.

Dale

 

[kwbMitel]

On the site where I had this issue, the headsets were connected in the wrong jack. Only Non-Amplified headsets should be connected in the Headset jack. For Amplified headsets they should be connected to the Handset Jack. Once all of my phones were correctly connected the audio issue went away.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

When you put someone on hold using a SIP trunk, it renegotiates to a brand new stream. So the original call transfer failed (one-way audio), the switch to Hold changed the streaming (it's now not trunk to set, but system to set), then the Retrieve settled back onto a negotiation that both sides liked.

So what is the call scenario that gets the one-way audio? What trunks/devices are involved? In the end I think you'll need to look at the SIP signalling to find out the problem for sure....

 

[drichter12]

Most of these calls do not pass over the SIP trunks (do not go through the IVR).

We can eliminate headset issues due to the randomness of the problem. x12345 may get 5 good calls in a row then 1 bad one then 2 good then 1 bad etc and all calls coming in through the same trunks and routing scheme.



Dale

 

[kwbMitel]

I disagree, my issue was random as well until I corrected the headset connections. It can't hurt to try.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

Can you give a rundown of the exact call path?

 

[slapin]

Are those calls coming from ICP or some of them from extension to extension? Have you seen the problem when you dial an extension at the same site or between sites?

Are those calls being forwarded from other extensions, from autoattendant or DID?