Cisco Collaboration and Contact Center Solutions - Messages with tag "CUCM traces"

Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Meeting Server

  • Archive

    «   March 2024   »
    M T W T F S S
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31
                 

CUCM Traces Analysis: CUCM Architecture

This is another guest post that we find quite useful for our readers. The author discusses briefly the CUCM architecture in order to understand better the CUCM traces.

CUCM is a C++ application working on the Red Hat Linux OS.

There are SDL (Signal Distribution Layer) processes within the application interacting with each other. Some of these objects exist permanently while some of them are being created and destroyed as needed.

All SDL processes can be classified into several logical layers:

  • Feature Layer
  • Call Control Layer
  • Media Control Layer
  • Device Layer

As the figure shows, there also are Aggregator Layer and Link Layer. For the purpose of this article we'll consider the first one as a part of the Call Control Layer. The Link Layer is responsible for network interaction on TCP/UDP level, which isn't our concern here.

CUCM Process Classification

Let's explain the CUCM process classification by the example of the Feature Layer.

  • Parent Processes live in the system permanently. They are being created at the Call Manager application launch. These processes are: Transfer Manager, Forward Manager, Conference Manager, Recording Manager. They are responsible for ALL conferences and transfers in the system.
  • 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).

Device Layer Processes

  • 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 will interact with a single StationInit process.
    • StationInit (SCCP)
    • SIPHandler (SIP)
    • H225Handler (H323)
    • MgcpHandler (MGCP)
    • MgcpBhHandler (MGCP PRI)
  • Control Processes exist in several instances. For example, for each registered SCCP phone a separate StationD process will be created that controls this phone. So, there will be 50 StationD processes created for 50 phones.
    • SipStationD
    • SIPD
    • 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 off 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 defined.
  • 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 define 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 defined 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 define the transcoder to be used. Then the separate MediaExchange (MX) process is created to ensure the connection between the first 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 Identifier (PID)

Each process in SDI and SDL Traces is marked in a certain way:

Process Type is the process type identifier (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 define 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.