Transferring call to MiCC results in dead air

[VinceWhirlwind]

I wonder if there is anything I can configure differently to avoid this issue.
external caller---->1234 call is answered
1234 uses MiCollab to add 5000 to the call (MiCC hunt group).
::::At this stage the external caller is hearing hold music and the user on 1234 can hear the MiCC playing a menu.
1234 presses the transfer button.
::::At this stage the call is connected but the external caller hears dead air until the conclusion of the msg that the MiCC was playing when 1234 initiated the connection. As soon as the MiCC callflow reaches the next msg event, the external caller  hears that msg and proceeds as normal.

I can kind of see what's happening. The external call to 1234 is being mediated by the MCD.
The connection started by 1234 to the MiCC is *not* mediated by the MCD.
When 1234 transfers its call, its connection to MiCC drops and is re-established via the MCD.
--> the question is, why does the msg not continue to be played over this re-established connection?

[eugenej]

trunk type?

Are you sure your the dead air bit is not just your message is on the blink? encoding, file format etc etc. Can you phone it internally, can you do the call scenario purely as an internal scenario?

As a test, run a trace on the IVR>miCC and see if it is actually sending any audio at the time when you expect it to. if it is, what is the destination IP, can you listen to it (in other words is it audible and not just dead air as you indicated.)

Good luck

[johnp]

might add a pause first to let the transferring ext to get out before it plays

[Tech Electronics]

VinceWhirlwind,

If the connection between them is a SIP connection then have you looked at the Early Media setting?

I know nothing of the MiCC and barely anymore on the 3300, but this issue has been seen on the MiVO-250 with similar results and it is usually an Early Media setting.

Thanks,

TE

[VinceWhirlwind]

Are you sure your the dead air bit is not just your message is on the blink? encoding, file format etc etc. Can you phone it internally, can you do the call scenario purely as an internal scenario?

No, the message continues to play fine so long as it isn't transferred from an internal call to an external one.
This scenario involves people who have rung a number assigned to a live human but what they really need is to be put through to the Contact Centre. The vast majority of callers ring the Contact Centre freecall number correctly.
 

might add a pause first to let the transferring ext to get out before it plays

That was one thought I had - if the initial message (it's actually a big long menu option) was instead a series of several very short messages, then the caller being transferred wouldn't notice any dead air. Not ideal though. I guess this is where I could insert a series of short msgs using Ralph's beep tone.
 

If the connection between them is a SIP connection then have you looked at the Early Media setting?

I know nothing of the MiCC and barely anymore on the 3300, but this issue has been seen on the MiVO-250 with similar results and it is usually an Early Media setting.

Cool, a clue...let me have a look into it...