1

Introduction
This document explains the basic SIP Call flow between the PBX, Gateways and SIP Phones in detail. Idea of
creating this document is to help the beginners to understand the Various SIP Call flows and messages. Also
this document covers the SIP Troubleshooting commands.

Prerequisites
 Basic knowledge about the SIP Protocol and the call flow Messages.

Call Flow Examples

1. Call Flow between PBX to Cisco SIP IP Phone—Successful Setup and Disconnect

Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and disconnect. In this
scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to
Gateway 1 (SIP Gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the
Cisco SIP IP phone over an IP network.

The call flow is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B disconnects the call.

 2

Step Action Description

1. Setup—PBX A to Call Setup is initiated between PBX A and Gateway 1. The Call Setup
Gateway 1 includes the standard transactions that take place as User A attempts to call
User B.

2. INVITE—Gateway 1 Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer
to Cisco SIP IP includes the IP address and the port number of the SIP-enabled entity to
phone contact. Gateway 1 sends a SIP INVITE request to the address it receives as
the dial peer, which, in this scenario, is the Cisco SIP IP phone.

In the INVITE request:

 The IP address of the Cisco SIP IP phone is inserted in the Request-

URI field.
 PBX A is identified as the call session initiator in the From field.
 A unique numeric identifier is assigned to the call and is inserted in
the Call-ID field.
 The transaction number within a single call leg is identified in the
CSeq field.
 3

 The media capability User A is ready to receive is specified.

 The port on which the Gateway is prepared to receive the RTP data is
specified.

3. Call Proceeding— Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the
Gateway 1 to PBX A Call Setup request.

4. 100 Trying—Cisco The Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The
SIP IP phone to 100 Trying response indicates that the INVITE request has been received by
Gateway 1 the Cisco SIP IP phone.

5. 180 Ringing—Cisco The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The
SIP IP phone to 180 Ringing response indicates that the user is being alerted.
Gateway 1

6. Alerting—Gateway 1 Gateway 1 sends an Alert message to User A. The Alert message indicates
to PBX A that Gateway 1 has received a 180 Ringing response from the Cisco SIP IP
phone. User A hears the ringback tone that indicates that User B is being
alerted.

7. 200 OK—Cisco SIP The Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200
IP phone to Gateway OK response notifies Gateway 1 that the connection has been made.
1

8. Connect—Gateway 1 Gateway 1 sends a Connect message to PBX A. The Connect message

to PBX A notifies PBX A that the connection has been made.

9. Connect ACK—PBX PBX A acknowledges Gateway 1's Connect message.

A to Gateway 1

10. ACK—Gateway 1 to Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The ACK confirms
Cisco SIP IP phone that Gateway 1 has received the 200 OK response. The call session is now
active.

11. BYE—Cisco SIP IP User B terminates the call session at his Cisco SIP IP phone and the phone
phone to Gateway 1 sends a SIP BYE request to Gateway 1. The BYE request indicates that User
B wants to release the call.

12. Disconnect— Gateway 1 sends a Disconnect message to PBX A.

Gateway 1 to PBX A

13. Release—PBX A to PBX A sends a Release message to Gateway 1.

Gateway 1
 4

14. 200 OK—Gateway 1 Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200
to Cisco SIP IP OK response notifies the phone that Gateway 1 has received the BYE request.
phone

15. Release Complete— Gateway 1 sends a Release Complete message to PBX A and the call session
Gateway 1 to PBX A is terminated.

2. Call flow between Gateway-to-Cisco SIP IP Phone Call—Successful Call Setup and Call Hold

Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and call hold. In this scenario,
the two end users are User A and User B. User A is located at PBX A. PBX A is connected to Gateway 1 (SIP
Gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP
phone over an IP network.

The call flow is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B puts User A on hold.

4. User B takes User A off hold.

 5

Step Action Description

1. Setup—PBX A to Call setup is initiated between PBX A and Gateway 1. The call setup includes
Gateway 1 the standard transactions that take place as User A attempts to call User B.

2. INVITE—Gateway 1 Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer
to Cisco SIP IP includes the IP address and the port number of the SIP enabled entity to
phone contact. Gateway 1 sends a SIP INVITE request to the address it receives as
the dial peer, which, in this scenario, is the Cisco SIP IP phone.

In the INVITE request:

 The IP address of the Cisco SIP IP phone is inserted in the Request-

URI field.
 PBX A is identified as the call session initiator in the From field.
 A unique numeric identifier is assigned to the call and is inserted in
the Call-ID field.
 The transaction number within a single call leg is identified in the
CSeq field.
 The media capability User A is ready to receive is specified.
 6

 The port on which the gateway is prepared to receive the RTP data is
specified.

3. Call Proceeding— Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the
Gateway 1 to PBX A Call Setup request.

4. 100 Trying—Cisco The Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The
SIP IP phone to 100 Trying response indicates that the INVITE request has been received by
Gateway 1 the Cisco SIP IP phone.

5. 180 Ringing—Cisco The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The
SIP IP phone to 180 Ringing response indicates that the user is being alerted.
Gateway 1

6. Alerting—Gateway 1 Gateway 1 sends an Alert message to User A. The Alert message indicates
to PBX A that Gateway 1 has received a 180 Ringing response from the Cisco SIP IP
phone. User A hears the ringback tone that indicates that User B is being
alerted.

7. 200 OK—Cisco SIP The Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200
IP phone to Gateway OK response notifies Gateway 1 that the connection has been made.
1

8. Connect—Gateway 1 Gateway 1 sends a Connect message to PBX A. The Connect message

to PBX A notifies PBX A that the connection has been made.

9. ACK—Gateway 1 to Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The ACK confirms
Cisco SIP IP phone that User A has received the 200 OK response. The call session is now active.

10. Connect ACK—PBX PBX A acknowledges Gateway 1's Connect message.

A to Gateway 1

11. INVITE—Cisco SIP User B puts User A on hold. The Cisco SIP IP phone sends a SIP INVITE
IP phone to Gateway request to Gateway 1.
1

12. 200 OK—Gateway 1 Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200
to Cisco SIP IP OK response notifies the Cisco SIP IP phone that the INVITE was
phone successfully processed.

13. ACK—Cisco SIP IP The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms
phone to Gateway 1 that the Cisco SIP IP phone has received the 200 OK response. The call
session is now temporarily inactive. No RTP packets are being sent.
 7

14. INVITE—Cisco SIP User B takes User A off hold. The Cisco SIP IP phone sends a SIP INVITE
IP phone to Gateway request to Gateway 1.
1

15. 200 OK—Gateway 1 Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200
to Cisco SIP IP OK response notifies the Cisco SIP IP phone that the INVITE was
phone successfully processed.

16. ACK—Cisco SIP IP The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms
phone to Gateway 1 that the Cisco SIP IP phone has received the 200 OK response. The call
session is now active.

3. Call flow between Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold

Below diagram illustrates a successful call between Cisco SIP IP phones in which one of the participants places
the other on hold and then returns to the call. In this call flow scenario, the two end users are User A and User
B. User A and User B are both using Cisco SIP IP phones, which are connected via an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B places User A on hold.

4. User B takes User A off hold.

5. The call continues.

 8

Step Action Description

1. INVITE—Cisco Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B.
SIP IP phone A to The INVITE request is an invitation to User B to participate in a call session.
Cisco SIP IP phone
B In the INVITE request:

 The phone number of User B is inserted in the Request-URI field in the

form of a SIP URL. The SIP URL identifies the address of User B and
takes a form similar to an e-mail address (user@host, where user is the
telephone number and host is either a domain name or a numeric
network address). For example, the Request-URI field in the INVITE
request to User B appears as "INVITE sip:555-0002@companyb.com;
user=phone." The "user=phone" parameter distinquishes that the
Request-URI address is a telephone number rather than a username.
 Cisco SIP IP phone A is identified as the call session initiator in the
From field.
 A unique numeric identifier is assigned to the call and is inserted in the
Call-ID field.
 The transaction number within a single call leg is identified in the CSeq
 9

field.
 The media capability User A is ready to receive is specified.

2. 180 Ringing— Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone
Cisco SIP IP phone A.
B to Cisco SIP IP
phone A

3. 200 OK—Cisco Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A.
SIP IP phone B to The 200 OK response notifies Cisco SIP IP phone A that the connection has
Cisco SIP IP phone been made.
A
If Cisco SIP IP phone B supports the media capability advertised in the INVITE
message sent by Cisco SIP IP phone A, it advertises the intersection of its own
and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco
SIP IP phone B does not support the media capability advertised by Cisco SIP
IP phone A, it sends back a 400 Bad Request response with a 304 Warning
header field.

4. ACK—Cisco SIP Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK
IP phone A to confirms that Cisco SIP IP phone A has received the 200 OK response from
Cisco SIP IP phone Cisco SIP IP phone B.
B
The ACK might contain a message body with the final session description to be
used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco
SIP IP phone B uses the session description in the INVITE request.

A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.

5. INVITE—Cisco Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with
SIP IP phone B to new Session Description Protocol (SDP) session parameters (IP address), which
Cisco SIP IP phone are used to place the call on hold.
A
Call_ID=1

SDP: c=IN IP4 0.0.0.0

The c= SDP field of the SIP INVITE contains an 0.0.0.0. This places the call in
hold.

6. 200 OK—Cisco Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
SIP IP phone A to
Cisco SIP IP phone
 10

7. ACK—Cisco SIP Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK
IP phone B to confirms that Cisco SIP IP phone B has received the 200 OK response from
Cisco SIP IP phone Cisco SIP IP phone A.
A

The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.

8. INVITE—Cisco Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with
SIP IP phone B to the same call ID as the previous INVITE and new SDP session parameters (IP
Cisco SIP IP phone address), which are used to reestablish the call.
A
Call_ID=1

SDP: c=IN IP4 181.23.250.2

To reestablish the call between phone A and phone B, the IP address of phone
B is inserted into the c= SDP field.

9. 200 OK—Cisco Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
SIP IP phone A to
Cisco SIP IP phone
B

10. ACK—Cisco SIP Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK
IP phone B to confirms that Cisco SIP IP phone B has received the 200 OK response from
Cisco SIP IP phone Cisco SIP IP phone A.
A

A two-way RTP channel is reestablished between IP phone A and IP phone B.

Defining SIP Port in Cisco Unified Communications Manager

 11

SIP Troubleshooting

 On Unified Communications Manager use RTMT to check SIP traces in UC Manager

 "debug ccsip calls"
 "debug ccsip all"
 "debug ccsip error"
 "debug ccsip events"
 "debug ccsip messages"
 "debug ccsip states"
 "show sip-ua call"
- Displays active UAC and user agent server (UAS) information on sip calls
 " show call active voice brief"
- Displays active call information for voice calls or fax transmission in progress

 Check MTP configuration

- MTP is required for Early offer
- MTP is required on older UC Manager versions to provide supplementary services
 Check layer 2/3 variables
 12

Introduction

This document covers the IP Phone Registration Process with the Cisco Unified Communications Manager (CUCM). It
covers both SCCP and SIP Phone Registration Process to help the beginners to understand the basics of IP Phone boot
process better which will help in Configuration and Troubleshooting the Network related issues easily.

IP Phone Registration Process

SCCP Phone Registration Process

1. SCCP phone obtains the Power (PoE or AC adapter).

2. The phone loads its locally stored firmware image.

3. The phone learns the Voice VLAN ID via CDP from the switch.

4. The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.

5. The phone contacts the TFTP server and requests its configuration file. Each phone has a customized
configuration file named SEP<mac_address>.cnf.xml created by CUCM and uploaded to TFTP when the
administrator creates or modifies the phone.

6. The phone registers with the primary CUCM server listed in its configuration file. CUCM then sends the
softkey template to the phone using SCCP messages.
 13

What is in that SEP<mac_address>.cnf.xml file ?

This file contains a list of CUCM server, in order, that the phone should register with. It lists teh TCP ports it
should use for SCCP communication. It also lists the firmware version for each device model and the service
URLs that each device should be using.

The CUCM server sends other configurations such as DNs, softkeys and speed dials via the SCCP messages in
the last phase of the registration process.

SIP Phone Registration Process

SIP Phones use a different set of steps to achieve the same goal. Steps 1 to 4 are the same as SCCP Phones,
refer the steps as illustrated in the figure: SCCP Phone Boot Process .

1. The phone contacts the TFTP server and requests the Certificate Trust List file (only if the cluster is secured).

2. The phone contacts the TFTP server and requests its SEP<mac-address>.cnf.xml configuration file.
 14

3. If the SIP Phone has not been provisioned before boot time, the SIP Phone downloads the default
configuration XMLDefault.cnf.xml file from the TFTP server.

4. The SIP phone requests a firmware upgrade (Load ID file), if one was specified in the configuration file. This
process allows the phone to upgrade the firmware image automatically when required for a new version of
CUCM.

5. The phone downloads the SIP dial rules configured for that phone.

6. The phone Establish connection with the primary CUCM and the TFTP server end to end.

7. The phone Registers with the primary CUCM server listed in its configuration file.

8. The phone downloads the appropriate localization files from TFTP.

9. The phone downloads the softkey configurations from TFTP.

10. The phone downloads custom ringtones (if any) from TFTP.
 15

About TFTP server:

TFTP is a critical service for IP Phones. The Phone use TFTP to download their config files, firmware and other
data. Without TFTP, the phones simply do not function properly. When you make a configuration change to a
device, CUCM creates or modifies a config file for the device and uploads it to the TFTP server. TFTP service
much therefore provided by one or more CUCM servers in the cluster.

Note: A generic TFTP server will not have the integrated capability that a CUCM TFTP server does and will
not correctly fulfill the role.

Recommendation
 16

Take note of the place where the files are logged. Cisco CallManager 3.x and 4.x, by default, stores trace files in the C:\Program
Files\Cisco\Trace\CCM\ directory, but these files can be specified to be stored elsewhere in the trace configuration. Other services log their traces in
their respective directories. As mentioned earlier, in Versions 5.x/6.x/7.x, they are stored in the location that the RTMT specifies.

Browse in the Windows Explorer to the trace directory in order to collect the correct trace files. Then choose View > Details from the menu bar in
order to view dates and times. Make the window large enough to see these values.

Note: If you reproduce a problem, make sure to select the file for the timeframe when you reproduced it. Look at the modification date and the
timestamps in the file. The best way to collect the right traces is to reproduce a problem, quickly locate the most recent file, and copy it from Cisco
CallManager.

Files are overwritten after some period of time. In order to find the current file that is logged, click View > Refresh on the menu bar and look at the
dates and times on the files. You can view and configure the location, size, and lifespan of the trace files, as shown in the preceding diagram.

Traces can be CPU intensive for the Cisco CallManager server. It is a good practice to turn off traces after you have collected them. Follow the same
procedure used to enable the traces, but uncheck the "Trace On" settings and save.
 17

Introduction

This document explains the various Unified Communications call flow scenario in an Enterprise Network. Idea
of creating this document is to help the beginners to understand the various Call flows and protocol messages.

Prerequisites

 Basic knowledge about Cisco Unified Communications Manager (CUCM) and the protocols SIP, H.323
and ISDN.

Call Flow Examples

1. IP Phone to IP Phone - Successful Intracluster Call

In this scenario, Phone A is registered to Cisco Unified Communication Manager X denoted by CUCM X.
Phone B is registered to the same CUCMX.

A call is placed from Phone A (1000) to Phone B (1006). Basic setup for a call between two IP phones
registered to the same CUCM.
18
 19

Below call flow illustrates the sequence of Skinny Call Control Protocol (SCCP) messages exchanged between
the Unified CM (CUCM X) and the two IP phones described in the setup.

2. Call flow: IP Phone to Voice Gateway using MGCP

In this scenario, Phone A is registered to the Unified CM (CUCM). Phone B is connected to a carrier’s central
office (CO) Switch. CUCM will access Phone B through the voice gateway. Below diagram illustrates this basic
setup for a call set up between an IP phone registered to the CUCM and another phone connected to a CO
switch in the public switched telephone network (PSTN) through a voice gateway. This voice gateway is
registered with the CUCM using Media Gateway Control Protocol (MGCP).

A call is placed from Phone A (1000) to Phone B (555-1212). Phone A will hang up first. MGCP is used to
relay ISDN messages that go between the CUCM and the actual CO switch.
 20

Below figure, include call flows that show ISDN messages going to the gateway (GW); they are really being
sent to the CO switch through the gateway. Detailed call flow is shown here,
 21

3. Call flow: IP Phone to H.323 Voice Gateway with Gatekeeper

In this scenario, Phone A is registered to the CUCM. Phone B is connected to a carrier’s CO switch. Below
diagram illustrates this call setup between two IP phones registered to the same CUCM. A call is placed from
Phone A (555-2001) to Phone B (555-2001). Phone B hangs up first. The CUCM must register with the
gatekeeper prior to placing any calls, and the gatekeeper will police the bandwidth by implementing Call
Admission Control (CAC).
 22

Because the initial call setup phases between the IP phone and the CUCM have been covered earlier, they are
not repeated in this call flow. Below figure includes all the steps involving CUCM registration with the
gatekeeper, skips the initial IP Phone A interaction with the CUCM when it goes off-hook to call Phone B in the
PSTN, and then illustrates the CUCM and H.323 gateway interaction, including the ISDN Q.931 messaging
exchange with the CO in the PSTN to set up the call with Phone B. The communication beyond the CO, which
would include SS7 messages, with the CO serving Phone B is not part of this overall example.
 23

Related Information