Question about MoH restarting vs resuming within a call

Unanswered Question
Sep 22nd, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jaime Valencia Tue, 09/22/2009 - 10:23
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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

bartoldus Tue, 09/22/2009 - 10:39
User Badges:

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


Jaime Valencia Tue, 09/22/2009 - 10:56
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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

bartoldus Tue, 09/22/2009 - 11:06
User Badges:

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?

Actions

This Discussion