cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
643
Views
0
Helpful
4
Replies

BE6000 (9.1.2.10000-28) - MOH on Hunt Pilot Queue - Just first 10 seconds and repeat.

Dmitry Blinov
Level 1
Level 1

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.

 

1 Accepted Solution

Accepted Solutions

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

 

View solution in original post

4 Replies 4

Manish Gogna
Cisco Employee
Cisco Employee

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

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

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

 

Hi Manish,

Thanks a lot, now it is clear. However it is sad to know MOH isn't suitable for speech announcements.

Dmitry.