Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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..
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?
An Invite is a SIP requests called methods. There are Six SIP methods described in the SIP specification document RFC 3261 .
The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six methods
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.
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:firstname.lastname@example.org initiated this request, all responses to this INVITE will read
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: 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:
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 specifies that the attributes containing “a=rtpmap” should be used for each media field
SDP Parameter Parameter Name
o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14
c=IN IP4 10.133.92.102
Connection/IP address for RTP stream
m=audio 25268 RTP/AVP 18 101
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
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
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.
+++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.
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.
Received: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8 From: <sip:email@example.com>;tag=4C85762C-1A2D To: <sip:firstname.lastname@example.org>;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