09-22-2009 10:16 AM - edited 03-15-2019 07:50 PM
Problem:
When placing a call on hold, the other party hears MoH. If the same call is placed on hold several times, the MoH audio is supposed to resume at the point where it was stopped when the previous time on hold ended. Sometimes this works and sometimes the audio starts from the beginning of the file. There is no rhyme or reason to when it decides to resume from last point on hold or restart from the beginning. We have varied the time off hold before placing the call on hold again and can't find a pattern for when music decides to resume or restart. Thoughts?
Environment:
- CUCM 6.1(3) on all servers
- 5 UCM servers (1 pub, 2 subs, 2 tftp/moh servers)
- Only outside calls are configured for MoH
- Both MoH servers are registered
- Unicast
09-22-2009 10:23 AM
That's not correct, when using unicast the stream ALWAYS start from the beginning of the file
When using multicast you'll start hearing it from whatever point was playing at the time
HTH
java
if this helps, please rate
09-22-2009 10:39 AM
ok that makes sense. But, why would the file not start from the beginning each time a call is placed on hold? Why would it start in the middle of the file sometimes when you place the call on hold and other times start over? Would it have to do with other calls being on hold at the same time?
In other words...
no OTHER calls on hold: When a call is placed on hold --> start the file from beginning
1 or more OTHER calls on hold: When a call is placed on hold --> Begin listening to the file at the same place where all the OTHER calls are currently listening
09-22-2009 10:56 AM
That's not the way it should work, once you press hold you tear down the connection to the phone and create a 1 way path to the MOH server which should recognize it's a new MOH request and start streaming from the beginning.
You would need to look at CUCM and IPVMS traces to find out exactly what's going on, or open a TAC case so they can troubleshoot why MOH server is not streaming from the beginning every single time.
It would make sense with multicast as you simply join to whatever was being streamed at the time, but unicast should create a new stream every time you put a call on hold. By what you're saying it appears that it's trying to reuse an already working stream for the MOH.
HTH
java
if this helps, please rate
09-22-2009 11:06 AM
perhaps this is because when another call has a user on hold, the connection is already established on the trunk (remember MoH is only configured for external callers, not internal calls) it won't create multiple connections on the same trunk?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: