Call Manager

It is software application that controls voice gateways & IP phones. Call manager runs on unified
computing system (UCS) hardware. Software running on VM is referred as call manager server.
Multiple call manager servers can be grouped into cluster for scalability & fault tolerance. Call
manger communicate with gateway using SIP & MGCP; with IP Phone using SIP, SCCP; with
ICM using JTAPI.

Communication between two IP Phones

Call manager uses SIP or SCCP to communicate with IP Phones for call setup & tear-down
tasks. When called party picks up the ringing phone, call manager completes the call setup;
media exchange is started between IP Phones across IP network using RTP. Call manager is not
involved in any call processing after the call has been setup unless soft key is initiated.

Even if the call manager is down the calls would survive. But the users cannot use the features
on the phone. CM Down, Features Disabled message is appeared on screen of the phone when
call manager is down.

SCCP phones sends their dialed digits to call manager as they are pressed (digit by digit)
whereas SIP phones sends their dialed digits, digit by digit or in one message depending on
generation of IP Phone.

Clustering
Call manager supports clustering of servers to provide HA & scalability. DB redundancy is
provided by sharing common DB replicated across call manager servers. Call manager cluster
can have up to 20 servers in it. Cluster consists of 1 publisher which maintains read/write copy of
call manager DB. Publisher replicates DB as read-only DB to up to 8 subscribers. Each cluster
has restriction of 4 subscribers that can perform active call processing. Additional 4 subscribers
are dedicated standby servers in case of active subscribers are not available. The additional 11
servers in cluster are responsible for various services like TFTP, Media Resources (such as MoH,
conferencing, transcoding) & integration with third party applications through API.

Multiple call manager servers in cluster maintain active TCP port 2000 connection to both
primary & backup call manager server. Call manager uses IDS LDAP DB to store user
information.

Types of Clustering

Single Site
Multisite with centralized call processing
Multisite with distributed call processing
Clustering over the WAN

IP Phone boot up process

1. The PoE switch sends a small DC voltage on Ethernet cable detects an unpowered
devices & supplies power to the line.
 2. Phone boots software image.
3. The switch delivers voice VLAN information to IP phone using CDP.
4. The IP phone sends DHCP request on its voice VLAN. The DHCP server replies with IP
addressing, subnet mask, default gateway, TFTP server address information including
DHCP Option 150, which directs the IP phone to the TFTP server.
5. The IP phone contacts the TFTP server & downloads its configuration file & firmware.
6. Based on IP address listed in the configuration file, the IP phone contacts the call
processing server (Call Manager or CME router) which supports VoIP functions.

Step 1. Assuming that the IP Phone is connected to a Cisco Catalyst switch that is capable of
providing Power over Ethernet (PoE), using Fast Link Pulse (FLP), the switch detects an
unpowered IP Phone and powers it up using Cisco proprietary standard (provides .48 V DC at up
to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6).
Step 2. Every IP Phone has nonvolatile flash memory in which it stores firmware image(s). At
startup, the IP Phone runs a bootstrap loader that loads an available phone image stored in flash
memory. Using this image, the IP Phone initializes its software and hardware.
Step 3. As the IP Phone receives power and boots, the switch sends a Cisco Discovery Protocol
(CDP) packet to the IP Phone. This CDP packet provides the IP Phone with voice VLAN (also
known as auxiliary VLAN) information so that the IP Phone can reach the appropriate VLAN
and initiate a DHCP request.
Step 4. The IP Phone sends a broadcast request such as a DHCP discover message to the DHCP
server in the voice VLAN. The DHCP server replies with an IP address, a subnet mask, a default
gateway, and the IP address of the Cisco TFTP server. There could be additional optional
parameters as well. However, at a minimum, these steps are required for IP Phone connection.
Step 5. The IP Phone contacts the Cisco TFTP server or external TFTP server to request
firmware and files. The TFTP server sends the configuration information for that IP Phone,
which contains an ordered list of up to three CUCM servers or two CUCM servers and an SRST
reference. If the IP Phone was manually preconfigured in CUCM, the SEP<MAC
address>.cnf.xml file is downloaded for that phone. Otherwise, the XMLDefault.cnf.xml
configuration file is used for IP Phones that request auto-registration.
Step 6. The .cnf.xml file indicates the firmware load that the IP Phone should be running. If this
image load differs from the one that is currently on the IP Phone, the phone contacts the TFTP
server to request the new firmware load file, which has a .bin file extension. The IP Phone
installs the firmware in its nonvolatile RAM and reboots.
Step 7. After rebooting, the IP Phone downloads other information such as the softkey template
and phone button template. The IP Phone attempts to make a TCP connection to a CUCM server
that is considered the highest priority in its list. The phone registers to the CUCM server and
obtains a directory number (DN).

Q. From where will the phone get new firmware?

A. TFTP server.
Q. What is phone hardening?

A. Phone Hardening is nothing but disabling some of the features on the phone, for example,
disabling the web access http/https, disabling the phone settings to the end users, disabling the
voice VLAN access settings and disabling the PC port setting. You can do it by accessing the
Phone device or by using the BAT tool.

Calling Search Space (CSS) & Partition

What is Partition?

Partition comprises logical grouping of directory numbers & route patterns with similar
reachability characteristics. Devices that are typically placed in partitions include DNs & route
patterns. These entities associate with DNs that users dial.

What is CSS?

CSS comprises of ordered list of partitions that users can look at before users are allowed to
place call. CSS determine the partitions that calling devices, including IP phones, softphones &
gateways, can search when attempting to complete call.

When CSS is assigned to device the list of partitions in CSS comprises only partitions that device
is allowed to reach. All other DNs that are in partitions that are not in device CSS receives busy
signal.

CSS-PARTITION Rule:
Call will be established if & only if PARTITION of CALLED PARTY is present in a CSS of
CALLING PARTY.

Line/Device CSS methodology:

The traditional approach can result in a large number of partitions & CSSs when applied to large
multisite deployments with centralized call processing. This configuration is required because
the device CSS is used to determine both the path selection which PSTN gateway to use for
external calls & the class of service.

It is possible to significantly decrease the total number of partitions & CSS needed by dividing
these two functions between the line CSS & the device CSS, in what is called the line/device
approach.

The following rules are applicable to the line/device approach:

1. Use device CSS to provide call routing information (e.g. which gateway to select for
PSTN calls)
2. Use line CSS to provide class-of-service information (e.g. which calls to allow)
Q. So if call is permitted on the line CSS but blocked on the device CSS is the call routed or
blocked?

A. The call is routed because both line CSS & device CSS are concatenated.

Q. My phone has line CSS & device CSS. I have the same exact pattern in a partition in my
line CSS & in a partition in my device CSS. Which pattern takes precedence?

A. If two or more numeric plan entries (like DNs, route patterns or so forth) have exact pattern
or overlap, call manager selects the entry with closest match to DN. In cases where two dial plan
entries match dialed plan pattern equally, call manager selects the dial plan entry that appears
first in the CSS of device making call.

Q. I have all the phone numbers within my organization in the same partition. How can I
grant the phone access to call these numbers?

A. Move that partition in calling parties CSS.

Q. The partition which contains all of my organizations phone numbers could either be
placed in a CSS on the line or a CSS on the device. Which one should I use & why?

A. The line CSS & device CSS are contaminated by call manager so you can use either CSS (line
or device) no matters.

Q. How are partitions & CSS used in dial plan?

A.

CUCM SIP Trunk:

Trunk is a communication channel on call manager that enables call manager to connect to other
servers. Using trunk call manager can receive or place voice, video calls, exchange real-time
event information & communicate with call control servers.

SIP trunk provides connectivity to other SIP devices such as gateways, SIP proxies, & other call
manager clusters.

SIP Offer / Answer model:

Call Manager uses SIP Offer/Answer model for establishing SIP sessions. Offer is contained in
the SDP fields sent in the body of SIP message. The offer typically defines media characteristics
(codecs, IP address & UDP port for RTP) supported by device. The device receiving offer sends
an Answer in the SDP fields of its SIP response with its corresponding matching media stream,
codec, IP address, UDP port for RTP. Once the Offer & Answer have been exchanged two way
media can be established between calling & called endpoints.
There are two ways that SDP messages can be sent in the Offer/Answer EO & DO.
In EO, calling device sends its capabilities in SDP body contained in the initial INVITE thus
allowing called device to choose codec for session.
In DO, calling device does not send its capabilities in the initial INVITE but waits for called
device to send its capabilities first.
EO & DO are the two options available for media capabilities exchange. By default, SIP trunks
are configured as DO. SIP based Cisco IP Phones send EO.

Provisional Reliable Acknowledgement (PRACK):

SIP defines two types of responses to SIP Requests as Final Responses & Provisional Responses.

Final Responses such as 2XX, 3XX & 4XX Responses convey result of processed request such
as INVITE & are sent reliably which means they are acknowledged.

Provisional Responses (1XX) provides info on the progress of request, but they are not sent
reliably so sender does not know that it has been received. For this reason SDP info is not sent in
unreliable 1XX responses.

PRACK is extension to SIP protocol that allows 1XX responses to be sent reliably. It provides
reliability of 1XX responses can also be used to reduce no of SIP messages that need to be
exchanged before setting up two way media. PRACK can be used over SIP trunks using EO or
DO & it is often called Early Media.