19.07.2013 Views

Cisco Unified Contact Center Enterprise Solution Reference ...

Cisco Unified Contact Center Enterprise Solution Reference ...

Cisco Unified Contact Center Enterprise Solution Reference ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Unified</strong> CCE Network Architecture Overview<br />

RSVP<br />

11-6<br />

<strong>Cisco</strong> <strong>Unified</strong> <strong>Contact</strong> <strong>Center</strong> <strong>Enterprise</strong> 7.x SRND<br />

Chapter 11 Bandwidth Provisioning and QoS Considerations<br />

you to specify keep-alive parameters on a per-connection basis. For <strong>Unified</strong> ICM public connections, the<br />

keep-alive timeout is set to 5∗400 ms, meaning that a failure can be detected after 2 seconds, as was the<br />

case with the UDP heartbeat prior to Release 5.0.<br />

The reasons for moving to TCP keep-alive with QoS enabled are as follows:<br />

In a converged network, algorithms used by routers to handle network congestion conditions can<br />

have different effects on TCP and UDP. As a result, delays and congestion experienced by UDP<br />

heartbeat traffic can have, in some cases, little correspondence to the TCP connections.<br />

The use of UDP heartbeats creates deployment complexities in a firewall environment. The dynamic<br />

port allocation for heartbeat communications makes it necessary to open a large range of port<br />

numbers, thus defeating the original purpose of the firewall device.<br />

<strong>Cisco</strong> <strong>Unified</strong> CallManager 5.0 introduces support for Resource Reservation Protocol (RSVP) between<br />

endpoints within a cluster. A protocol for Call Admission Control (CAC), RSVP is used by the routers<br />

in the network to reserve bandwidth for calls.<br />

To calculate bandwidth usage before RSVP was introduced, it was necessary for each CallManager<br />

cluster to maintain local counts of how many active calls traversed between locations. If more than one<br />

<strong>Cisco</strong> <strong>Unified</strong> CallManager cluster shared the same link, it was necessary to dedicate bandwidth for each<br />

cluster, leading to inefficient use of available bandwidth.<br />

RSVP solves this problem by tracing the path between two RSVP agents that reside on the same LAN<br />

as the phones. The RSVP agent is a software media termination point (MTP) that runs on <strong>Cisco</strong> IOS<br />

routers. The RSVP agents are controlled by <strong>Cisco</strong> <strong>Unified</strong> CallManager and are inserted into the media<br />

stream between the two phones when a call is made. The RSVP agent of the originating phone will<br />

traverse the network to the RSVP agent of the destination phone, and reserve bandwidth. Since the<br />

network routers keep track of bandwidth usage instead of CallManager, multiple phone calls can traverse<br />

the same RSVP controlled link even if the calls are controlled by multiple CallManagers.<br />

Figure 11-2 shows a scenario in which two different CallManager clusters provide service to phones at<br />

the same remote site. This may occur if a CallManager cluster is assigned to handle an IP call center. In<br />

the scenario, two users at the same office are serviced by different clusters. RSVP offloads the bandwidth<br />

calculation responsibilities of CallManager to the network routers.<br />

OL-8669-05

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!