These deployment models cover scenarios in which Cisco IP phones are configured for media forking. Two versions are covered:

From the perspective of MediaSense, there is actually no difference between the two basic Unified Communications Manager versions. In both cases, media forked by a phone is sent to the recording device where the forked streams are captured. They are distinguished here because there is a significant difference in their function at the solution level.

Unified Communications Manager Deployment - Internal-to-External

The preceding diagram shows a basic Unified Communications Manager deployment for BiB forking where calls with parties who are outside the enterprise are recorded. This deployment applies to both inbound and outbound calls, as long as the inside phone is configured with an appropriate recording profile.

Once the connection is established from a signaling perspective, media flows directly from the forking phone to the recording server.

If the call is transferred away from this phone, the recording session ends. Only if the phone that takes up the call is configured for recording will the next segment of the call be captured.

Unified Communications Manager Deployment - Internal-to-Internal

This diagram shows a basic Unified Communications Manager deployment for BiB forking where calls are with parties who are inside the enterprise. One of the phones must be configured for recording. If both phones are configured for recording, then two separate recording sessions are captured.

In an Unified Communications Manager Session Management Edition (Unified CM SME) environment, all the phones that are to be recorded by a specific MediaSense cluster must be part of the same SME leaf cluster. If phones from different leaf clusters need to be recorded, then a separate and independent MediaSense clusters must be deployed, as shown in the illustration.

The illustration demonstrates how MediaSense clusters must be connected to Unified CM SME leaf clusters, not to the Unified CM SME manager cluster. The diagram also shows the leaf clusters connecting to separate MediaSense clusters, which is a supported arrangement.

This diagram shows that the recording calls using Network-Based Recording (NBR) is similar to recording calls using BiB, except that the media flows to MediaSense from the voice router rather than from the phone. The SIP signaling in both cases comes from Unified Communications Manager.

As with BiB recordings, if the call is transferred away from the phone whose conversation is being recorded, the recording session ends, despite the fact that the media continues to flow through the same voice router. Only if the phone that takes up the call is configured for recording (either BiB or NBR) will the next segment of the call be captured.

Note	NBR is not yet supported for inbound calls to Unified CCE.

The preceding diagram shows a very basic Unified Border Element deployment for dial peer forking where calls arrive on a SIP Trunk from the PSTN and are connected to a SIP phone inside the enterprise. The media forking is performed by the Unified Border Element device using a recorder profile configuration that is attached to one or more dial peers.

When a call passes through Unified Border Element (or any Cisco router), it matches two dial peers: one at the point where the call enters the Unified Border Element, and one at the point where it exits. In case of the Unified Border Element system, these are known as the inbound and outbound dial peers. These terms are relative to the direction of the call. On an inbound call, the inbound dial peer is the one that represents the outside of the enterprise and the outbound dial peer represents the inside of the enterprise. The assignment is reversed for an outbound call. In this document, we use the terms inside and outside dial peers to represent the inside and the outside of the enterprise, respectively.

Although there are a few exceptions, the best practice is to apply the recording profile to the outside dial peer: the inbound dial peer for inbound calls and the outbound dial peer for outbound calls. This is because the external leg of the call is typically quite stable, whereas the internal leg is often subject to complex call manipulations including various kinds of consults, conferences, and transfers. If any of those operations cause the Unified Border Element to trigger a new dial peer match, the recording session may be terminated prematurely. (If such an operation causes the prevailing codec to be changed, the recording session is terminated and a new one is initiated.)

This diagram also shows a Unified Communications Manager component. Though currently required for Unified Border Element deployments, Unified Communications Manager does not perform any call signaling, media, or record keeping. A single Unified Communications Manager server is required to manage and authenticate MediaSense API users. It can be any existing or specially installed Unified Communications Manager server on Release 8.5(1) or later. Ideally, the server selected should be one that is not itself loaded with calls.

The Unified Communications Manager server is omitted from the remaining Unified Border Element deployment model diagrams since it plays no part in call handling.

The basic Unified Border Element deployment is unlikely to ever be used in a production environment. More typically, a Unified Communications Manager, other Private Branch Exchange (PBX), or Automatic Call distributor (ACD) would be attached to the internal side of the Unified Border Element and phones would be attached to that rather than to the Unified Border Element directly. However, all Unified Border Element deployments contain this configuration at their core. From the strict perspective of Unified Border Element and MediaSense, all the other models are no different from this one.

Basic Unified Border Element Deployment with Various PBXs for Dial Peer Recording

One of the great advantages of using Unified Border Element to fork media is its ability to capture the entire conversation from the caller perspective, no matter where the call goes inside the enterprise. This includes contact center agents, non-contact center personnel, IVR systems, and even users on non-Cisco ACD and PBX systems.

The preceding diagram shows three ways that MediaSense and Unified Border Element may be deployed in a heterogeneous enterprise environment. Any given call might experience one or a combination of these flows and the entire caller experience will be recorded. Additional combinations are possible as well; for example, a call may be handled by an IP-based or TDM-based IVR system.

Unified Border Element Deployment Variation Using TDM Ingress for Dial Peer Recording

In order to fork media, Unified Border Element must be dealing with a SIP to SIP call. If calls are arriving by TDM, then a separate TDM gateway is provisioned as shown in the diagram. Forking is then configured as usual on the outside dial peer of the Unified Border Element.

If your application is designed to transmit DTMF signals to the PSTN, such as to perform PSTN-controlled transfers (also known as *8 Transfer Connect), then you must ensure that both the Unified Border Element and the TDM gateway are configured to use the same method for DTMF signaling. You can do so by adding the same dtmf-relay configuration to the connecting dial peers in both devices. Relay type rtp-nte is the most standard, preferred method. The dial peer going to CVP should also be configured with rtp-nte.

When Unified Border Element is connected to Unified Customer Voice Portal (Unified CVP), MediaSense can be used to record calls in a contact center. The following subsections describe these models:

Unified CVP deployments typically involve a VXML function and optionally a TDM to IP conversion function. Unified CVP deployment recommendations sometimes provide for combining those two functions on the same ISR. There are also Unified CVP deployments that involve incoming SIP trunks rather than TDM lines. These deployments can use Unified Border Element routers and they can also host the VXML function. Unified CVP also includes an optional component, Call Survivability, which allows branch routers to continue to provide a degraded level of service to callers even if the WAN connection between the router and Unified CVP is out of service. This component is implemented as a TCL-IVR application installed directly on each gateway and associated with a dial peer.

Unified CVP deployments with Unified Border Element media forking must manage up to four distinct activities:

• TDM to IP conversion
• Call survivability
• Media forking
• VXML browsing

Some of these activities conflict with each other at the dial peer level, and certain steps must be taken in order to ensure that they interact well together. For example, you must not configure both media forking and a TCL or VXML application on the same dial peer. Each activity uses resources on the router, so they must all be considered for sizing. You can technically configure one router to provide all four capabilities, which is acceptable in low call volume scenarios. But as call volume rises, you must move either VXML browsing or media forking to a separate device. These two functions must not be co-located.

The function to isolate depends on your needs. VXML takes the bulk of router resources (especially if Automatic Speech Recognition is being used) and its sizing calculation is based on a different (usually smaller) quantity of calls than are the other activities. For the convenience and simplicity of sizing calculations, isolating VXML is a good choice.

However, if your intent is to capture only the agent part of the call in your recordings (see the Additional Deployment Options and Considerations section), the required configuration is simpler if you perform media forking on a separate router. This configuration has an additional advantage in that co-locating TDM-to-IP, Call Survivability, and VXML browsing on a single router is the most common configuration for branch offices in a Unified CVP deployment.

In multisite ingress deployments, especially branch office deployments, you must use a combination of Significant Digits and Send To Originator functions in Unified CVP's call routing configuration in order to prevent calls from inadvertently traversing a WAN link.

See the Unified CVP documentation for more information about these techniques.

Note

During normal processing of SIP messages, Unified CVP inserts arbitrary data into the SIP content as a multi-part body. This format is currently not supported by MediaSense, nor is the content of interest to MediaSense. The recording dial peer in Unified Border Element must be configured to prevent this content from being forwarded to MediaSense by adding the command "signaling forward none" to the recording dial peer. If the same physical router is being used for both MediaSense and Unified CVP, it must be running a version of Cisco IOS that has been qualified by both products. Except in the simplest of scenarios, contact the ISR sales team for capacity planning.

Unified Border Element Deployments for Dial Peer Recording with Unified CVP — SIP Trunks, No Survivability

In this scenario, Unified CVP manages all call control operations including an initial delivery to a VXML gateway for Music on Hold or other treatments, a subsequent delivery to a Unified Contact Center Enterprise (Unified CCE) agent, and possible further network transfers to other agents and devices. All segments of the call are recorded.

When properly configured, Unified CVP affects these transfers by issuing SIP invitations to the destination device rather than to Unified Border Element. This effectively re-routes the media without triggering a new dial peer match in Unified Border Element.

As with most scenarios, media forking is configured on the outside dial peer.

Unified Border Element Deployments for Dial Peer Recording with Unified CVP — SIP Trunks, with Survivability

This scenario is identical to the preceding one except that the customer has elected to use the Unified CVP Survivability script to manage call failures and time-of- day routing. To use the Unified CVP Survivability script, place it on the outside dial peer in Unified Border Element. Cisco IOS does not allow a script and media forking to occur on the same dial peer, however, so use the inside dial peer for media forking (as shown in the diagram). Configuring recording on the inside dial peer is risky because of the possibility that call manipulation may inadvertently trigger Cisco IOS to start a new dial peer matching operation. This operation terminates the current recording session.

When properly configured, Unified CVP affects these transfers by issuing SIP invitations to the destination device rather than to Unified Border Element. This transfer prevents Unified Border Element from triggering a new dial peer match.

Note

If survivability is initiated to handle a mid-call failure of any kind, any audio played by that script (such as a technical difficulties message) cannot be recorded by MediaSense. But if the script transfers the call to a local phone, that conversation can be recorded if the local phone's dial peer is configured for media forking.

For information about REFER transfers, see the Additional Deployment Options and Considerations section.

Unified Border Element Deployments for Dial Peer Recording with Unified CVP — TDM Trunks

A TDM MediaSense Unified Border Element deployment for Unified CVP is just like a SIP trunk deployment, except that a logically separate TDM gateway is placed ahead of the Unified Border Element. Unified Border Element still does the media forking on the outside dial peer and Unified Border Element still acts as the router that Unified CVP interacts with.

If survivability is used, it is placed on the POTS dial peer in the TDM gateway; not in the Unified Border Element. This placement keeps the media forking on the outside dial peer in Unified Border Element.

If Unified CVP is issuing DTMF tones to the PSTN (as in "*8 Transfer Connect" transfers), configure either dtmf-relay sip-kpml or dtmf-relay sip-notify on both ends of the call connection between the TDM gateway and the Unified Border Element.

Unified Border Element Deployments for Dial Peer Recording with Unified CVP — Outbound Dialer

Outbound campaigns using the Unified CCE SIP outbound dialer are configured to directly instruct the TDM gateway to call the target phone number. Once a party answers and the answering machine detection algorithm determines that the answering party is a real person, the dialer instructs the TDM gateway to connect the call using Unified Border Element to Unified CVP. From the perspective of Unified Border Element and MediaSense, this appears the same as any another inbound call.

The outbound dialer is connected to the TDM gateway; not to the Unified Border Element.

Redundant Media Forking Using Unified Border Element Dial Peer

Normally, you would apply the recording profile to the outside dial peer, the one that represents the side of the call which is external to the enterprise. It is also possible to configure media forking on both dial peers in a given call, which results in two independent recording sessions. The dial peers must be configured to deliver recordings to two separate and independent MediaSense clusters, implementing true recording redundancy. However, doing so severely impacts the performance of the Unified Border Element. For sizing purposes, the Unified Border Element call-carrying capacity should be assumed to be cut in half.

Percentage Recording

Compliance recording, by definition, means that every call gets recorded. However, some applications do not require that 100 percent of calls be recorded; in some cases spot-checking is sufficient.

Using Unified Border Element, it is possible to record a pseudo-random sample of calls. This recording is accomplished by configuring multiple identical dial peers, and assigning them equal preference values, but only configuring a subset of them for media forking. For example, you could record roughly one out of every three calls by configuring three identical inbound dial peers at preference level 5 and configuring media forking for only one of them.

Omitting the VRU Segment From a Recording

This applies to contact center recording where Unified CVP is used for call routing.

By forking media from Unified Border Element, you can record the entirety of the caller's experience. This recording includes not only his or her conversation with one or more agents, but also any VRU or call-queuing activity that may occur before the call is ever delivered to an agent. Forking media from Unified Border Element can even be used to record the VRU activity if no agent is ever included in the call.

Some customers may want to omit the pre-agent VRU activity from the recording, particularly if it consists primarily of Music on Hold. One way to do this is by forking media from the agent's phone rather than from Unified Border Element. But, if you need to fork media from Unified Border Element for other reasons, you can accomplish this by causing Unified CVP to route the agent segment of the call back through the Unified Border Element. You need to separate the ingress and media forking function from one another to do this, which means that you must either route the call through the ingress router a second time, or route it through a second router.

Both routing approaches require more hardware, but using a second router makes the configuration considerably easier. If your PSTN connection is TDM-based, you must route calls through the router a second time (or route them though a second router) anyway. Therefore, the remainder of this section assumes that the media forking router is separate from the ingress router, that the ingress router can be either a TDM gateway, or an IP-only Unified Border Element, and that the VXML function is running on the ingress router.

With a normal Unified CVP configuration, when an agent becomes available, Unified CVP sends a SIP invitation to the Unified Communications Manager that controls that agent's phone. Unified Communications Manager negotiates with the ingress router to connect the media stream from the router to the agent's phone. The ingress router itself never gets involved in routing that segment of the call because it never needs to figure out what IP address handles the selected agent's extension.

This arrangement is shown in this diagram.

Unified CVP also can be configured so that the agent-segment invitation gets sent to the ingress router rather than to the Unified Communications Manager. The configuration can be done using Local Static Routes, an Outbound Proxy Server, or with Locally Resolved DNS SRV. You cannot configure the sending of the invitation by checking the Enable Send Calls to Originator box in Unified CVP's Dialed Number Pattern Configuration; that setting is only observed during the SendToVRU operation; not during the delivery to the agent. Once Unified CVP is configured, you can define a dial peer in the ingress router that is specifically for routes to agent extensions with Unified Communications Manager as the destination target.

This arrangement is shown in the following diagram.

To add media forking, insert a second router, a Unified Border Element, to do the media forking, as shown in the following diagram.

The situation becomes more complex when you have multiple ingress sites, but the goal is still achievable using a combination of Unified CVP's Send Call to Originator and Significant Digits capabilities to avoid hair-pinning calls across the WAN. Send Call to Originator allows Unified CVP to ensure that any given call's own ingress router is where its VXML activity is performed. Significant Digits can be used to ensure that when the call is delivered to an agent, it passes through a Unified Border Element that is in the same site as the call's own ingress router. Significant Digits can also be used to localize VXML activity to any VXML-capable router at the ingress router's site, rather than being limited to the ingress router itself. The following diagram shows the final arrangement in a multi-ingress site scenario. In one site, we show two ingress gateways and one Unified Border Element for media forking. The two ingress gateways are identical; both are performing TDM-to-IP conversion and VXML functions. In the other site, the same number of routers is shown, but one router is used for TDM-to-IP conversion and a second router is dedicated to VXML activity.

Regardless of the configuration, bandwidth usage must always be considered. In the design in the diagram, media flows twice over the WAN: once to and from the agent's phone, and a second time from the media forking Unified Border Element to the MediaSense cluster. If you co-locate MediaSense with the Unified Border Element, there is no problem. But if your deployment calls for centralizing MediaSense in a shared data center, then you must consider this extra bandwidth usage. In order to avoid the extra WAN traffic, you can also move the media forking Unified Border Element to the data center where MediaSense is located. This movement can only work if your Unified Communications Manager cluster and your agent's phones are all in the same WAN location. Otherwise, you will end up causing more WAN traffic rather than less, since you cannot force calls to pass through a Unified Border Element, which is co-located with the selected agent's phone. Media streams will frequently hairpin first through a Unified Border Element that is located where the agent is not. This technique also has the potential to confuse Unified Communication Manager's Call Admission Control (CAC) algorithm.

REFER Transfers

By default, Unified Border Element passes a REFER transfer from Unified CVP on to the next upstream user agent. Once that transfer succeeds, Unified Border Element is no longer in the signaling or media path and therefore cannot further record the call. If your deployment environment permits it, you can configure Unified Border Element to "consume" the REFER transfer rather than pass it on. This consumption results in Unified Border Element executing the transfer, taking Unified CVP out of the loop, but keeping Unified Border Element in the signaling and media path and recording the call. You can accomplish this by adding "voice service voip; no supplementary-service sip refer" to your Unified Border Element configuration.

Note	If the inside dial peer is doing the media forking, then a REFER will always terminate the recording because it forces Cisco IOS to perform a new dial peer match operation.

Combining Deployment Models

The deployment models described in this document are not exclusive of each other. Any typical installation may have some

• Inbound calls

• Outbound calls

• Calls that use Unified CVP

• Calls that are not part of a contact center

• Calls that use TDM trunks

• Calls that use SIP trunks

• Calls that fork media in Unified Border Element

• Calls that fork media at the phone

Generally speaking, the models here should be seen as describing the path that any one particular call may follow, while other calls may follow the paths that are covered in other deployment models. In that sense, all of these models may be combined indiscriminately, though usually any single call remains within one single model.

Combining TDM to IP Conversion with Dial Peer Media Forking

By definition, only a SIP-to-SIP call can fork media in a Unified Border Element. However, there is no reason that you cannot insert T1/E1 cards into an ISRG2 running Unified Border Element software. Calls that arrive on a TDM port can be recorded if they are routed through the device twice: once as a TDM-to-SIP call, and once as a SIP-to-SIP call. The recording of calls that arrive on the TDM port can be accomplished by configuring the device's outbound dial peer of the TDM-to-SIP call to specify itself in its session target parameter. By using some digit manipulation or other means of qualifying the call, the second time that the call arrives it matches a different (VoIP) dial peer and resembles a SIP-to-SIP call. On this second pass through the router, media forking can be enabled.

In this flow, the call gets handled by the router twice, and therefore counts as two calls from a capacity perspective. Put the other way around, calls which follow this flow will effectively halve the stated capacity of the router, which requires twice as much router capacity for the same number of calls. If you intended to use the full capacity of the router for calls, you need two routers. When you double the number of routers, you can either have all routers do both jobs (TDM and forking) or have half the routers do each job. Either approach may be used if engineered correctly.

For more information about ISR configuration, see https:/​/​supportforums.cisco.com/​docs/​DOC-23115.

Combining VXML with Unified Border Element Media Forking

In Unified CVP deployments without MediaSense, it is possible to run VXML voice browser functions on the same router as Unified Border Element, but Cisco does not support sharing media forking and VXML activities on the same router. VXML, especially with automatic speech recognition, uses a lot of the router's resources. Sizing also is a challenge because with media forking you must consider the total number of concurrent calls being handled, whereas for VXML you only consider the number of concurrent calls that are expected to be in queue or in IVR scripts.

In multisite ingress deployments, especially branch office deployments, this means that Unified CVP must be configured to use SigDigits functionality rather than SendToOriginator, in order to prevent calls that are in queue from inadvertently traversing a WAN link.

for more information about these techniques, see the Unified CVP documentation.