04-06-2014 07:46 AM - edited 03-21-2019 08:11 AM
Hello,
I try setup the Hunt Pilot to serve incoming calls. The problem is when caller come into queue he hear:
1. Initial Announcement - ok
2. Not full MOH music but cycle of the first 10 seconds of music. - here is my problem!
3. Periodic Announcement - ok
I cannot figure out why full MOH doesn't work - any ideas?
Thanks,
Dmitry.
Solved! Go to Solution.
04-07-2014 10:04 AM
Hi Dmitry,
As per the following link
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/fsgd-712-cm/fsmoh.html
The MOH feature causes any party that gets placed on hold to hear the same point of the audio source that is streaming, regardless of when the party is placed on hold.
If you are using the MOH to deliver a spoken announcement when a party is placed on hold, the standard MOH configuration can create a problem. Users do not hear the announcement from the beginning, except for the first party that gets placed on hold: other parties join the announcement (audio source) in progress.
Both multicast and unicast configurations present the same audio-source behavior to held parties. Each audio source gets used once, and the stream gets split internally and gets sent to the held parties. The only difference between multicast and unicast, in this case, is how the data itself gets sent over the network.
Thus, basic MOH configuration is unsuitable for playing announcements that users must hear from the beginning.
HTH
Manish
04-06-2014 08:11 PM
Hi Dmitry,
Is it set up a unicast or multicast?
Have you tried applying this MOH audio source file on an IP phone and test it internally? Does it give the same results?
HTH
Manish
04-07-2014 05:22 AM
Hi Manish,
Thanks for reply and direction.
This is should be unicast, at least I did not set up multicast.
I tried test internally and have found that problem was in the CUBE dialpeer. I fixed it and now it is almost ok.
Why almost ok - because the first caller in the queue hear music from its beginning but the second caller and others hear the same as the first one.
I thought that each caller should hear the "own" music stream from the beginning because in is unicast. Isn't it?
Thank you,
Dmitry
04-07-2014 10:04 AM
Hi Dmitry,
As per the following link
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/fsgd-712-cm/fsmoh.html
The MOH feature causes any party that gets placed on hold to hear the same point of the audio source that is streaming, regardless of when the party is placed on hold.
If you are using the MOH to deliver a spoken announcement when a party is placed on hold, the standard MOH configuration can create a problem. Users do not hear the announcement from the beginning, except for the first party that gets placed on hold: other parties join the announcement (audio source) in progress.
Both multicast and unicast configurations present the same audio-source behavior to held parties. Each audio source gets used once, and the stream gets split internally and gets sent to the held parties. The only difference between multicast and unicast, in this case, is how the data itself gets sent over the network.
Thus, basic MOH configuration is unsuitable for playing announcements that users must hear from the beginning.
HTH
Manish
04-07-2014 12:02 PM
Hi Manish,
Thanks a lot, now it is clear. However it is sad to know MOH isn't suitable for speech announcements.
Dmitry.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide