Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

UNDERSTANDING SIP TRACES

 

SIP traces provide key information in troubleshooting SIP Trunks, SIP endpoints and other SIP related issues. Even though these traces are in clear text, these texts can be gibberish unless you understand fully what they mean.

This document attempts to break down each component of the SIP interaction using a practical approach. We will look at various logs, the SIP messages, headers, SDP information and try to figure out what is going on in a sip voice call transaction.

In as much as I will try to define the under lying layer of the SIP messaging, this document will not go into in-depth analysis of the SIP protocol, so it is advisable to understand SIP protocol technology to be able to understand sip traces.

One key element of troubleshooting is this: To fix a problem, you need to understand the issue, how it works before you can restore it to order.

One popular debug used in troubleshooting a sip solution on a cisco IOS router is

 

“Debug ccsip messages”.

 

To understand The output generated by this debug..We need to understand the Key/fundamental sip messages exchanged during a sip voice call..

1. Invite

2. Trying

3. Ringing

4. ACK

5. OK

 

 

We will look at these messages as we try to understand the debugs. These messages are key in knowing what’s going on. They help us to understand the language been spoken so we are not lost like a non French speaking man in Paris!

Ok enough of grammars, lets dive in! Ready?

INVITE:

An Invite is a SIP requests called methods. There are Six SIP methods described in the SIP specification document RFC 3261 [1].

The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six methods

in SIP.

 

The INVITE method is used to establish media sessions between user agents. In

telephony, it is similar to a Setup message in ISDN

 

 

An INVITE usually has a message body containing the media information

of the caller. The message body can also contain other session information, such

as a resource list in the case of an early offer. If an INVITE does not contain media information, the ACK contains the media information of the UAC.

 

To identify the caller, the called number, the media information and resources advertised in the Invite, SIP invites use headers. Headers are key parameters within the SIP invite and we shall look at them so as to gain full clarity of what’s going on.

 

Let’s look at a sample SIP trace from CUCM. Note this is very similar to what a debug ccsip messages will produce on a CUBE gateway.

 

Here is the call setup for this trace

 

CUCM----------sip trunk------>CUBE---------SIP Trunk--------------->ITSP

(10.105.80.114)                        (10.105.80.174)

 

INVITE with SDP.

 

INVITE sip:14107154522807@10.105.80.174:5060 SIP/2.0

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

From: "Solihull" <sip:01214248526@10.105.80.114>;tag=25526~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-551664735

To: <sip:14107584528207@10.105.80.174>

Date: Mon, 02 Apr 2012 18:12:31 GMT

Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114

Supported: timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 101 INVITE

Expires: 180

Allow-Events: presence, kpml

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Call-Info: <sip:10.105.80.114:5060>;method="NOTIFY;Event=telephone-event;Duration=500"

Cisco-Guid: 1752700672-0000065536-0000007823-0237529354

Session-Expires: 84600

Contact: <sip:01214248526@10.105.80.114:5060>

Max-Forwards: 70

Content-Length: 0

Content-Type: application/sdp

Content-Length: 238

 

v=0

o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14

s=SIP Call

c=IN IP4 10.133.92.102

t=0 0

m=audio 25268 RTP/AVP 18 101

a=rtpmap:18 G729/8000

a=ptime:20

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

 

Now let’s break it up or dissect this piece of information.

 

As we can see there are lots of headers in this invite…

 

 

Via

To

From

Call-ID

CSeq

Contact

Max-Forwards

Expires

 

The INVITE header

 

INVITE sip:14107584528207@10.105.80.174:5060 SIP/2.0

 

This is the first part of the trace usually refrred to as the Request-URI This shows four key things

1. The called number

2. The device responsible for the called number or the device through which the called number will be routed

3. SIP Port number

4. Sip Version..

 

So here we see the called number is: 14107584528207

The gateway responsible for routing to this number is 10.105.80.174

SIP port is 5060 and the Sip version is 2.0

 

The Via Header:

 

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

 

The required Via header field is used to record the SIP route taken by a request

and is used to route a response back to the originator. A UA generating a request

records its own address in a Via header field.

 

Here we see that CUCM is the UA generating this invite and it stamps it IP on the call. This helps identify the origin of the call.

Via header fields contain protocol name, version number, and transport

(SIP/2.0/UDP, SIP/2.0/TCP, etc)

 

The Via header contains what is called the sent-by field. The image below shows the sent by field and this is where the required response will be sent to.

In SIP responses follow the via header except for future requests like ACK and BYE where responses are sent to the contact header

The To and From Headers

 

From: <sip:01214248526@10.105.80.114>;tag=25526~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-551664735

 

To: sip:14107584528207@10.105.80.174

 

The next header fields are the To and From header fields, which show the

originator and destination of the SIP request.

 

Note that the To and From header fields are not reversed in the response message as one might expect them to be. This is because the To and From header fields in SIP are defi ned to indicate the direction of the request, not the direction of the message. Since <sip:01214248526@10.105.80.114 initiated this request, all responses to this INVITE will read

To: sip:14107584528207@10.105.80.174

From: <sip:01214248526@10.105.80.114.

 

Date Header:

 

 

A key component of the sip message. Its tells us the time of the sip request.

 

 

Call ID:

 

Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114

 

The Call-ID header field is an identifier used to keep track of a particular SIP session. The originator of the request creates a locally unique string. Some older implementations also add an “@” and its host name to the string. The initiator of the session that generates the establishing INVITE generates the unique Call-ID and From tag.

 

The Call ID is one of the key components used in troubleshooting. Each UA generates its own Call ID. Sowhen a call originates from CUCM, CUCM generates its own call id and when a call origate from the CUBE, CUBE generate its own call ID.

 

 

 

Cseq Header:

 

 

CSeq: 101 INVITE

The command sequence CSeq header field is a required header field in every request. The CSeq header field contains a decimal number that increases for each request. Usually, it increases by 1 for each new request, with the exception of CANCEL and ACK requests, which use the CSeq number of the INVITE request to which it refers. The CSeq count is used by UASs to determine out-of-sequence requests or to differentiate between a new request (different CSeq) or a retransmission (same CSeq). The CSeq header fi eld is used by UACs to match a response to the request it references

 

 

 

User Agent Header:

 

 

User-Agent: Cisco-CUCM8.6

 

 

This header identifies the UA that is originating this request/response. In this trace we can see that the UA above is CUCM version 8.6.The user agent header helps identify the originator of the request/response.

 

SDP Extensions and Attributes

 

The SDP extensions used in the application/SDP header lists the media capabilities the calling party is willing to receive or negotiate or support for the session. The table below shows the SDP attributes in this test call and the meaning of each attribute/extension. Please note that The RFC 3264[17] specifies that the attributes containing “a=rtpmap” should be used for each media field

 

 

SDP Parameter Parameter                                                             Name

 

v=0

Version Number

o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14

 

Origin

s=SIP Call

Call Subject

c=IN IP4 10.133.92.102

Connection/IP address for RTP stream

t=0 0

time

m=audio 25268 RTP/AVP 18 101

Media

a=rtpmap:18 G729/8000

Attributes-media

a=ptime:20

Attributes-Packetization

a=rtpmap:101 telephone-event/8000

Dtmf attributes

a=fmtp:101 0-15

Dtmf tones

 

Lets look at media attributes below

 

                                             m=audio 25268 RTP/AVP 18 0 8 101

 

This line defines the media attribtes that will be used for the call.

 

               Audio:           means that this is an Audio call, we can also have m=video in case of a Video call

               25268:           Is the dynamic RTP port used for the call

               RTP/AVP:      Represents the RTP/AVP profile number for each of the profiles listed. The profile numbers are explained below

              

               18=G729

               0=PCMU

               8=PCMA

               101=rtp-nte payload

 

 

 

DISSECTING A SIP TRACE

 

Now we have looked at the basics of sip headers and messages, lets use this to understand the following sip trace

 

The call flow for this call is as shown:

 

 

PSTN-------->ITSP------->CUBE--------------->CUCM---------------->IP PHONE

 

 

 

 

ITSP: 10.10.33.132

CUBE:10.100.0.74

CUCM:10.100.0.14

 

 

 

 

1. An inbound call is received on the CUBE from the ITSP. This invite was sent with SDP. NB that this inbound leg of this call will have a unique call ID that shows the origin of the call, highlighted below.

 

Received:
INVITE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-
To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 INVITE
Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 207

v=0
o=BroadWorks 161384582 1 IN IP4 10.10.33.132
s=-
c=IN IP4 10.10.33.132
t=0 0
m=audio 11164 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no

 

+++From our understanding of the traces, we see that the call originates from a device called Broadworks, which advertises G711a, G711u, G729 and uses rtp-nte for DTMF. We also see the IP address for the CUBE to stream its RTP to.+++++

 

2. A new Invite Sent to CUCM.

 

After the CUBE receives the invite, it sends an invite to cucm based on the dial-peers configured.

 

NB: that this new invite is sent with a new CALL-ID. This is very important in understanding the order of thigs especially when troubleshooting issues. We can also see that the CUBE advertises all its SDP attributes, codec, dtmf supported, fax etc.

 

002791: Jun  6 16:07:28.394: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:901926653485@10.100.0.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859
Remote-Party-ID: <sip:07455900064@10.100.0.74>;party=calling;screen=no;privacy=off
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2352544350-2938638817-2514718541-1568562753
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1338998848
Contact: <sip:07455900064@10.100.0.74:5060;transport=tcp>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 68
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 355

v=0
o=CiscoSystemsSIP-GW-UserAgent 8773 2764 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
m=audio 19264 RTP/AVP 18 0 8 100 101
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

3. Next the CUBE sends a trying to ITSP. Trying simply means: I am looking for the number you have requested.

 

002792: Jun  6 16:07:28.394: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1

From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-

To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>

Date: Wed, 06 Jun 2012 16:07:28 GMT

Call-ID:

BW1807283840606121067600210@212.136.178.216

 

CSeq: 558267841 INVITE

Allow-Events: kpml, telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

 

4. Next the CUBE receives a trying from CUCM. The call-ID help us to know where these responses are coming from.

 

002793: Jun  6 16:07:28.396: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0

 

5. Next the CUBE receives ringing from CUCM This informs the CUBE that the called endpoint is ringing

 

002794: Jun  6 16:07:28.412: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859

From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D

To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854

Date: Wed, 06 Jun 2012 16:07:28 GMT

Call-ID:

8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74

 

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Contact: <sip:901926653485@10.100.0.14:5060;transport=tcp>

Content-Length: 0

 

 

6. The CUBE relays this message to the calling party

 

002795: Jun  6 16:07:28.412: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1

From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-

To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8

Date: Wed, 06 Jun 2012 16:07:28 GMT

Call-ID:

BW1807283840606121067600210@212.136.178.216

 

CSeq: 558267841 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: kpml, telephone-event

Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off

Contact: <sip:901127653485@10.100.0.74:5060>

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

 

 

7. Now the CUBE receives a 200 ok from CUCM. Please note that some elements of the SDP has changed

 

c=IN IP4 10.100.20.10------------------------IP address to send RTP stream to

t=0 0 -------------------------------------------Duration of the call

m=audio 16730 RTP/AVP 18 101---------Codec to use for call and DTMF type to use

a=rtpmap:18 G729/8000-------------------Codec = G729

 

 

 

002796: Jun  6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  84600;refresher=uas
Require:  timer
Contact: <sip:901127653485@10.100.0.14:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 237

v=0
o=CiscoSystemsCCM-SIP 811674 1 IN IP4 10.100.0.14
s=SIP Call
c=IN IP4 10.100.20.10

t=0 0

m=audio 16730 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message

 

002797: Jun 6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:901127653485@10.105.40.14:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953DC95

From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D

To: <sip:901127653485@10.105.40.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854

Date: Wed, 06 Jun 2012 16:07:28 GMT

Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: kpml, telephone-event

Content-Length: 0

 

9. CUBE then sends a 200 OK to ITSP with the SDP attributes to use for the Call based on what it received from CUCM.

 

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.14:5060;branch=z9hG4bK198a0b7ee5d33c
From: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854
To: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 101 SUBSCRIBE
Content-Length: 0
Contact: <sip:07455900064@10.100.0.74:5060;transport=tcp>
Expires: 7200

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-
To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: kpml, telephone-event
Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:441127653485@10.100.0.74:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 7413 6169 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
m=audio 29626 RTP/AVP 18 101
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

 

10. CUBE then receives an ACK

 

002803: Jun  6 16:07:28.594: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:441127653485@10.100.0.74:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0.1

From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-

To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8

Call-ID:

BW1807283840606121067600210@212.136.178.216

 

CSeq: 558267841 ACK

Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>

Max-Forwards: 69

Content-Length: 0

 


11. Finally the call is ended. Now when troubleshooting the direction of call termination is important. In this case we can see that the CUBE receives a BYE, which is the sip method for call termination. However who sent the BYE, is it CUCM or ITSP…The answer is in the Call-ID. As we call can see the CALL-ID is for the leg from the ITSP. So we see that the call was terminated from the ITSP side.

 

Next important thing is the cause code. The reason why the call was terminated.

 

                                CSeq: 558267842 BYE

        Reason: Q.850;cause=16

 

Here we see as normal call clearing Cause=16.

 

Received:
BYE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-
To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
Max-Forwards: 69
Content-Length: 0

 

002809: Jun  6 16:07:34.470: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=1526438727-1338998848384-
To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E-1CF8
Date: Wed, 06 Jun 2012 16:07:34 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 558267842 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5
Content-Length: 0


002810: Jun  6 16:07:34.470: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:901127653485@10.100.0.14:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1338998854
CSeq: 103 BYE
Reason: Q.850;cause=16

 

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-477917854
Date: Wed, 06 Jun 2012 16:07:34 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 103 BYE
Content-Length: 0

 

Below are a few of the Threads that we have used the indepth understanding of sip trcaes to help resolve thier issues. Please take a look as this will help you to understand better sip traces and how they play a key part in troubleshooitng issues

 

https://supportforums.cisco.com/message/3646952#3646952

 

https://supportforums.cisco.com/message/3634572#3634572

 

https://supportforums.cisco.com/message/3624258#3624258

 

https://supportforums.cisco.com/message/3653801#3653801

 

Please feel free to ask any questions and I will be happy to answer to the best of my knowledge. Dont forget to hit the stars, if you find this useful.

Version history
Revision #:
1 of 1
Last update:
‎09-28-2012 06:37 AM
Updated by:
 
Labels (1)
Everyone's tags (3)
Comments

I have to say that was great

thanks

VIP Super Bronze

Thanks Abdullahi, I am happy you find it useful

New Member

thanks helped lot

Excellent document ! Verymuch useful for troubleshooting.

Regards

Lavanya

Technical Community Manager - Cisco Support Community

Useful... Expecting the same for H.323, ss7 traces

VIP Super Bronze

Thank you. I am glad you find it useful

VIP Super Bronze

Lavanya,

That is very encouraging coming from you. Thank you

New Member

This document helped me very much in understanding the SIP messages.

I have a question at step 7, 200 OK recieved from CUCM

c=IN IP4 10.110.0.20------------------------IP address to send RTP stream to

but I see in SDP there is c=IN IP4 10.100.20.10,

I think this is just typo??

VIP Super Bronze

Yes that is a typo. I will correct it. I am happy it helped you and thanks for the feedback

New Member

Awesome document.

Saw your comments regarding SIP troubleshooting in some discussions.

You have great knowledge on SIP.

Kindly suggest how to develop SIP skills.

Thanks in advance

Aman

VIP Super Bronze

Aman,

Thanks for the comment. Understanding the traces starts with understanding the technology..If you want to know SIP I suggest you read this book

understanding sip by Alan b Johnston. Its a great book

http://books.google.co.uk/books/about/SIP.html?id=VMP6gCBazzIC

You can also spend time online to know more about sip, how things work and then look at traces in detailed.

If you have any more questions, I will be happy to help

Hi Mate

Good Job (5 stars)

Keep doing the great job that you are doing in this forum

Regards

chrysostomos

VIP Super Bronze

Thanks Chrys..You doing a great job too. Lets continue to make the forum AWESOME!

New Member

5 stars... im sharing this document to my colleagues

can you write here CUBE config

New Member

Excellent write up. 

New Member

Fantastic explanation.  Does anyone know in a SIP trace for a phone sending a keepalive to a call manager how do you distinguish between the primary and secondary servers? 

Thanks!

New Member

it's just what I'm looking for. Wonderful.

I have a question though, we are currently configuring cube-sp using ASR1001 and about to simulate calls to find out the max calls it can handle. Our test tool is able to simulate calls but I'm having difficulty passing calls succesfully in the cube.

The setetup only involves [tool interface 1] ------->(CUBE)-------->[tool interface 2]

First, I was sending SIP traffic from the address of [tool Int 1]  to [tool int 2] address and that didn't work. I then found out that I should be sending from [tool int 1] address to (cube receiving interface) and that will route the call to the (cube adj interface) then to the [tool int 2].

The problem I have now, is I'm getting error 408 in debug messages as well "SIP is discarding message due to Via Branch". The test tool is generating the Branch parameter prefix with the magic cookie and I can see from the wireshark trace that Branch in Invite, Trying Ringing, are all the same but not from the ACK. Is this normal?

Any assistance is appreciated.

New Member

Excellent doc, very useful.

Have a question, what message will CUCM generate if a SIP phone unregistered.

VIP Super Bronze

Murali,

SIP de-registration is performed by sending a REGISTER message with either a Contact header containing an 'expires=0' parameter or an Expires header with value 0

Hence the REGISTER method is still used however the expires header will be set to 0..

eg..

When a phone first REGISTER, you will get this..

+++++

REGISTER sip:titan-pub.sipnet5.com SIP/2.0
Via: SIP/2.0/UDP 5.5.5.7:58632;branch=z9hG4bK-d8754z-da08d10e221f1f0f-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:3881070@5.5.5.7:58632;rinstance=49dceefe6bc74ab0>
To: "3881070"<sip:3881070@titan-pub.sipnet5.com>
From: "3881070"<sip:3881070@titan-pub.sipnet5.com>;tag=49185324
Call-ID: M2IwZGRlNzM3NjI5Mjk3MDJjNzg5ZTk5ZmY1MTM3NmI.
CSeq: 1 REGISTER
Expires: 300--------------------------------------------------------Registration Expires in 300sec

When the phone de-REGISTER..you will get this..

+++++++

REGISTER sip:titan-pub.sipnet5.com SIP/2.0
Via: SIP/2.0/UDP 5.5.5.7:58632;branch=z9hG4bK-d8754z-da08d10e221f1f0f-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:3881070@5.5.5.7:58632;rinstance=49dceefe6bc74ab0>
To: "3881070"<sip:3881070@titan-pub.sipnet5.com>
From: "3881070"<sip:3881070@titan-pub.sipnet5.com>;tag=49185324
Call-ID: M2IwZGRlNzM3NjI5Mjk3MDJjNzg5ZTk5ZmY1MTM3NmI.
CSeq: 1 REGISTER
Expires: 0--------------------------------NB Expires is set to 0

Green

Great Work (+5)

New Member

Hi aokanlawon,

Was going through the SIP troubleshooting links you provided.

For the discussion : https://supportforums.cisco.com/message/3653801#3653801

Just for educational pupose I wanted to clarify a doubt.

If i have understood the requirement properly:

1. CUBE is influencing the Codec negotiation

2. We want codec negotiation between ITSP and CUCM directly

Can we use "codec transparent" in dial-peers to let CUCM decide the Codec ?

Regards,

Aman

VIP Super Bronze

Aman,

The direction of the call determines who influences the codec selection..

+++INBOUND LEG+++++

on the inbound leg..

The region setting will take effect regardless of what you have configured on the voice-class codec for your inbound dial-peer. This is because when 200 ok is sent CUCM will send the codec defined between the endpoint and the CUBE as the codec. CUBE then passes this on to ITSP.

+++OUTBOUND LEG++++

on the outbound direction...

The advertised codec to ITSP will be used, beacuse ITSP is the one making decision which codec to use based on advertised codec.So here with voice class codec, the preffered codec in the list will be selected by the ITSP and this will be used for the call regardless of what the region setting is on the phone to the cube gateway.

if the codec is hardcoded..if its set to g711, then g711 response will be obtained from the ITSP and that codec will be used for the call.

if its g729 then it will be g729...

2. If you have CUBNE between ITSP and CUCM. then you cant have direct negotiation between ITSP and CUCM,

You dont need codec transparent to let cucm decide which codec to use in the inbound direction..CUCM will always do that as explained above. Codec transparency is only supported for H.323-to-H.323 calls.

New Member

 

This is one if the best document for SIP. Thank you very for depth analysis and excellent explanation. 

Cheers 

Uma Maheshwaran

New Member

Just found this post, well done!!

very nicely documented, nothing new, but well condensed!  keep up the good work 

New Member

Excellent work Ayodeji... keep it up!

New Member

This is awesome Ayodoji, it is very helpful for me.

 

One small doubt, there is an RTP information in the BYE message. 

P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5

The packet loss, jitter and lattency are always zero. Any reason for that? 

 

Thanks,

Pandian

VIP Super Bronze

Yes this is to provide the call statistics for the call. This can help in troubleshooting call quality. This is usually sent in the BYE message..

Don't forget to rate the document

New Member

Yes Ayodeji, I understand.

But they all comes as zero always. Is there any configuration I am missing to turn them on?

My (+5) for the document.

 

Thanks,

Pandian

VIP Super Bronze

Its zero probably because there is no latency, jitter or packet loss. So there is nothing to worry about. It means you have a good network. You have done a great job :)

New Member

Thanks Ayodeji :)

New Member

Hey hi Ayodoji,

Hope you're fit-n-fine. Your drafted document is very helpful to me for understanding the traces. Will you let me and correct if am wrong.

Supported: replaces   ----------------- (This command is supported and can be configured. Correct?)

Supported: sdp-anat

m=audio 29588 RTP/AVP 0 19

a=rtpmap:19 CN/8000

a=inactive

 

 

regards,

Ritesh Desai.

VIP Super Bronze

Hi Ritesh,

The Supported header is used to define any sip extension that the UAC supports. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog.  This is used for 
features such as: "Attended Transfer" and "Call Pickup". 

Hope this answers your question. Don't forget to rate the document..

New Member

Tank you sir for te good Doc.

I am learning sip.Please consider my doubts

What is the significance of content length. What is the meaning if content length is 0 or any other value?

Is CUbe act as a proxy server here?

And CUCM will do the functon of a registrr server right?

Excellent information Deji for anyone who wants to start with SIP, [+5].

I would  have rate 10 if I can :)

- Vivek

VIP Super Bronze

Thank you as always for the encouragement. Most appreciated.

VIP Super Bronze

Manzoor,

The Content-Length is used to indicate the number of octets in the message body. A Content-Length: 0 indicates no message body. This is usually used to indicate if there is SDP in the message ( in the case of a sip INVITE)

Examples:

In this first INVITE, there is no message body, hence we have a content lenght of "0"

Received:
INVITE sip:01785625736@192.168.10.200:5060 SIP/2.0
Via: SIP/2.0/UDP  192.168.10.14:5060;branch=z9hG4bK39e91a3ffb2b83
From:   <sip:01185425746@ 192.168.10.14>;tag=1882131~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-602547130
To: <sip:01785625736@192.168.10.200>
Date: Wed, 13 Feb 2013 15:22:00 GMT
Call-ID: 1b442180-11b1af98-d844e-e28690a@ 192.168.10.14
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip: 192.168.10.14:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0457449856-0000065536-0000561076-0237529354
Session-Expires:  84600
Contact: <sip:01185425746@ 192.168.10.14:5060>
Max-Forwards: 70
Content-Length: 0

#### In this next INVITE we have a message body (SDP) in the INVITE, hence we have a  content-type ( this will tell us what kind of content we have in the message body), then a content-length  

Sent:
INVITE sip:01785625736@10.106.33.24:5070 SIP/2.0
Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK10D68412602
Remote-Party-ID:   <sip:441733293943@192.168.10.200>;party=calling;screen=no;privacy=off
From:   <sip:441733293943@192.168.10.200>;tag=5DA6E490-1672
To: <sip:01785625736@10.106.33.24>
Date: Wed, 13 Feb 2013 15:22:00 GMT
Call-ID: F27D7F72-752711E2-8CA2FE93-B3867CA6@192.168.10.200
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 0457449856-0000065536-0000561076-0237529354
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1360768920
Contact: <sip:441733293943@192.168.10.200:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Session-Expires:  84600
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 358

v=0
o=CiscoSystemsSIP-GW-UserAgent 1428 3688 IN IP4 192.168.10.200
s=SIP Call
c=IN IP4 192.168.10.200
t=0 0
m=audio 26388 RTP/AVP 18 0 8 100 101
c=IN IP4 192.168.10.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

For your next question:

CUBE and CUCM are B2BUA. This means that they can both innitiate a request and then at the same time provide a response to requests. A B2BUA combines both the functionality of a UAC and a UAS. A UAC is a user agent client that innitiates a request and a UAS is a user agent server that generates a response to the request.

A proxy server relays requests and responses, so CUBE is not a proxy server. A proxy most times just acts as a middle man between the client and the terminating server.

CUCM is not a typical registrar server. It does perform some functionality of a registrar server. A typical registrar server also known as a registration server, accepts SIP REGISTER requests; all other requests receive a 501 Not Implemented response. But like I said CUCM does more that just accepting sip REGISTER requests

Hope its clearer now.

You can watch these webcast to get a better understanding of the SIP protocol

https://supportforums.cisco.com/video/12394941/vip-webcast-recording-troubleshooting-sip-cisco-unified-communications-deployments

New Member

Thank you Sir!

VIP Super Bronze

You are most welcome. Dont forget to rate the document :)

New Member

Hi, Would you explain the what type of information carry to 100 trying 180 ringing 200 ok message. 

New Member

Awesome Document with detailed description.Helped a lot in understanding the concept.Thanks !!!!

VIP Super Bronze
Thanks for the feedback. Don't forget to rate the document
New Member

Just watched your Troubleshooting SIP in UC Deployments video to go along with this document.  Both are excellent.  We've been having quite a few issues with moving over from H323 to SIP between our CUBE and CUCM.  Mainly in regaurds to faxing using g711ulaw pass through since T.38 isn't support on the SIP trunk that we have from our ITSP.  Show I needed a better understanding of what I'm seeing in the debugs and not just taking the provider or TAC's word for it.

VIP Super Bronze

Louis,

Thank you for the feed back. Its because of people like you I wrote this. Engineers willing to go the extra mile.

All the best.

New Member

.Is it mandatory to enable debug to be able to see the invite ,ok ,Ringing ,... or we can put Wire shark to capture those messages without enabling debug in the CUBE? 

VIP Super Bronze

The debugs are the easiest way of seeing the sip transaction in CUBE. You cant use wireshark natively with CUBE, you will have to configure and enable "wireshark like" captures in CUBE.

New Member

Thanks. Great tutorial !!

Q: In the Step 9, why are there 2  200 OK ?  What mean CSeq: 101 SUBSCRIBE inthe first 200 OK  ?

New Member

Now you don't need to take any stress about your exam. We are here for you. We provide you real exam questions. You can get same questions in your exam we ensure you that you will pass your exam in first attempt.

It's not easy to pass neither you can't do it. We will help you by our quality assured dumps.

Here you can get the latest exam questions in PDF format.

Cisco 100-101 Dumps

New Member

HI ,

I really appreciate the way u taught all this.

I m failry new to sip ,first I wanted to know what do you mean by CUCM,ITSP,CUBE.

Second thing when there is a call so it two different IP for invite and media?