Cisco Article DirectoryAll about Cisco

Distributed Call
Processing

Distributed Call
Processing

Most optimum
design because it ensures that only traffic that must traverse the high latency
link does...

Provides the best users experience

_{This reduces
bandwidth across the wan}

This can handle
intermittent links better than a centralized environment

It doesn't take much special knowledge...

Optimizations
discussed for H.323 and SIP gateways/trunks in the centralized section applies
directly to this model

■ Optimizations
for management of IOS Devices also apply to both the Centralized and
Distributed Models

BRKVVT-2602_c1 © 2009 Cisco Systems,
Inc. All rights reserved.                                                   Cisco
Public 31

Centralized Call Processing

Dealing With High Delay Paths and Large Bit Error
Rates

Unified Communications
Core: Network Services

_TFTP

MAC Address:
001956A6A7ED

Phone
Configuration, Firmware Download

The time to
complete each file transfer via TFTP is predictable as a function of the file
size, the percentage of TFTP packets that must be retransmitted, and the
network latency or round-trip time.

At first glance,
network bandwidth might seem to be missing from the previous statement, but it
is actually included via the percentage of TFTP packets that must be
retransmitted. This is because, if there is not enough network bandwidth to
support the file transfer(s), then packets will be dropped by the network
interface queuing algorithms and will have to be retransmitted.

TFTP operates on
top of the User Datagram Protocol (UDP). Unlike Transmission Control Protocol
(TCP), UDP is not a reliable protocol, which means that UDP does not inherently
have the ability to detect packet loss. Obviously, detecting packet loss in a
file transfer is important, so RFC 1350 defines TFTP as a lock-step protocol. In
other words, a TFTP sender will send one packet and wait for a response before
sending the next packet.

If a response is
not received in the timeout period (4 seconds by default), the sender will
resend the data packet or acknowledgment. When a packet has been sent five
times without a response, the TFTP session fails. Because the timeout period is
always the same and not adaptive like a TCP timeout, packet loss can
significantly increase the amount of time a transfer session takes to complete.

Because
the delay between each data packet is, at a minimum, equal to the network
round-trip time, network latency also is a factor in the maximum
throughput that a TFTP session can achieve.

If the round-trip
time is increased to 40 ms and one packet has been lost in
transit. While the error rate is high at 12%, it is easy to
see the effect of latency and packet loss on TFTP because the time to complete
the session increased from 30 ms to 4160 ms.

Effect of Packet
Loss on TFTP Session Completion Time

■ Use the
following formula to calculate how long a TFTP file transfer will take to
complete:

FileTransferTime(seconds) = FileSize(bytes) * [(RTT(ms) + ERR(%) * Timeout(ms)) / 512000]

^{Avoiding TFTP Over Long Delay Links}

CUCM Device Load
Server Option

■

■

■

■

By configuring the "Load Server"
option phones can avoid the long delay path by download their firmware from an
on-site TFTP Server instead of the CUCM TFTP Server.

Configuration
files are still downloaded from the CUCM TFTP

Server

The on-site TFTP
Server isn't part of the CUCM Cluster and can be any standards based TFTP
Server including the local IOS based Router.

Firmware files
must be uploaded to the TFTP Server manually. However, a TCP based file
transfer is now possible.

^{Avoiding TFTP Over Long Delay Links}

Peer-to-Peer
Image Distribution

■

The PPID
feature optimizes firmware upgrades in branch deployment scenarios over
bandwidth-limited WAN links. It is also valuable in high-speed campus LAN
settings by limiting the congestion on TFTP transfers to centralized TFTP
servers, and it can eliminate the need for rolling resets and other forms of
manually controlling firmware upgrades.

■ When enabled,
PPID allows the phone to discover similar phones on the subnet that are requesting
the files that make up the firmware image and to automatically assemble
transfer hierarchies on a file-by-file basis.

■
Only the root phone in the hierarchy retrieves the
individual files that make up the firmware image from the TFTP server, and the
files then are rapidly transferred down the transfer hierarchy to the other
phones on the subnet by using TCP connections.

■
Configure PPID from the Phone Configuration window by
using the Peer Firmware Sharing settings in the Product-Specific Configuration
Layout. This menu option indicates whether the phone supports PPID. Settings
include enabled or disabled (the default). Configure per device via QED, and
apply on multiple phones via BAT

■ Default is
'Disabled'

Centralized Call Processing

Dealing With High
Delay and Large Bit Error Rates

■

■

■

■

■

High Delay Call showing the following
issues Cut-thru delay UI issues/digit by digit delay Packet loss...

Will ask the
audience for what some of the problems where and write them down on the
whiteboard.

Agenda

■ Endpoint
Sluggishness

■ Front
End-Clipping and Cut-Thru Delay

■ Packet Loss

RTT

SoftKeyEvent(NewCall) SetRinger
SetSpeakerMode

SetLamp

Ack CallState

SelectSoftKeys ActiveCallPlane

StartTone
KeyPadButton

StopTone

SelectSoftKeys

■ Every press of a
digit, line, or soft-key and every on-hook or off-hook event of the phone is
transmitted to the CUCM server for processing.

■ The phone must
wait for a response from the CUCM server before it provides visual or audio
feedback of the current state.

■ High amounts of
latency

between the CUCM
and the device will make the phone seem "sluggish."

■ Ensure that the
MTU is set appropriately (PMTUD, or Static) to bundle as many messages in a
packet as possible

RTT

Invite

100 Trying

Subscribe

200 OK

Notify

200 OK

Notify

200 OK

Notify

200 OK

Notify

200 OK

180 Ringing

■ SIP Phones
require less interaction with the CUCM for changes to the user interface
(visual, audio) based on user input.

■ Most Cisco SIP
Phones utilize KPML by default to provide digit-by-digit dial-plan analysis at
the CUCM similar to SCCP devices.

■ High amounts of
latency between the CUCM and the device should be less noticeable with a Cisco
SIP Device because of the reduced interaction

■ To further
enhance the user experience and control bandwidth over the wan link SIP Dial
Rules can be configured on the CUCM

^{Digit Collection}

_{Dial Rules and KPML}

Local Dial Rules are configured in Cisco
Unified Communications Manager and automatically downloaded to the phone via
TFTP

Phone collects
all digits and sends

them enbloc to the Cisco Unified

Communications Manager

Syntax varies
based on which of the two device groups your phone fall in to.

Some SIP Devices don't support dial-rules
or KPML and a "dial" key must be pressed similar to a mobile phone
before the device sends digits to CUCM.

BRKVVT-2012
provides more information on SIP Devices, KPML, and Dial-Rules.

Agenda

■ Endpoint
Sluggishness

■ Front
End-Clipping and Cut-Thru Delay

■ Packet Loss

Cut-Thru Delay or Front End Clipping

k o o

^f-f

О

Cut-thru delay is
the amount of time it takes from when a phone is answered to when the phone
starts capturing audio to send to the calling side.

The length of
time between answering the call and starting to speak can very based on if the
user is using a handset, headset, or speakerphone.

500ms for
"Anstime" is a best practice to budget when a user is using a
handset. Lower values will be required for headsets and speaker-phones.

Calculating
Cut-Thru Delay

Unified CM

Calling Device

_m

RTT Side B

RTT Side A

Called Device

-------- Ring

Л----- Answer

Л Stage 1

-------- Stage 2

Messages before
the call are answered are not used in the calculation of cut-thru delay.

Stage 1 prepares
the devices to be in a call and negotiates the type of codec to be used in the
call. Stage 2 must wait until Stage 1 is completed for both sides of the call.

Stage 2 sends the final negotiated
parameters to the called device and tells it to start transmitting media to the
calling device.

The number of
protocol interlocking steps in each stage times the RTT will dictate the
cut-thru delay.

RTT Called

RTT Calling

1.5)

SoftKeyEvent

SetRinger

OpenReceiveChannel

SetSpeakerMode
SetLamp

StopTone CallState

Ack

Select

CallState

ORCAck

ActiveCallPlane

SetRinger

StopTone

OpenReceiveChanne

StopTone

CallState

_к

If
stage1(calling) takes longer than stage1(called), the delta time is added to
the cut-thru delay

Select

1.5)

ORCAck

SMTransmission

CallInfov2

DisplayPromptStatus
CallInfo StopTone

Round Trips = 2

SMTransmissionAck

SMTransmission

SMTransmissionAck

Round Trips = 1