Remove 0.6 second music on hold before connecting to a queue

[ecom2]

Remove 0.6 second music on hold before connecting to a queue

I have noticed that when you call an IVR, and press 1 for example for queue , the moh play for 0.5 - 0.6 second first then it connect to a queue moh. the little 0.5 gap really annoys.. is there a way to fix it?

if i use a blank moh audio file, then there will be no moh on any call at all.

thanks

 

[eddv123]

This is an ever so slight delay which I think may just be the behavior of when a call is transferred to a queue.

As a test if you change the polling strategy does this change anything ?

 

[ecom2]

This is an ever so slight delay which I think may just be the behavior of when a call is transferred to a queue.

As a test if you change the polling strategy does this change anything ?

Well, It does bother to hear few second of a music then suddenly start queue music.

Changing to which polling? i tried all and same.

 

[eddv123]

Yeah it's putting you on hold before transferring.

What is your call flow? SIP trunk straight to queue or via IVR?

 

[ecom2]

they way it put on hold before it transfer sound horrible. caller may think its an audio issue..

call flow has nothing to do with it, i tired pstn gateway to ivr.. sip to ivr, dial the ivr from an extension. all produce same issue. i tried it on cloud 3cx, on premise and all same.

 

[YiannisH_3CX]

Hello @ecom2

This is the default behaviour of the system as during the transfer the system will place the caller on hold until the transfer is complete. Because the transfer is to a queue where the queue manager answers the call and plays its own music on hold you hear this difference.
As this is the default behaviour there is no way to change it so i would recommend creating a feature request on https://www.3cx.com/community/forums/3cx-ideas/ . All posts are reviewed by their corresponding Departments and, if feasible and voted for by other users as well, may be implemented in an upcoming service pack or update.

 

[ecom2]

Hello @ecom2

This is the default behaviour of the system as during the transfer the system will place the caller on hold until the transfer is complete. Because the transfer is to a queue where the queue manager answers the call and plays its own music on hold you hear this difference.
As this is the default behaviour there is no way to change it so i would recommend creating a feature request on https://www.3cx.com/community/forums/3cx-ideas/ . All posts are reviewed by their corresponding Departments and, if feasible and voted for by other users as well, may be implemented in an upcoming service pack or update.

Thanks YiannisH, For posting in ideas, i have seen a couple of partner here posted same issue and never heard anything about it.

So if this is the normal behavior to be on hold then transfer to queue, is there a way at least to extend the 0.5 second on hold? let me know. thanks

 

[YiannisH_3CX]

So if this is the normal behavior to be on hold then transfer to queue, is there a way at least to extend the 0.5 second on hold? let me know. thanks

This is not configurable as there is no option to delay the Queue manager from answering the call.

 

[ecom2]

This is not configurable as there is no option to delay the Queue manager from answering the call.

Alright Thanks