Multicast music on hold conserves system resources. Multicast allows multiple users to use the same audio source stream to provide music on hold. Multicast audio sources associate with an IP address.
Unicast music on hold, the system default, uses a separate stream for each user or connection. Users connect to a specific device or stream.
An MoH audio source may be configured with an initial (greeting) announcement which will be played to unicast held parties. For unicast MoH users, this announcement will be heard from the beginning. For multicast users this announcement will not be heard.
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.
A MoH audio source may be configured with a periodic announcement that is inserted in the basic MoH audio on a configurable periodic interval. This announcement is heard by both unicast and multicast users. However, the user may be inserted into the MoH audio stream at a point when this announcement is in the middle of being played. This is dependent on whether other held users are already hearing the MoH audio source.
For administrators, multicast entails managing devices, IP addresses, and ports. In contrast, unicast entails managing devices only.
For multicast, administrators must define at least one audio source to allow multicasting. To define music on hold servers for multicast, first define the server to allow multicasting.
For multicast, an address comprises a combination of an IP address and a port number. Each audio source for multicast requires a set of addresses: one for each format on each MoH server. When configuring the MoH server for multicast, specify whether addresses should be assigned by incrementing the port or the IP address.
Cisco strongly recommends incrementing multicast on IP address instead of port number to avoid network saturation in firewall situations. If you follow this recommendation, each multicast audio source has a unique IP address, and you help to avoid network saturation.
The Max Hops field in the Music On Hold (MoH) Server Configuration window indicates the maximum number of routers that an audio source is allowed to cross. If max hops is set to zero, the audio source must remain in its own subnet. If max hops is set to one, the audio source can cross up to one router to the next subnet. Cisco recommends setting max hops to two.
A standards body reserves IP addresses. Addresses for IP multicast range from 18.104.22.168 to 22.214.171.124. The standards body, however, assigns addresses in the range 126.96.36.199 to 188.8.131.52 for public multicast applications. Cisco strongly discourages using public multicast addresses for music on hold multicast. Instead, Cisco recommends using an IP address in the range that is reserved for administratively controlled applications on private networks (184.108.40.206 to 220.127.116.11).
Valid port numbers for multicast include even numbers that range from 16384 to 32767. (The system reserves odd values.)
Multicast functions only if both media resource groups and media resource group lists are defined to include a multicast music on hold server. For media resource groups, you must include a music on hold server that is set up for multicast. Such servers get labeled as (MOH)[Multicast]. Also, check the Use Multicast for MOH Audio check box when you define a media resource group for multicast.
For media resource group lists, which are associated with device pools and devices, define the media resource group list, so the media resource group that is set up for multicast is the first group in the list. This recommended practice facilitates the device efforts to find the multicast audio source first.
In music on hold processing, the held device (the device placed on hold) determines the media resource to use, but the holding device (the device that initiates the hold action) determines the audio source to use.
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.
Multicast MoH Direction Attribute for SIP Service Parameter
The Multicast MoH Direction Attribute for SIP service parameter determines whether Cisco Unified Communications Manager sets the direction attribute of the Session Description Protocol (SDP) in its multicast Music on Hold (MoH) INVITE message to sendOnly or recvOnly.
If your deployment uses SIP phone loads 8.4 and earlier for Cisco Unified IP Phones 7940 and 7960, or SIP phone loads 8.1(x) and earlier for Cisco Unified IP Phones 7906, 7911, 7941, 7961, 7970, and 7971, set this parameter to sendOnly. Otherwise, leave this parameter set to the default value, recvOnly.