MOH Issues and Resolution

There are quite a few issues which you may come across while configuring Music on Hold.

As of SRST/ITS 3.0 an IOS branch gateway has the capability to function as a multicast Music on Hold (MoH) resource. This allows for a distributed MoH design where MoH at remote sites is provided by the local gateway, which can save valuable bandwidth by not having to stream MoH across the WAN.

The MoH capabilities of IOS are very simple. IOS can be configured to permanently multicast RTP packets from an audio file stored locally on flash. This multicasting/streaming is not under the control of CCM, in fact CCM is not even aware of the fact that an IOS MoH resource exists in the network. By configuring IOS MoH to multicast to the same multicast IP address and port as that used by CCM, we can simply block multicast packets originated by CCM, and phones and gateways at a remote site will instead pickup the identical packets being multicast by the local branch gateway.

Note that IOS MoH works for multicast MoH only. Unicast MoH is not supported.

CUCM Checks:

• The Communications Manager configuration must be designed appropriately.  This involves enabling multicast MoH, and configuring Media Resource Groups (MRG) and Media Resource Group Lists (MRGL) to control which devices get multicast and which get unicast MoH. It also involves assigning Regions so that g711 is used whenever an IOS MoH resource is being invoked.
• On the “Music On Hold (MOH) Server Configuration” tick the Enable Multicast Audio Sources on this MOH Server box. Note that this MoH server can still unicast MoH, we are just expanding it’s capabilities to include multicast MoH. Specify a base for the IP multicast address and port numbers. For example IP address 239.1.1.1 and port 16384.

		Inc. Multicast on IP Address		Inc. Multicast on Port Number
Audio Stream	Codec	Dst. IP Address	Dst. Port	Dst. IP Address	Dst. Port
1	G.711 ulaw	239.1.1.1	16384	239.1.1.1	16384
1	G.711 Alaw	239.1.1.2	16384	239.1.1.1	16385
1	G.729	239.1.1.3	16384	239.1.1.1	16386
1	Wideband	239.1.1.4	16384	239.1.1.1	16387
2	G.711 ulaw	239.1.1.5	16384	239.1.1.1	16388
2	G.711 Alaw	239.1.1.6	16384	239.1.1.1	16389
2	G.729	239.1.1.7	16384	239.1.1.1	16390
2	Wideband	239.1.1.8	16384	239.1.1.1	16391

• On the “Music On Hold (MOH) Audio Source Configuration” select audio source number 1. Tick the Allow Multicasting box. This will allow this audio source to be used for multicast MoH. Note that it can still be used simultaneously for unicast MoH.
• It is important to realize that only a single audio source can be used throughout the network when IOS MoH is used.. Even if you have 500 sites and only one site is using IOS MoH you are subject to this restriction.
• Place the MRGL with Multicast MOH Group in Device Pool or Remote Gateway
• IOS MoH supports G.711 only. So it is critical that CCM be configured to open up a G711 MoH connection when a device at the remote branch is placed on hold.
• First test the MOH from CUCM. Even with an IOS MoH resource present the CCM MoH configuration that we have just put together must work. If the WAN is multicast enabled then placing a remote IPhone and/or gateway on hold is the ultimate test to validate the configuration.  If the WAN is not multicast enabled then it will not be possible for the CCM MoH server to stream MoH to the remote device. In this case the second best test is to place an IPhone on the same subnet as the CCM MoH server and verify that Moh can be heard. Since the phone and MoH server are on the same subnet no multicast routing capabilities in the network are required.
• Use perfmon to verify that the MoH you are hearing is provided via multicast and not unicast. Since unicast MoH is enabled by default it is easy to mistakenly conclude that multicast MoH is working when in fact it is not. Monitor the MOHMulticastResourceActive and MOHUnicastResourceActive counters under the Cisco MOH Device performance object. The multicast counter must be the one incrementing in order for IOS MoH to later work.

IOS & Gateway Checks:

• The IOS MoH gateway must be running 12.2(15)ZJ2, or 12.3(2^nd)T and later when available.
• Copy the desired MoH audio file to flash on the gateway. The MOH file can be in .wav or .au file format, but must contain 8-bit 8 kHz data, such as a-law or u-law data format.  A known working MoH audio file (music-on-hold.au) is included in its-3.0.1.zip and srst-3.0.zip, which can be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key
• Configure the music on hold commands as described in previous MOH section.

Troubleshoot IOS MoH to PSTN:

• If the PSTN caller on hold hears tone on hold (ToH) instead of MoH, then one can conclude that a configuration exists on the CCM side. CCM has failed to activate MoH and has used ToH as a last resort. In this case use the trouble shooting guidelines described in the CCM section.
• If the PSTN caller on hold hears complete silence, then one can conclude that the problem lies on the IOS or network side. In this case CCM has successfully completed the multicast MoH handshaking with the GW, but the gateway is failing to pick up the locally generated multicast RTP stream. In this case use the ‘show ccm-manager music-on-hold’ command to troubleshoot as described below.

HQ#show ccm-manager music-on-hold

Current active multicast sessions : 1

Multicast Address	RTP Port Number	Packets In/Out	Codec	Incoming Interface
239.1.1.1	16387	326/326	42	G711ulaw L

• If no MoH streams are shown by this command then CCM has failed to provide the gateway with MoH. In this case you’ll normally hear tone on hold instead. The typical cause for this is CCM not having an appropriate MoH resource available. This could be because the required codec is has not been enabled on CCM (check the service parameters). Or it could be because no MRGL has been assigned to the gateway, or if one has been assigned then it has insufficient resources. Check the Event Viewer for error message
• The IP address and port number above is the MoH source that IOS has been directed to listen to by CCM. Make sure that these match those configured in IOS MoH with the multicast moh command.
• The ‘show ccm-manager music-on-hold’ command shows only PSTN connections on hold. It does not show multicast streams going to IPhones on hold. When an IPhone is placed on hold, and the MoH is sourced from an IOS gateway, the MoH signaling is directly between CCM and IPhone. In this scenario the IOS gateway plays no role other then to blindly stream multicast RTP packets to the IPhone.
• Keep in mind that hearing MoH does not necessarily mean that multicast IOS MoH is working as expected. If the PSTN caller hears MoH, but ‘show ccm-manager music-on-hold’ shows no active multicast streams, then the MoH is coming from a unicast. This can be confirmed by checking the MoH perfmon counters as discussed earlier.
• Check that the remote IP address is MOH Multicast IP

HQ#show call active voice | include RemoteMedia
RemoteMediaIPAddress=239.1.1.1
RemoteMediaPort=16384

Troubleshoot IOS MoH to IP Phones:

• When an IPhone is placed on hold, and the MoH is sourced from an IOS gateway, the MoH signaling takes place directly between CCM and IPhone.
• The IOS gateway places no other role than to blindly stream multicast RTP packets to the IPhone.  So other than verifying that the IOS gateway is streaming multicast RTP packets out the Ethernet interface where the IPhones reside, there is no other troubleshooting that can be performed on the gateway.
• In order to verify that CCM is correctly signaling the IPhone to listen for multicast MoH, place the IPhone on hold. Then check the MOHMulticastResourceActive and MOHUnicastResourceActive counters under the Cisco MOH Device performance object. The multicast counter must be the one incrementing in order for IOS MoH to later work.
• If MoH signaling looks OK, but no MoH is heard, connect a sniffer to the PC port on the back of the port. If the IPhone and IOS MoH gateway are connected to the same subnet then multicast RTP packets should be seen here at all times, even when the IPhone is not placed on hold. If IPhone and IOS MoH gateway are not connected to the same subnet then, then multicast RTP packets are only seen when the IPhone is placed on hold and sends an IGMP join to the closest router.