Products Free Apps Clients Partners Blog Contacts Support

Aurus Blog
CUCM Traces Analysis: CUCM Architecture
This blog is to share our
expertise in Cisco UCM,
UCCX/UCCE and Cisco
Telepresence.
24.08.2016 15:01:47

This is another guest post that we nd quite useful for our Popular Posts
readers. The author discusses brie y the CUCM architecture in Call Tracing in CUCM Using
order to understand better the CUCM traces. RTMT
Deprecated Cisco IP
CUCM is a C++ application working on the Red Hat Linux OS. Phones in CUCM 14

There are SDL (Signal Distribution Layer) processes within the Time of the Day Routing in
CUCM
application interacting with each other. Some of these objects
CUCM 12: What’s New?
exist permanently while some of them are being created and
Con guring Callback
destroyed as needed. feature in CUCM
Con guring Dialed Number
All SDL processes can be classi ed into several logical layers: Analyzer in CUCM
CUCM 12.5 and CUBE -
Feature Layer media forking to multiple
recorders simultaneously
Call Control Layer
SCCP (Skinny Client Control
Protocol)
Media Control Layer
Connecting THIRD PARTY
SIP to CUCM
Device Layer
Cisco Meeting Server (CMS)
and Skype for Business
(Lync) Integration – Basics
and Hints
 Tag Cloud
Acano Ad-Hoc Conference Asterisk
attendant console Aurus Outbound
auto registration availability issues
call control Call Detail Record call

recording call tracing callback

caller ID authentication CCIE
Collaboration CCIE Collaboration

v2.0 CDR Cisco Cisco CallManager

Cisco Collaboration Cisco ip phone
Cisco ip phone background CIsco ip
phone lock CIsco ip phone unlock

Cisco ip telephony Cisco Jabber

Cisco logo Cisco MCU Cisco
Meeting Server Cisco Spark Cisco
TelePresence Management Suite

Cisco TMS Cisco UCCX Cisco Uni ed

RTMT CLI SQL Queries CMS

contact center CUBE CUCM

CUCM 11.5 CUCM 12 CUCM 12.5
CUCM 14 CUCM architecture CUCM
conferencing CUCM database

CUCM extensions CUCM security

CUCM server CUCM traces CUCM
troubleshooting Database Dialed
Number Analyzer Disaster Recovery

System disk cleanup DRS end-of-

sale extension mobility global
directory LinkedIn Lync

MediaSense Meet-Me conference

As the gure shows, there also are Aggregator Layer and Link Layer. For the purpose of this article we'll Packet sni ng Paging to Cisco
consider the rst one as a part of the Call Control Layer. The Link Layer is responsible for network interaction Phones PBX phone directory

on TCP/UDP level, which isn't our concern here. PhoneUP PIN authentication PIN
for CUCM Meet-Me conference

predictive vs progressive dialer

CUCM Process Classi cation RichCall SCCP scripts Self-
Provisioning in CUCM Single
Let's explain the CUCM process classi cation by the example of the Feature Layer. Number Reach SIP gateway

monitoring SIP Trunk Skinny Client

Parent Processes live in the system permanently. They are being created at the Call Manager application Control Protocol Skype Skype for
launch. These processes are: Transfer Manager, Forward Manager, Conference Manager, Recording Business SOAP SPAN Third Party
Manager. They are responsible for ALL conferences and transfers in the system.
SIP Time of the Day Routing UCCX
video chat VoIP xml XML-Services
Child Processes are being created during a certain operation. For example, the Forward operation
creates a Forwarding sub-process that lives until the transfer is over (then this process will be destroyed). for Cisco Phones Сisco Phone Сisco
phones

Device Layer Processes RSS subscribe

Edge Processes. are responsible for signaling protocols. These processes are Parent Processes and each
of them exists in a single copy on each node. For example, if we have 50 SCCP phones, then all of them Archive
will interact with a single StationInit process.
«   July 2019   »
StationInit (SCCP) M T W T F S S
SIPHandler (SIP) 1 2 3 4 5 6 7
8 9 10 11 12 13 14
H225Handler (H323)
15 16 17 18 19 20 21
MgcpHandler (MGCP) 22 23 24 25 26 27 28

MgcpBhHandler (MGCP PRI) 29 30 31        

Control Processes exist in several instances. For example, for each registered SCCP phone a separate Search
StationD process will be created that controls this phone. So, there will be 50 StationD processes created
for 50 phones.
SipStationD in messages

SIPD Find

StationD
If there are 20 SIP phones, then one SipHandler process, an intermediate SipStationInit process and 20
SipStationD processes will be created on the node. SIPD processes are used for SIP Trunks (one for each
trunk).

Now let's look into what happens when a user picks up the phone:

The phone transmits a message to CUCM, and then the following events occur: StationInit transmits a
message to the phone StationD process. StationD creates StationCdpc process. StationCdpc process is
responsible for a single call from a certain phone (CallDependent) and will be destroyed after the call is over.

Similarly, if the phone is turned o and its registration is lost, its StationD process will be destroyed.

Call Control Layer Processes

Call Control layer processes come into play to process the dialed phone number. These processes take part in
establishing the call and handling it:
 Call Control (CC) is responsible for all the calls passing through the CUCM node (1 process for a node).

Call Dependent Call Control (CdCc) is responsible for a single call. Every new call creates a new process.

DA - Digit Analysis: here all the translations are being performed, the corresponding CSS and Partitions
applied, and the destination for a particular call to be routed to is being de ned.

Device Manager (DM) – contains the tables with all the devices connected to a CUCM cluster (phones,
trunks, gateways, route lists). DM makes it possible to de ne where the call should be physically routed.

Line Control process is responsible for all the DNs registered in the system.

Let's look into how a call is handled, step by step:

Call Control (CC) creates a separate Call Dependent Call Control (CdCc) process for the call. The dialed digits
are passed to this process.

CdCc passes the numbers to DA for the necessary translations to be performed and the privileges to be
de ned for this call.
Then the call is passed to the Device Manager (DM) which determines the device the call should be transferred
to.

The information from the DM is sent back to DA and then to CDCC.

Then the call establishment will begin (CcSetupReq) and the end device will be chosen through the
RouteListControl > RoutelistCdrc chain.

Notice the Line Control process here – it is responsible for all the DNs registered.

So, the phone starts ringing, the user picks it up, and the next step is setting up a media or RTP stream. Now
we're moving one layer lower and pass the call to the Media Layer.

Media Layer Processes

As we have already mentioned, this layer hosts the processes that are responsible RTP streams.

There are permanent processes: ConnectionManager and MediaCoordinator.

And there are MediaManager and MediaExchange processes are being created and destroyed along with the
calls. They are responsible for all the call parameters - DTMF, codecs etc.

There are also Int processes - interfaces that interact with the devices directly. These processes are
responsible for the interaction between the Media Layer and Device Layer: they pass the codecs, IP addresses,
ports, etc., to the devices.

Codec mismatch

When the "codec mismatch" happens the MediaManager and MediaExchage processes de ne the transcoder
to be used. Then the separate MediaExchange (MX) process is created to ensure the connection between the
rst phone and the transcoder and between the transcoder and the second phone.

After the call is over, all the processes will be destroyed, except for ConnectionManager and
MediaCoordinator.
Process Identi er (PID)
Each process in SDI and SDL Traces is marked in a certain way:

Process Type is the process type identi er (37 for a StationD process)

Process Instance is the process ID. In this case "50" means there are at least 50 phones registered, and the
current phone is the 50th. This value is always equal to 1 for Parent Processes.

CUCM Architecture Summarized

Suppose that the phone A is calling the phone B.

The Device Layer hosts the StationD and StationCdpc processes that are responsible for the interaction
with the phone directly.

After the handset is picked up (the Device Layer process this), the call info is being passed to the Call
Control Layer where the Digit Analysis is located. Here all the translations are being performed and the
corresponding CSS and Partitions applied to identify the destination the call. At the same time a request
to the Feature Layer will be sent to transfer the call to user B.

The Call Control Layer passes a message to the Device Layer - this time to the phone B process. Phone B
rings.

Phone B is picked up and the Media set up begins. To de ne the codec the Connection Manager and the
Media Coordinator create Media Manager and Media Exchange processes that will interact with the
phones through Interfaces.

The conversation begins.

Views: 7793 Comments: 0

 Tags: CUCM, CUCM architecture, CUCM traces

For Cisco UCM Become a Partner Ask a question

Discover PhoneUP - all-in-one bundle for
CUCM and Cisco BE 6000/7000:
"Record" - call recording for
Cisco IP telephony;
"Directory" - caller ID, missed
calls and contact search.
Our sales are 100% based on a network of Find out about the price and features.
quali ed partners.
Send us your question and we will get
If your company deploys Cisco back to you in 1 business day or earlier.
collaboration solutions and contact center
software, your are welcome to join our
partner network!

"Lock" - Cisco IP phone

lock/unlock app;

About News Clients Services Contacts