Understanding Sip Traces - Cisco Technical Support Forum

29/5/2014 UNDERSTANDING SIP TRACES | Cisco Technical Support Forum
https://supportforums.cisco.com/document/113271/understanding-sip-traces 1/30

Search
Language: English
English
(Japanese)
Espaol (Spanish)
Portugus (Portuguese)
P (Russian)
(Chinese)
Contact Us
Help
Follow Us
LinkedIn
YouTube
Newsletter
Instagram
Facebook
Twitter
Google +
Community Directory
Expert Corner
Solutions
Community Corner
Community Resources
Cisco
Cisco Support Community
Community Directory
Network
Infrastructure
WAN, Routing and Switching
Security
VPN
Security Management
Firewalling
Service
Providers
Metro
Expert Corner
Top Contributors
Leaderboards
Knowledge Sharing
Experts Bureau
Cisco Live! Events
Solutions
Cisco SMB Marketplace
Cisco On Demand
OnDemand Solutions
Community Corner
Awards & Recognitions
Behind the Scenes
Cisco Cafe
Cisco.com Idea Center
Community Ideas
Feedback Forum
Mobile Community
Login | Register
LAN, Switching and Routing
Network Management
Remote Access
Optical Networking
Getting Started with LANs
IPv6 Integration and Transition
EEM Scripting
Other Subjects
Intrusion Prevention
Systems/IDS
AAA, Identity and NAC
Physical Security
MARS
Email Security
Web Security
Other Subjects
MPLS
Voice Over IP
XR OS and
Platforms
Video
Other Subjects
Collaboration,
Voice and
Video
IP Telephony
Video Over IP
Jabber Clients
Unified
Communications
Applications
TelePresence
Digital Media
System
Contact Center
Conferencing
UC Migrations
Other Subjects
Wireless - Mobility
Security and Network
Management
Wireless IP Voice and Video
Getting Started with Wireless
WLCCA
Other Subjects
Services
Partner Support Service
Cisco ServiceGrid
Smart Call Home
Smart Care
Customer Premises Equipment (CPE) Support
Compliance Management and Configuration
Service
Smart Net Total Care
Operations Exchange
Mobile
Applications
Cisco Proximity
Cisco Technical Support
Online Tools
and
Resources
Cisco Bug
Discussions
Technical
Documentation
Ideas
Support
Community
Help
Data Center
Application Networking
Server Networking
Storage Networking
Unified Computing
Wide Area Application Services
(WAAS)
Other Subjects
Small Business
Network Storage
Routers
Security
Surveillance
Switches
Voice and
Conferencing
Wireless
Solutions
and
Architectures
Borderless
Networks
Collaboration
Data Center
and
Virtualization
Cisco User Groups
Seattle Cisco User Group (SEACUG)
Silicon Valley Cisco User Group (SVCUG)
Southern California Cisco User Group
(SCCUG)
Search
Home/
Collaboration, Voice and Video
Additional Communities
Community Corner
Data Center
Mobile Applications
Network Infrastructure
Wireless - Mobility
Service Providers
Small Business Support Community
Security
Solutions and Architectures
Services
Top Contributors
Cisco User Groups
On Demand
Online Tools and Resources
Private
/
IP Telephony
Video Over IP
Jabber Clients
Unified Communications Applications
Prime Collaboration Management
TelePresence
Digital Media System
Contact Center
Conferencing
Other Collaboration, Voice, and Video Subjects
UC Migrations
Language: English
English
(Japanese)
Espaol (Spanish)
Portugus (Portuguese)
P (Russian)
(Chinese)
Contact Us
Help
Follow Us
LinkedIn
YouTube
Newsletter
Instagram
Facebook
Twitter
Google +
UNDERSTANDING SIP TRACES
Document
Sep 28, 2012 6:37 AM
Ayodeji oladipo... 2 years ago
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
whats 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 whats going on.
Lets 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 lets 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 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-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=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-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=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.
Sent:
SIP/2.0 100 Trying
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
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.
Received:
SIP/2.0 100 Trying
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
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
Received:
SIP/2.0 180 Ringing
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-Events: presence
Content-Length: 0
6. The CUBE relays this message to the calling party
Sent:
SIP/2.0 180 Ringing
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
REGISTER
Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:901127653485@10.100.0.74:5060>
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
Received:
SIP/2.0 200 OK
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 INVITE
Allow-Events: presence, kpml
Supported: replaces
Session-Expires: 84600;refresher=uas
Require: timer
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
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=fmtp:101 0-15
8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message
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
Date: Wed, 06 Jun 2012 16:07:28 GMT
Max-Forwards: 70
CSeq: 101 ACK
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
CSeq: 101 SUBSCRIBE
Content-Length: 0
Expires: 7200
Sent:
SIP/2.0 200 OK
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216
REGISTER
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
Supported: timer
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
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
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
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 ITSPThe 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
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
Date: Wed, 06 Jun 2012 16:07:34 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5
Content-Length: 0
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
Date: Wed, 06 Jun 2012 16:07:28 GMT
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1338998854
CSeq: 103 BYE
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
Date: Wed, 06 Jun 2012 16:07:34 GMT
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
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.
Rating
Average Rating: 5 (21 ratings)
Log in or register to post comments
Share:
Comments
abdullahimemphis08 2 years ago
I have to say that was great
thanks
See More
Ayodeji oladipo... 2 years ago (reply to abdullahimemphis08)
Thanks Abdullahi, I am happy you find it useful
See More
searskarthik about a year ago
thanks helped lot
See More
Ayodeji oladipo... about a year ago (reply to searskarthik)
Thank you. I am glad you find it useful
See More
rajendransify17 about a year ago
Useful... Expecting the same for H.323, ss7 traces
See More
mpaneers about a year ago
Excellent document ! Verymuch useful for troubleshooting.
Regards
Lavanya
Technical Community Manager - Cisco Support Community
See More
Ayodeji oladipo... about a year ago (reply to mpaneers)
Lavanya,
That is very encouraging coming from you. Thank you
See More
ulambaday about a year ago
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??
See More
Ayodeji oladipo... about a year ago (reply to ulambaday)
Yes that is a typo. I will correct it. I am happy it helped you and thanks for the feedback
See More
amansin74 about a year ago
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
See More
Ayodeji oladipo... about a year ago (reply to amansin74)
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
See More
chrysostomos1980 about a year ago
Hi Mate
Good Job (5 stars)
Keep doing the great job that you are doing in this forum
Regards
chrysostomos
See More
Ayodeji oladipo... about a year ago (reply to chrysostomos1980)
Thanks Chrys..You doing a great job too. Lets continue to make the forum AWESOME!
See More
nirmalissac about a year ago
5 stars... im sharing this document to my colleagues
See More
saravanaboobathy about a year ago
Very good explanation...... 5 Stars..... i am sharing it to my friends right away..... u r rocking.... keep it up...
See More
ttemirgaliyev about a year ago
can you write here CUBE config
See More
rajeshkh about a year ago
Excellent write up.
See More
nathangageby 12 months ago
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!
See More
wythat001 8 months ago
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.
See More
muraligprt 6 months ago
Excellent doc, very useful.
Have a question, what message will CUCM generate if a SIP phone unregistered.
See More
Ayodeji oladipo... 6 months ago (reply to muraligprt)
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
See More
acampbell 6 months ago
Great Work (+5)
See More
amansin74 3 months ago
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
See More
Ayodeji oladipo... 3 months ago (reply to amansin74)
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.
See More
gumamah2@ford.com 7 days ago
Show
- Any -

This is one if the best document for SIP. Thank you very for depth analysis and excellent explanation.
Cheers
Uma Maheshwaran
See More
Actions
Login or Register to take actions
This Document
Posted September 28, 2012 at 6:37 AM
By Ayodeji oladipo Okanlawon
Stats:
Comments: 25 Avg. Rating: 5
Views: 38264 Contributors: 17
Shares: 2
Tags: sip, understanding, traces
-
Follow
Shortcut
Abuse
Save
Related Content
Discussion
Strange CM-Group Behaviour
Peter Bishop
1 week 1 hour ago
65 views
Discussion
SRST SIP
markhollingsworth
2 weeks 1 day ago
24 views
Discussion
Converting CISCO 7940G to SIP
art-craft
3 weeks 6 days ago
30 views
Discussion
Voice Call Debug Filter command
r-white
4 weeks 1 day ago
53 views
Discussion
ASA SIP inspection
gokul.poomari
1 month 5 days ago
51 views
Documents Leaderboard
All Time Monthly
Rank Username Points
1
Ayodeji oladipo...
237
2
TCC_2
87
3
Greeshma Bernad
40
4
PAWS
15
5
kusatija
15
View Full Leaderboards
Information For
Small Business
Midsize Business
Executives
Home
Service Provider
Industries
Contacts
Contact Cisco
Find a Reseller
News & Alerts
Newsroom
Blogs
Field Notices
Security Advisories
Technology Trends
Cloud
IPv6
Mobility
Open Network Environment
Trustworthy Systems
Support
Downloads
Documentation
Communities
Developer Network
Learning Network
Support Community
Video Portal
About Cisco
Investor Relations
Corporate Social Responsibility
Environmental Sustainability
Tomorrow Starts Here
Career Opportunities
Programs
Cisco Designated VIP Program
Cisco Powerered
Financing Options
Terms & Conditions
Privacy Statement
Cookie Policy
Trademarks of Cisco Systems, Inc.


Understanding Sip Traces - Cisco Technical Support Forum

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding Sip Traces - Cisco Technical Support Forum

Uploaded by

Copyright:

Available Formats

29/5/2014 UNDERSTANDING SIP TRACES | Cisco Technical Support Forum

29/5/2014 UNDERSTANDING SIP TRACES | Cisco Technical Support Forum

You might also like