How CUCM Places a Call on Hold

The ability to troubleshoot Session Initiation Protocol (SIP) calls is an invaluable skill for any network engineer. In order to troubleshoot a process, it is important to have a good understanding of how the process actually works. Understanding SIP call flow will not only help you on the job, but help you pass numerous Cisco certification exams.

This article will hone in on understanding how exactly the CUCM places calls on hold. This may seem like a simple enough transaction, but there is actually a lot going on behind the scenes. First, let's briefly review SIP calls and how we can use Cisco Unified Communication Manager (CUCM) to collect information.

What is a SIP Call?

Session Initiation Protocol (SIP) is a method of initiating, maintaining, and ending different modes of communication. So any text message, video call, or phone call will use SIP. It's essentially the "language" of internet telephony in the same way that HTTP is the "language" of web browsers. Let's break down SIP a little more; it will greatly enhance our understanding of how CUCM places a call on hold.

What are the Different Types of SIP Messages?

A SIP message is either a request or a response. Think of a phone call between two entities. One party listens while the other party speaks. In other words, telephonic communication is half-duplex. While the core of messaging may be half-duplex, how does a SIP message actually know what to do next in a conversation? Let's take a look at three different requests commonly used when placing a person on hold: ACK, SUBSCRIBE, and BYE.

What is ACK?

Whenever one party calls another party, SIP requires that the receiving user acknowledges that call. This is called an ACK. It is tightly coupled to another request called INVITE. Every INVITE created must receive an ACK for a call to be formally initiated. For those of you versed in TCP, think of it as a three-way handshake.

What is SUBSCRIBE?

SUBSCRIBE is used to create a subscription to retrieve some expected event. All subscriptions have an expire value. Expire determines how long the subscription will last, aka how long the server will wait for an event.

As will become apparent in the logs, whenever a user dials an extension, a SUBSCRIBE request is initiated. A SUBSCRIBE message is sent to the SIP server which in turn acknowledges with an OK. This is status 200 for those familiar with HTTP.

Once the status is returned as OK, the server will send out NOTIFY messages to the notifier until the SUBSCRIBE is complete. The NOTIFY will hold information about the status of the process, in which the initiator can take action. For example, whether a KPML event has occurred. KPML here stands for Key Press Markup Language. SUBSCRIBE is the most complex of the three we will discuss, but let's briefly go over BYE.

What is BYE?

BYE does exactly what it implies, it ends a call between two parties. One thing that is important to note is that a BYE request can't be sent from a proxy server. The request must come from either the caller or callee. Also, a BYE can be sent from either party to end the session.

Now that we've gone over several different requests, let's dive into the Cisco RTMT to download the call traces. That way we can see these requests in action, and learn how CUCM puts calls on hold. After that, we'll take those call logs and process them in TranslatorX. That's where all the magic happens!

What is Cisco RTMT?

Cisco RTMT stands for real-time monitoring tool. As the name implies, it allows you to monitor SIP calls in real time. It is used to troubleshoot calls or look at SIP transactions for any particular reason. The RTMT executable can be found in the Cisco Unified CM Administration.

Once RTMT is downloaded, open it up and click on Trace and Log Central. You will then be prompted for a username and password. Submit the credentials and click Collect Files near the top. The next screen will look like the picture below:

On the screen above, click Cisco CallManager for All Servers. After that, click next. At this point you will be prompted for a range of data that needs to be collected.

Once this process is finished, a collection of files will be produced that we can analyze using Translator X. Translator X is a troubleshooting tool that allows us to analyze SIP calls retrieved from RTMT. This is how we can review logs to see how a CUCM call is placed on Hold.

How is a CUCM Call Placed on Hold?

Now that we have familiarity with all the terms and required tools, let's take a look at a call flow for a call placed on hold. This scenario will be between two employees named Savannah and Mariah.

Starting the Call

The first thing we will review is Savannah calling Mariah using extensions 1000 and 1001 respectively. Then Savannah will place Mariah on hold, who will then end the call. The image below is a collection of requests that begin to describe this transaction. Think of Savannah (the caller) as the left column and Mariah (the callee) as the right column.

The picture above is describing the beginning of the call. Each 200 OK represents a KPML event. In other words, Savannah is calling Mariah and each key she types is receiving an ACK from the server that the request is OK. So Savannah sends a NOTIFY with the digit as the payload, and CUCM sends back an OK.

Once CUCM receives all of the numbers, it's able to find Savannah's extension and terminate the SUBSCRIBE request. The image shows the logs of a call actually being attempted once the extension is recognized by CUCM.

A Call Put on Hold

Notice how at 10:35:25.590 an INVITE is sent. This is Savannah sending out an INVITE to Mariah to establish a session. CUCM then sends out "Ringing" notifications to each of them. This is just the sound of the phone ringing, waiting for the ACK that is soon to follow.

Mariah then ACKs the call at 10:35:25.731, and then Savannah ACK's that Mariah successfully received the INVITE. This is the all-too-familiar three-way handshake. The next thing Savannah will do is put Mariah on HOLD.

Observe that at time 10:35:27.749 a Re-INVITE request is sent. The reason it is a re-INVITE instead of an INVITE is because we have already established a session between Savannah and Mariah. Because Savannah is the one initiating HOLD, her session can only send media, which is why that row is marked sendonly in parentheses.

In the image below, notice the requests outlined by a green rectangle. During this moment Music On Hold (MOH) is being sent to Mariah. Specifically, this is occurring in the ACK at 10:35:29.887.

Wrapping Up the Call

The next event occurs at 10:35:41.200. Savannah takes Mariah off hold. The next group of requests deal with ending the MOH and reestablishing a connection between the two parties. By the time a 200 OK w/SDP is made at 10:35:41.309, the call has resumed. Mariah then ends the call, which is why there is a BYE at 10:35:45.835. This BYE is acknowledged by Savannah and thus ends the call.

Final Thoughts

Phew! Suffice it to say, that is a lot of information to process. In this article, we covered the following material:

• The definition of SIP

• Common SIP requests such as ACK, SUBSCRIBE, BYE and OK

• How to download call logs from RTMT and how to process and analyze the logs in TranslatorX.

• The request flow of a Call On Hold.

This is a fairly complex subject, so be patient as you dive into the exciting and complex world of SIP.