The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Cisco Unified Communications functionality requires the use of media resources. Media resources provide services such as annunciator, transcoding, conferencing, music on hold, and media termination.
The media resource manager enhances Cisco Unified Communications Manager features by making Cisco Unified Communications Manager more readily able to deploy annunciator, media termination point, transcoding, conferencing, and music on hold services.
Cisco Unified Communications Manager media resource groups and media resource group lists provide a way to manage resources. Use these resources for conferencing, transcoding, media termination, and music on hold (MOH).
Media resource groups define logical groupings of media servers. You can associate a media resource group with a geographical location or a site as desired. You can also form media resource groups to control the usage of servers or the type of service (unicast or multicast) that is desired.
Media resource group lists specify a list of prioritized media resource groups. An application can select required media resources from among the available resources according to the priority order that is defined in the media resource group list. Media resource group lists, which are associated with devices, provide media resource group redundancy.
The following steps describe how to configure media resource groups and media resource group lists.
Media resource management provides access to media resources for all Cisco Unified Communications Managers in a cluster. Every Cisco Unified Communications Manager contains a software component called a media resource manager. The media resource manager locates the media resource that is necessary to connect media streams to complete a feature.
The media resource manager manages the following media resource types:
Music On Hold (MOH) server
Unicast conference bridge (CFB)
Media termination point (MTP)
Transcoder (XCODE)
Annunciator (ANN)
Trusted relay point (TRP)
The following reasons explain why resources are shared:
To allow both hardware and software devices to coexist within a Cisco Unified Communications Manager
To enable Cisco Unified Communications Manager to share and access resources that are available in the cluster
To enable Cisco Unified Communications Manager to do load distribution within a group of similar resources
To enable Cisco Unified Communications Manager to allocate resources on the basis of user preferences
Initialization of the Cisco Unified Communications Manager creates a media resource manager. Each media termination point, music on hold, transcoder, conference bridge, and annunciator device that is defined in the database registers with the media resource manager. The media resource manager obtains a list of provisioned devices from the database and constructs and maintains a table to track these resources. The media resource manager uses this table to validate registered devices. The media resource manager keeps track of the total devices that are available in the system, while also tracking the devices that have available resources.
When a media device registers, Cisco Unified Communications Manager creates a controller to control this device. After the device is validated, the system advertises its resources throughout the cluster. This mechanism allows the resource to be shared throughout the cluster.
Resource reservation takes place based on search criteria. The given criteria provide the resource type and the media resource group list. When the Cisco Unified Communications Manager no longer needs the resource, resource deallocation occurs. Cisco Unified Communications Manager updates and synchronizes the resource table after each allocation and deallocation.
The media resource manager interfaces with the following major components:
Call control software component performs call processing, including setup and tear down of connections. Call control interacts with the feature layer to provide services like transfer, hold, conference, and so forth. Call control interfaces with the media resource manager when it needs to locate a resource to set up conference call and music on hold features.
Media control software component manages the creation and teardown of media streams for the endpoint. Whenever a request for media to be connected between devices is received, depending on the type of endpoint, media control sets up the proper interface to establish a stream.
The media layer interfaces with the media resource manager when it needs to locate a resource to set up a media termination point or transcoding.
Media termination point (MTP) provides the capability to bridge an incoming H.245 stream to an outgoing H.245 stream. MTP maintains an H.245 session with an H.323 endpoint when the streaming from its connected endpoint stops. MTP supports the G.711 and G.729 codecs. MTP can also transcode G.711 a-law to mu-law. MTP also enables Early Offer on SIP trunks and Fast Start on H.323 trunks. MTPs also get dynamically inserted to perform DTMF transport translation for endpoints that do not support a common DTMF transport method.
The Media Resource Manager (MRM) provides resource reservation of transcoders within a Cisco Unified Communications Manager cluster. Transcoders comprise another media resource type that is hardware based and uses Digital Signal Processing (DSP). DSP resources also support MTP functionality. Cisco Unified Communications Manager supports simultaneous registration of both the MTP and transcoder and concurrent MTP and transcoder functionality within a single call. A transcoder takes the stream of one codec and transcodes (converts) it from one compression type to another compression type. For example, it could take a stream from a G.711 codec and transcode (convert) it in real time to a G.729 stream. In addition, a transcoder provides MTP capabilities and may be used to enable supplementary services for H.323 endpoints when required.
For each media termination point device and each transcoder that is registered with Cisco Unified Communications Manager, Cisco Unified Communications Manager creates a media termination point control process. This media termination point control process registers with the device manager when it initializes. The device manager advertises the availability of the media termination point control processes throughout the cluster.
An annunciator enables Cisco Unified Communications Manager to play prerecorded announcements (.wav files) and tones to Cisco Unified IP Phones, gateways, and other configurable devices. The annunciator, which works with Cisco Unified Communications Manager Multilevel Precedence and Preemption, enables Cisco Unified Communications Manager to alert callers as to why the call fails. Annunciator can also play tones for some transferred calls and some conferences.
For each annunciator device that is registered with Cisco Unified Communications Manager, Cisco Unified Communications Manager creates an annunciator control process. This annunciator control process registers with the device manager when it initializes. The device manager advertises the availability of the annunciator control process throughout the cluster.
A unicast bridge (CFB), more commonly known as a conference bridge, provides the capability to mix a set of incoming unicast streams into a set of composite output streams. Unicast bridge provides resources to implement ad hoc and meet-me conferencing in the Cisco Unified Communications Manager.
For each unicast bridge device that is registered with Cisco Unified Communications Manager, Cisco Unified Communications Manager creates a unicast control process. This unicast control process registers with the device manager when it initializes. The device manager advertises the availability of unicast stream resources throughout the cluster.
Music on hold (MOH) provides the capability to redirect a party on hold to an audio server. For each music on hold server device that is registered with Cisco Unified Communications Manager, Cisco Unified Communications Manager creates a music on hold control process. This music on hold control process registers with the device manager when it initializes. The device manager advertises the availability of music on hold resources throughout the cluster. Music on hold supports both unicast and multicast audio sources.
The Cisco Unified Communications system can be deployed in a network virtualization environment. Cisco Unified Communications Manager enables the insertion of trusted relay points (TRPs). The insertion of TRPs into the media path constitutes a first step toward VoIP deployment within a virtual network.
The underlying network infrastructure comprises one of the key shared assets in an overall network design. A number of customer use cases require support for network infrastructure virtualization, such as the following examples:
Guest internet access
Partner access
Departmental or divisional separation
Subsidiaries/mergers and acquisitions
Application segregation (data/voice)
All these applications include a requirement to maintain traffic separation on the network device as well as between network devices.
Traffic separation translates into concepts such as Virtual Routing and Forwarding (VRF). VRF allows multiple instances of a routing table to co-exist within the same router at the same time. In a virtualized network, these different routing domains, or VRFs, typically cannot communicate directly without transiting through the data center. This situation challenges applications such as Cisco Unified Communications, where devices in the data VRF domain, such as software endpoints running on PCs, need to communicate directly with hard phones in the voice VRF domain without hairpinning media in the data center and without directly exposing the voice and data VRFs to each other.
To solve the communication problem between PC-based softphones located in the data VRF domain and the hard phones located in the voice VRF domain without hairpinning media in the data center and without directly exposing the voice and data VRFs to each other, the system can insert a trusted relay point (TRP) in the media path between the softphone and hard phone, so both phones send/receive media to the TRP, and the TRP relays the media from one phone to another phone. The system allows only media that passes through the TRP between voice and data VRF domains.
A firewall currently must inspect the signaling of the call setup to open pinholes for Real-time Transfer Protocol (RTP) streams. Many deployments of firewalls exist in such a way that a customer can design their network, so only media go through the firewall, but not the signaling.
If a firewall has media termination point (MTP)/trusted relay point (TRP) functionality, Cisco Unified Communications Manager can insert the MTP/TRP in the media path, so the signaling does not have to go through the firewall for the RTP streams to traverse the firewall and at the same time be inspected at the firewall. The firewall receives signaling from Cisco Unified Communications Manager, which informs about the RTP traffic.
The firewall can allow this traffic because of the messaging from Cisco Unified Communications Manager, but the firewall does not have to allow this traffic if the firewall is so configured. If the local configuration on the firewall prevents these RTP streams, calls never start only to be dropped at the firewall interface. After a firewall receives indication that the stream comes from phones, that firewall can still inspect all the RTP streams to ensure that everything appears as it should between the two devices that are communicating and that someone is not trying to attack the phone system.
In a Cisco voice network, the switch detects Cisco Unified IP Phones that use Cisco Discovery Protocol (CDP), and the switch trusts the Differentiated Services Code Point (DSCP) marking of packets that the Cisco Unified IP Phones send. Because CDP is not secure and can easily be replicated from a PC, the switch generally does not trust the traffic that is coming from a PC. Because it is almost impossible to ensure that only Cisco Unified Communications Manager-authorized traffic will get marked with DSCP, the packets that come from a PC get re-marked to best effort.
To resolve this problem, Cisco Unified Communications Manager inserts a trusted relay point (TRP) in front of the softphone that runs on the PC, and the media stream from the endpoint can be forced to flow through the TRP. The TRP re-marks the DSCP according to instructions from Cisco Unified Communications Manager. The switch honors and trusts media packets that are sent from the TRP.
Cisco Unified Communications Manager uses the following service parameter with trusted relay points:
This service parameter, which is found in the Clusterwide Parameters (System - General) section, determines whether a call that requires a Trusted Relay Point (TRP) is allowed to proceed if no TRP resource is available. Valid values specify True (the call fails if no TRP resource is available) or False (the call proceeds regardless even if a TRP resource is not available).
The administrator should choose the best value for a system based on how the system uses TRPs. If a TRP is used for Quality of Service (QoS) enforcement, Cisco Unified Communications Manager can complete the call if a TRP resource is unavailable, but the call will not have the correct Differentiated Services Code Point (DSCP) marking.
From the Cisco Unified Communications Manager point of view, the trusted relay point (TRP) always gets placed closest to the endpoint device that requires it. The high-level requirements for TRP insertion follow:
The administrator configures the Use Trusted Relay Point check box in the Common Device Configuration window. The administrator configures the Use Trusted Relay Point drop-down list with On/Off/Default options in the configuration windows of all devices where media terminate, so Cisco Unified Communications Manager knows when to insert a TRP.
The administrator configures the Trusted Relay Point check box in the Media Termination Point Configuration and Transcoder Configuration windows. If the administrator checks this check box when configuring a particular device, Cisco Unified Communications Manager knows that it can use the device as a TRP. The administrator must ensure that a device that is configured as a TRP in Cisco Unified Communications Manager has the appropriate network connectivity and configuration between the TRP and any endpoints that are involved in the call. If the TRP is invoked but does not have the needed connectivity, an audio or video call will not succeed.
The service parameter, Fail Call If Trusted Relay Point Allocation Fails, applies. See the Trusted Relay Point Service Parameter for details.
Cisco Unified Communications Manager must insert a TRP for the endpoint if the Use Trusted Relay Point check box is checked for either the endpoint or the device pool that is associated with the device. The call may fail if Cisco Unified Communications Manager fails to allocate a TRP while the Fail Call If Trusted Relay Point Allocation Fails service parameter is set to True.
If both the Media Termination Point Required check box and the Use Trusted Relay Point check box are checked for the endpoint, Cisco Unified Communications Manager should allocate an MTP that is also a TRP. If the administrator fails to allocate such an MTP/TRP, the following table shows the call status, which the values of the Fail Call If Trusted Relay Point Allocation Fails service parameter and the Fail Call if MTP Allocation Fails service parameter also affect.
Fail Call If TRP Allocation Fails |
Fail Call If MTP Allocation Fails |
Fail Call? |
---|---|---|
True |
True |
Yes |
True |
False |
Yes |
False |
True |
Yes, if MTP is required for H.323 endpoint. No, if MTP is required for SIP endpoint. |
False |
False |
No |
If RSVP is enabled for the call, Cisco Unified Communications Manager should first try to allocate an RSVPAgent that is also labeled as TRP. Otherwise, another TRP device gets inserted between the RSVPAgent and the endpoint.
If a transcoder is needed for the call and needs to be allocated on the same side as the endpoint that needs TRP, Cisco Unified Communications Manager should first try to allocate a transcoder that is also labeled as TRP. Otherwise, another TRP device gets inserted between the transcoder and the endpoint.
Assuming that both the Fail Call If Trusted Relay Point Allocation Fails service parameter and the Fail Call If MTP Allocation Fails service parameter are set to False, the following table shows the call behavior in relationship to the MTP that is required and Use Trusted Relay Point settings and the resource allocation status.
MTP Required |
Use TRP |
Resource Allocation Status |
Call Behavior |
---|---|---|---|
Y |
Y |
TRP allocated |
Audio call only because no pass-through support exists. |
Y |
Y or N |
MTP only |
Audio call only. No TRP support. |
Y |
Y or N |
None allocated |
If MTP required is checked for H.323 endpoint, supplementary services will be disabled. |
N |
Y |
TRP allocated |
Audio or video call depends on endpoint capabilities, and call admission control (CAC). Supplementary services still work. |
N |
Y |
None allocated |
Audio or video call. Supplementary services still work, but no TRP support exists. |
Cisco Unified Communications Manager media resource groups and media resource group lists provide a way to manage resources. Use these resources for conferencing, transcoding, media termination, and music on hold (MOH).
Media resource groups define logical groupings of media servers. You can associate a media resource group with a geographical location or a site as desired. You can also form media resource groups to control the usage of servers or the type of service (unicast or multicast) that is desired.
After media resources are configured, if no media resource groups are defined, all media resources belong to the default group, and, as such, all media resources are available to all Cisco Unified Communications Managers within a given cluster.
Tip | Deactivating the Cisco IP Voice Media Streaming Application deletes associated devices (Annunciator, Conference Bridge, Music-on-Hold, and Media Termination Point) from media resource groups. If the deletion results in an empty media resource group, you cannot deactivate the service; in this case, you must delete the media resource group before deactivating the service. |
The following rules govern selection of a resource from a media resource group in a media resource group list:
Search the first media resource group in a media resource group list to find the requested resource. If located, return the resource ID.
If the requested resource is not found, search the next media resource group in the media resource group list. Return the resource ID if a match is found.
If no resource of the requested type is available in any media resource group in a media resource group list, the resource manager attempts to use the resource in the default group.
The default media resource group for a Cisco Unified Communications Manager comprises the following media resources: MOH1, MTP1, XCODE1, XCODE2, XCODE3. For calls that require a transcoder, this Cisco Unified Communications Manager distributes the load evenly among the transcoders in its default media resource group. The following allocation order occurs for incoming calls that require transcoders:
Call 1 - XCODE1 Call 2 - XCODE2 Call 3 - XCODE3 Call 4 - XCODE1 Call 5 - XCODE2 Call 6 - XCODE3 Call 7 - XCODE1
Media resource group lists specify a list of prioritized media resource groups. An application can select required media resources from among the available resources according to the priority order that is defined in the media resource group list. Media resource group lists, which are associated with devices, provide media resource group redundancy.
The following rules govern selection of media resource group lists:
A media resource group list, which is configured in the Media Resource Group List Configuration window, gets assigned to either a device or to a device pool.
Call processing uses a media resource group list in the device level if the media resource group list is selected. If a resource is not found, call processing may retrieve it from the default allocation.
Call processing uses media resource group list in the device pool only if no media resource group list is selected in the device level. If a resource is not found, call processing may retrieve it from the default allocation.
Assign all resources to three media resource groups as listed:
SoftwareGroup media resource group: MTP1, MTP2, SW-CONF1, SWCONF2
HardwareGroup media resource group: XCODE1, XCODE2, HW-CONF1, HW-CONF2
MusicGroup media resource group: MOH1, MOH2
Create a media resource group list called RESOURCE_LIST and assign the media resource groups in this order: SoftwareGroup, HardwareGroup, MusicGroup.
Result: With this arrangement, when a conference is needed, Cisco Unified Communications Manager allocates the software conference resource first; the hardware conference does not get used until all software conference resources are exhausted.
Assign resources to four media resource groups as listed:
DallasSoftware: MTP1, MOH1, SW-CONF1
SanJoseSoftware: MTP2, MOH2, SW-CONF2
DallasHardware: XCODE1, HW-CONF1
SanJoseHardware: XCODE2, HW-CONF2
CM1 and CM2 designate Cisco Unified Communications Managers.
Create a DALLAS_LIST media resource group list and assign media resource groups in this order: DallasSoftware, DallasHardware, SanJoseSoftware, SanJoseHardware
Create a SANJOSE_LIST media resource group list and assign media resource groups in this order: SanJoseSoftware, SanJoseHardware, DallasSoftware, DallasHardware.
Assign a phone in Dallas CM1 to use DALLAS_LIST and a phone in San Jose CM2 to use SANJOSE_LIST.
Result: With this arrangement, phones in CM1 use the DALLAS_LIST resources before using the SANJOSE_LIST resources.
Assign all resources to four groups as listed, leaving no resources in the default group:
MtpGroup: MTP1, MTP2
ConfGroup: SW-CONF1, SW-CONF2, HW-CONF1, HW-CONF2
MusicGroup: MOH1, MOH2
XcodeGroup: XCODE1, XCODE2
Create a media resource group list that is called NO_CONF_LIST and assign media resource groups in this order: MtpGroup, XcodeGroup, MusicGroup.
In the device configuration, assign the NO_CONF_LIST as the device media resource group list.
Result: The device cannot use conference resources. This means that only media termination point, transcoder, annunciator, and music resources are available to the device.
To find out which media resource group lists are associated with the media resource groups, click the Dependency Records link that displays in the Cisco Unified Communications Manager Administration Media Resource Group Configuration window. To find out more information about the media resource group list, click the record type, and the Dependency Records Details window displays.
To find out which phones or trunks are associated with media resource group lists, click the Dependency Records link that displays in the Cisco Unified Communications Manager Administration Media Resource Group List Configuration window.
If the dependency records are not enabled for the system, the dependency records summary window displays a message.