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.