Total Pageviews

Showing posts with label sip. Show all posts
Showing posts with label sip. Show all posts

Wednesday, June 20, 2012

CUCM SIP Trunk TLS Configuration and Troubleshooting


Purpose

This document will serve as an instructional guide to help understand and configure SIP TLS on Communications Manager. This will supplement the original Security Guide by providing diagrams and images, along with further explanation.

After following this doc, SIP messages between two clusters will be encrypted using TLS. To encrypt phone signaling, or media (RTP) please follow the Phone Security Guide.

SIP TLS on Inter Cluster Trunk Configruation

Lab Network Overview

SIPTLS-cluster-diagram.png
Cluster 1 consists of two servers running CUCM 7.1(3).

Cluster 2 is just a single node running 8.5(1).

Note the very important distinction that phone 7131001 has a CMG (CallManagerGroup)  that points to the Publisher as the primary node for registration. 7131002 has a CMG that causes it to register with the Subscriber server. This will make a difference later on.

Download CallManager.pem Certificates

The very first step is to download every single CallManager.pem certificate from every node that could potentially be involved in a SIP call on both clusters. Self Signed certificates are being used in this lab example. If CA signed certificates were used instead, only the CA certificate would be needed for this step.

For more information on CA Signed Certificates see the following Document covering CA Signed Certificates in Tomcat. The theory is similar.
OSAdminCertPage.png

CallManagerPemDownload.png

The browser suggests the file should be saved as CallManager.pem. It's very helpful to instead take the CN (Common Name) of the server and use that as a file name. When the next step comes up this will make a lot of sense.
CertNames.png

Upload CallManager.pem Certificates

Each CUCM server now needs the certificate from every server that can make a SIP connection to it. Upload these certificates as the type "CallManager-trust". This is much easier if each certificate file is named with the Common Name.

In this step on the CA Root Certificates need to be uploaded if using CA Signed Certificates. In this example Self Signed Certificates are used, so all certificates must be uploaded.
CUCM7Pub-certupload.png

Certificates Uploaded on CUCM7-PUB and CUCM7-SUB1

Cluster 1 can only make and receive a connection to a single server, CUCM8-Publisher. Therefore only the single certificate from Cluster 2 needs to be uploaded.

It's important to upload this file on both the publisher and subscriber in Cluster 1, because both servers in Cluster 1 could potentially make or receive a SIP call to the remote cluster. The OS Admin Certificate Management web page should look like this:
trust-certs-on7.png

Certificates Uploaded on CUCM8-Publisher

On Cluster 2, both certificates from the Cluster 1 publisher and subscriber must be uploaded. This is so the Cluster 2 server can establish secure connections to either of these servers.

trust-certs-on8.png

Create SIP Trunk Security Profiles

The SIP Trunk Security Profile must be created on each cluster. This sets the security parameters for the SIP trunk. When using SIP TLS, a unique SIP Trunk Security Profile must be created for each SIP Trunk in a cluster.

The Transport Type is set to TLS, which means an X.509 certificate Subject Name must also be configured. On Cluster 1 this must be set to the Common Name in the certificate from Cluster 2 that was just uploaded. In this case, CUCM8-Publisher.bbbburns.lab.

Since this is also an Inter Cluster Trunk between two CUCM clusters, the "Transmit Security Status" can be sent across the trunk so phones display the appropriate lock or shield icon for the call security status.
Cluster1-SIPT-Sec-Profile.png
On Cluster 2 the configuration is slightly more complex. Since Cluster 2 can establish TLS connections with two different servers, the Subject Name of both servers must be listed in Cluster 2's SIP Trunk Security Profile. In this case the comma separated list of "CUCM7-PUB.bbbburns.lab, CUCM7-SUB1.bbbburns.lab" is required. These fields are not case sensitive.
Cluster2-SIPT-Sec-Profile.png
Both SIP Trunk Security Profiles set an incoming port of 5061. That means each cluster will be listening on TCP port 5061 for new inbound SIP TLS calls.

Create SIP Trunks

After the Security Profiles are created, then the SIP Trunks that use the Security Profiles can be created as well.

The only configuration parameter changed in this screen on Cluster 1 is "SRTP Allowed". This will allow secure RTP to be used for calls over this trunk. This box should only be checked when using SIP TLS, because the keys for SRTP are exchanged in the body of the SIP message. The SIP signaling must be secured by TLS, otherwise anyone with the non secure SIP signaling could decrypt the corresponding Secure RTP stream over the trunk.

The Device Pool of this SIP trunk on Cluster 1 contains both the publisher and subscriber. That means this SIP Trunk will run on the publisher and subscriber, listening for new incoming calls to both of these nodes.
Cluster1-SIPT1.png
On the bottom section of the SIP Trunk configuration for Cluster 1, note the Destination IP Address, Destination Port, and Security Profile.
Cluster1-SIPT2.png

Cluster 2 has a similar SIP Trunk configuration.
Cluster2-SIPT1.png

Since Cluster 2 is on 8.5(1) it has the ability to add up to 16 destinations for the SIP trunk. We use only two, and set the destination port to 5061 accordingly. Remember that 5061 is the port that Cluster 1 is listening on, and Cluster 1 has a Device Pool that allows both servers to accept SIP calls for this trunk.
Cluster2-SIPT2.png

Create Route Patterns

In this case the simplest method is to create a Route Pattern on each cluster pointing directly to the SIP Trunk. Route Groups and Route Lists could also be used.

Here is the SIP Trunk on Cluster 1. Note that the Trunk page allows the associated Route Pattern to be easily viewed. Cluster 1 points to 851XXXX via the trunk to Cluster 2.

Cluster1-SIPT-RP.png

Cluster 2 points to 713XXXX via the trunk to Cluster 1.

Cluster2-SIPT-RP.png

Troubleshooting

A SIP TLS call can be debugged with just a few  tools.

Collect Packet Captures on CUCM

Command Line Packet Captures to Screen

The fastest way to verify connectivity between clusters is to take a packet capture on the CUCM servers and watch for SIP TLS traffic. Remember that it should be transmitted on TCP port 5061.

In the following example there is an SSH CLI session established to both the publisher and subscriber servers on Cluster 1. Test calls are made from 7131001 and 7131002, both calling 8151001.

This example shows that when 7131001 makes a call, the TCP session comes from CUCM7-PUB.bbbburns.lab, and goes to CUCM8-Pub.bbbburns.lab.
admin:utils network capture host ip 14.48.44.80
Executing command with options:
 size=128                count=1000              interface=eth0
 src=                    dest=                   port=
 ip=14.48.44.80
13:31:51.787879 IP CUCM7-PUB.bbbburns.lab.37448 > cucm8-pub.bbbburns.lab.5061: S 3618047650:3618047650(0) win 5840 <mss 1460,sackOK,timestamp 944769035 0,nop,wscale 2>
13:31:51.788102 IP cucm8-pub.bbbburns.lab.5061 > CUCM7-PUB.bbbburns.lab.37448: S 1615387233:1615387233(0) ack 3618047651 win 5792 <mss 1460,sackOK,timestamp 1044807200 944769035,nop,wscale 2>
13:31:51.788124 IP CUCM7-PUB.bbbburns.lab.37448 > cucm8-pub.bbbburns.lab.5061: . ack 1 win 1460 <nop,nop,timestamp 944769039 1044807200>

Now watch what happens on the Subscriber server when 7131002 makes the call.
admin:utils network capture host ip 14.48.44.80
Executing command with options:
 size=128                count=1000              interface=eth0
 src=                    dest=                   port=
 ip=14.48.44.80
13:32:17.928367 IP CUCM7-SUB1.bbbburns.lab.52172 > cucm8-pub.bbbburns.lab.5061: S 4239526776:4239526776(0) win 5840 <mss 1460,sackOK,timestamp 346555111 0,nop,wscale 2>
13:32:17.928511 IP cucm8-pub.bbbburns.lab.5061 > CUCM7-SUB1.bbbburns.lab.52172: S 1630528437:1630528437(0) ack 4239526777 win 5792 <mss 1460,sackOK,timestamp 1044833336 346555111,nop,wscale 2>
13:32:17.928530 IP CUCM7-SUB1.bbbburns.lab.52172 > cucm8-pub.bbbburns.lab.5061: . ack 1 win 1460 <nop,nop,timestamp 346555115 1044833336>

These packet captures demonstrate that a phone making a call out a SIP Trunk attempts to use the SIP Trunk process on the same server where the phone is registered if possible. In this case the SIP Trunk on Cluster 1 has a CMG that did allow it to exist on both the publisher and subscriber.

These results would be different if the CMG of the SIP Trunk on Cluster 1 only contained a single server. We would only see traffic sourced from that single server.

Let's test multiple calls in the reverse direction now and gather a capture on the CUCM 8 server:
admin:utils network capture port 5061
Executing command with options:
 size=128                count=1000              interface=eth0
 src=                    dest=                   port=5061
 ip=

First call attempt goes to 14.48.44.22 (cucm7-sub1.bbbburns.lab)
13:44:26.128758 IP CUCM8-Publisher.bbbburns.lab.48393 > cucm7-sub1.bbbburns.lab.5061: P 1909893565:1909894727(1162) ack 217213568 win 6161 <nop,nop,timestamp 1045561456 347159087>
13:44:26.128876 IP cucm7-sub1.bbbburns.lab.5061 > CUCM8-Publisher.bbbburns.lab.48393: . ack 1162 win 6641 <nop,nop,timestamp 347283235 1045561456>

Next call attempt is load balanced to 14.48.44.21 (cucm7-pub.bbbburns.lab)
13:45:11.098222 IP CUCM8-Publisher.bbbburns.lab.48417 > cucm7-pub.bbbburns.lab.5061: P 1951301588:1951302750(1162) ack 3961011476 win 5189 <nop,nop,timestamp 1045606420 945409167>
13:45:11.098450 IP cucm7-pub.bbbburns.lab.5061 > CUCM8-Publisher.bbbburns.lab.48417: . ack 1162 win 5479 <nop,nop,timestamp 945568267 1045606420>

These captures demonstrate that when a SIP Trunk has multiple destinations (Like the SIP Trunk configured on Cluster 2), calls can be load balanced between the different destinations.

A common complaint about calls over a trunk is "One out of every X calls fails". If there are X destinations on a SIP Trunk, this probably means one of those destinations is failing for some reason when a call is load balanced to that destination.

Command Line Captures to File

A packet capture to the screen can be useful to verify packets are being sent and received in both directions. To look at what is actually inside the packets a capture to file is the best option.

utils network capture port 5061 file 851SIPTLS count 1000 size all
file get activelog platform/cli/851SIPTLS.cap

The capture will be written in a standard pcap format. This example uses Wireshark, but any packet capture display tool could be used. This packet capture is attached to the document. It can be downloaded to follow along with this example and do deeper digging into the packet bytes.

PacketCaptureOverview.png
The highlighted parts are in order,

  1. The TCP SYN to establish TCP communication between CUCM8-Publisher (Client) and CUCM7-SUB1 (Server).
  2. The Client Hello that CUCM8-Publisher sends to start the TLS session.
  3. The Server Hello, Server Certificate, and Certificate Request that the CUCM7-SUB1 sends to start the certificate exchange process.
  4. The Certificate that the Client CUCM8-Publisher sends to complete the certificate exchange.
  5. The Application Data that is encrypted SIP signaling. Showing us the TLS session has been established.
  6. The next TCP SYN sent from CUCM8-Publisher to CUCM7-Publisher, showing the load balancing that happens for multiple calls.

Let's drill down and focus on the most important pieces for troubleshooting. There is nothing too interesting in the Client Hello. Let's start with the Server Hello and Server Certificate:
PacketCaptureServerCert.png
The Server Hello also contains the Server Certificate. The serial number and subject information that the server CUCM7-PUB is presenting to CUCM8-Publisher is visible here. The serial number, subject, issuer, and validity dates can all be compared to what has actually been uploaded into the OS Admin Certificate Management page.

If there is a mismatch between the certificates in the packet capture and the certificates in the OS Admin Web Page, the correct certificates must be uploaded into the OS Admin Cert page.

The final part of interest is the "Certificate Request" in this message. The server has presented its own certificate for verification, now it wants to see the certificate of the client. Verification happens in both directions.

The same fields in the Client Certificate can be analyzed and compared to what has been uploaded to the OS Admin Cert page.
PacketCaptureClientCert.png
The certificate exchange completes successfully in this instance. Application Data then flows between the Client and the Server. The Application Data here is a SIP INVITE.

Collect CUCM Traces

In addition to packet captures, CUCM traces can also be helpful to determine what sort of messages are being exchanged between the servers, and whether or not the SSL session is properly established.


In this example traces from Cluster 2 will be analyzed. 8511001 makes a call to 7131001 over the SIP TLS Trunk. Start with the SDI traces for basic information, and for more details the SDL traces can be reviewed as well.

Here the SDI traces show the Calling and Called numbers in the Digit Analysis block. The Route Pattern used can also be viewed.

13:57:03.801 ||PretransformCallingPartyNumber=8511001
|CallingPartyNumber=8511001
|DialingPartition=
|DialingPattern=713XXXX
|FullyQualifiedCalledPartyNumber=7131001

The messages in the SDI traces are quite sparse regarding SIP TLS, but here it is visible that SIP TLS is being used on port 5061 for this call.

13:57:03.811 |//SIP/SIPHandler/ccbId=0/scbId=0/SIP_PROCESS_ENQUEUE: createConnMsg tls_security=3

13:57:03.823 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 14.48.44.22 on port 5061 index 19 
INVITE sip:7131001@14.48.44.22:5061 SIP/2.0
Via: SIP/2.0/TLS 14.48.44.80:5061;branch=z9hG4bK28140d6fdf
From: <sip:8511001@14.48.44.80>;tag=5164~fa1de7d3-3a9e-4568-ae99-39e270e47fbc-30262865
To: <sip:7131001@14.48.44.22>
13:57:03.827 |SIPSocketProtocol(1,100,13,5)::SendTLSConnectionInfo

Now let's look at the SDL traces for more detailed information. Here the Subject CN and connection information for the TLS session is available. The key pieces are the SdlSSLTCPConnector, and the SIPCertificateInd message that comes from SIPTcp to SIPHandler containing the Subject CN of the remote cluster.

001569030 |2011/09/28 13:57:03.815 |100 |Created   |                                       |                               |SdlSSLTCPConnection(1,100,13,5)  |SdlSSLTCPConnector(1,100,12,3)   |                                         |NumOfCurrentInstances: 1
001569032 |2011/09/28 13:57:03.827 |100 |SdlSig    |SIPCertificateInd                      |wait                           |SIPHandler(1,100,65,1)           |SIPTcp(1,100,57,1)               |1,100,50,1.395726^14.48.44.202^SEP0011215A1AE3 |[T:N-H:0,N:1,L:0,V:0,Z:0,D:0]  connIdx= 19 --remoteIP=14.48.44.22 --remotePort = 5061 --X509SubjectName /CN=CUCM7-SUB1.bbbburns.lab --Cipher AES128-SHA --SubjectAltname =  

SIP Troubleshooting Commands & SIP Call Flows


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.



callflowsip-new.bmp



Step
Action
Description
1.
Setup—PBX A to Gateway 1
Call Setup is initiated between PBX A and Gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2.
INVITE—Gateway 1 to Cisco SIP IP phone
Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer includes the IP address and the port number of the SIP-enabled entity to 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.
  • The port on which the Gateway is prepared to receive the RTP data is specified.
3.
Call Proceeding—Gateway 1 to PBX A
Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4.
100 Trying—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.
5.
180 Ringing—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing response indicates that the user is being alerted.
6.
Alerting—Gateway 1 to PBX A
Gateway 1 sends an Alert message to User A. The Alert message indicates 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 IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200 OK response notifies Gateway 1 that the connection has been made.
8.
Connect—Gateway 1 to PBX A
Gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
9.
Connect ACK—PBX A to Gateway 1
PBX A acknowledges Gateway 1's Connect message.
10.
ACK—Gateway 1 to Cisco SIP IP phone
Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The ACK confirms that Gateway 1 has received the 200 OK response. The call session is now active.
11.
BYE—Cisco SIP IP phone to Gateway 1
User B terminates the call session at his Cisco SIP IP phone and the phone sends a SIP BYE request to Gateway 1. The BYE request indicates that User B wants to release the call.
12.
Disconnect—Gateway 1 to PBX A
Gateway 1 sends a Disconnect message to PBX A.
13.
Release—PBX A to Gateway 1
PBX A sends a Release message to Gateway 1.
14.
200 OK—Gateway 1 to Cisco SIP IP phone
Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200 OK response notifies the phone that Gateway 1 has received the BYE request.
15.
Release Complete—Gateway 1 to PBX A
Gateway 1 sends a Release Complete message to PBX A and the call session 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.

callflowsip-new2.bmp

Step
Action
Description
1.
Setup—PBX A to Gateway 1
Call setup is initiated between PBX A and Gateway 1. The call setup includes the standard transactions that take place as User A attempts to call User B.
2.
INVITE—Gateway 1 to Cisco SIP IP phone
Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer includes the IP address and the port number of the SIP enabled entity to 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.
  • The port on which the gateway is prepared to receive the RTP data is specified.
3.
Call Proceeding—Gateway 1 to PBX A
Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4.
100 Trying—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.
5.
180 Ringing—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing response indicates that the user is being alerted.
6.
Alerting—Gateway 1 to PBX A
Gateway 1 sends an Alert message to User A. The Alert message indicates 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 IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200 OK response notifies Gateway 1 that the connection has been made.
8.
Connect—Gateway 1 to PBX A
Gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
9.
ACK—Gateway 1 to Cisco SIP IP phone
Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The ACK confirms that User A has received the 200 OK response. The call session is now active.
10.
Connect ACK—PBX A to Gateway 1
PBX A acknowledges Gateway 1's Connect message.
11.
INVITE—Cisco SIP IP phone to Gateway 1
User B puts User A on hold. The Cisco SIP IP phone sends a SIP INVITE request to Gateway 1.
12.
200 OK—Gateway 1 to Cisco SIP IP phone
Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP phone that the INVITE was successfully processed.
13.
ACK—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms 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.
14.
INVITE—Cisco SIP IP phone to Gateway 1
User B takes User A off hold. The Cisco SIP IP phone sends a SIP INVITE request to Gateway 1.
15.
200 OK—Gateway 1 to Cisco SIP IP phone
Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP phone that the INVITE was successfully processed.
16.
ACK—Cisco SIP IP phone to Gateway 1
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms 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.

callflowsip-new3.bmp

Step
Action
Description
1.
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
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 field.
  • The media capability User A is ready to receive is specified.
2.
180 Ringing—Cisco SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
3.
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
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 IP phone A to Cisco SIP IP phone B
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone 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 SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with new Session Description Protocol (SDP) session parameters (IP address), which are used to place the call on hold.
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 SIP IP phone A to Cisco SIP IP phone B
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
7.
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
8.
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to reestablish the call.
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 SIP IP phone A to Cisco SIP IP phone B
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
10.
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
A two-way RTP channel is reestablished between IP phone A and IP phone B.


Defining SIP Port in Cisco Unified Communications Manager



sip-1.bmp

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