MoH Combined with other Media Resources

As we mentioned earlier MOH uses G711 is the only supported codec by default (other codecs can be enabled from IPVMS service parameters).

Let’s assume the following scenario, HQ-Region (which contains HQ-Phones, HQ-Servers, HQ-MediaResources) and BR1-Region (which contains BR1-Phones, BR1-MediaResources). In case HQ-Region to BR1-Region codec definition is G729 (and vice versa) and MOH Server at HQ site should be used by BR1-Phones, then how MOH will work??

NOTE: Here we are assuming that BR1 Phones are registered with HQ CUCM, i.e. no trunks are available between sites.

The simple way is to enable G729 codec for MOH Server from IPVMS service parameters. The other way is through XCODER. When MoH is invoked CUCM will realize that MOH is using G711 while the inter-region configuration should use G729. Therefore, it will invoke XCODE based on MoH MRGL. MOH MRGL can be assigned to MOH Device Pool; else MOH will pick XCODE from the null group.

NOTE: When CUCM invoke MOH, new call negotiation will take place between MOH and Phone including TCS negotiation, OLC, etc.

If we consider that BR1 Phones are registered to another cluster, for example CME, and HQ Site is connected to BR1 Site through ICT (H323/SIP). If HQ Phone places BR1 Phone on hold what will happen??

NOTE: We are maintaining the same assumption that HQ-Region to BR1-Region relation is G729. In this case BR1-Region is assigned to ICT.

In this case, CUCM will allocate MOH server based on ICT MRGL. Either G729 codec should be enabled from MOH server from IPVMS service parameters or XCODER will be invoked. An important note is that whether the ICT is running SIP or H323, MTP Required should be always enabled to get the functionality, This isn’t mandatory but due to bug only.

With MTP, the output will look as,

NOTE: When MOH is invoked new call negotiation will take place between CUCM and CME over ICT including TCS and OLC negotiations.

HQ#sh call leg act su

G  L     Elog A/O FAX T Codec    type Peer Address     IP R:

G0     L 83       N   ORG     T10    g729r8   VOIP        P         142.2.66.254:17734

G0     L 85       N   ORG     T4     g729r8   VOIP        P         142.2.64.254:17672

G0     L 86       N   ORG     T4     g729r8   VOIP        P         142.2.64.254:17502

G0     L 88       N   ORG     T4     g711ulaw VOIP        P         0.0.0.0:0

The bug details are,

CSCso85618 Bug Details

No Audio when Call is put on hold by remote party over Sip Trunk

Symptoms:

1. The MOH does not work between CM and CME.

2. There is no audio on the CME endpoint when the remote CCM party resumes the call on hold, conferences, or transfers with another CCM endpoint (scenario: CME - CUBE - CCM).

Conditions:

Symptom 1 is observed if the phone registered to the CME is put on hold by the CM, then the CME phone does not hear the MOH.

Symptom 2 is observed if the CCM endpoint does a conference, hold, or transfer.

Workaround: Use an MTP.

Important

The following restriction exists for multicast music on hold (MOH) when a media termination point (MTP) is invoked. When an MTP resource gets invoked in a call leg at a site that is using multicast MOH, the caller receives silence instead of music on hold. To avoid this scenario, configure unicast MOH or Tone on Hold instead of multicast MOH.

CTI devices do not support the multicast Music On Hold feature. If a CTI device is configured with a multicast MOH device in the media resource group list of the CTI device, call control issues may result. CTI devices do not support multicast media streaming.