Articles in this section

Understanding SIP Traces

Avatar
Bruce Clark
Updated

Our support team will often ask you for a "SIP Trace" (or 'pcap') in order to help diagnose any issues you're having.

These traces are simple text files (or a simple text file can be created from the pcap) but are not intended to be human-readable and are often confusing. A "pcap" is a full packet capture, and provides a lot more information than a simple SIP trace, so is preferred where possible - especially if you have an issue with call audio.

The ultimate authority on SIP is the specification RFC 3261, but below we'll take a look at an example call and the corresponding SIP trace, together with some common errors you might see, to help you debug your SIP calls.

There are a few common messages you'll see in most calls, some with simple text names e.g;

  • INVITE
  • ACK
  • BYE

And some numeric codes, followed by a human-readable description;

  • 100 Trying
  • 180 Session Progress
  • 183 Ringing
  • 200 OK

If you're familiar with HTTP, you'll recognise some of these numbers, they have (mostly) the same meaning in SIP as in HTTP.

INVITE

The INVITE is used to set up a new media session between endpoints. Think of it as a request for a new call, or IAM if you're familiar with C7 signalling.

The INVITE will contain a number of "headers" much like eMail headers or HTTP headers, these provide detail such as the calling party, and important information about call routing.

The INVITE will also typically contain session information in the form of SDP, which details how to send media to/from your endpoint

INVITE sip:443301223043@example.domain.com SIP/2.0
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK4c3b.89da53d6c866068371492213a605b2b4.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.78;rport=5060;branch=z9hG4bKUBp1X76ZFr2UD
Max-Forwards: 64
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com;transport=tcp>
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814375 INVITE
Contact: <sip:mod_sofia@178.22.139.78:5060>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Privacy: id
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 299

v=0
o=root 14193896 14193896 IN IP4 178.22.139.77
s=sip call
c=IN IP4 178.22.139.77
t=0 0
a=rtpengine:d64117c145f7
m=audio 57152 RTP/AVP 8 101
b=RR:3000
b=RS:1000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:40
a=rtcp:57153
a=ptime:20

RURI

The first line after INVITE is known as the Request URI ("RURI"), this is the number you're calling so in the above the number dialled is 03301223043 shown in E.164 format (sip:443301223043@example.domain.com;transport=tcp)

Parameters after the semi-colon are used to provide additional information, in this case this is a call that used TCP rather than the default UDP.

Via Headers

The Via header shows the route taken by the request and is used to route the reply. Each path generating a request appends it's own Via header.

The Via header includes the IP address responses to this request should be sent to.

To/From

The From header denotes the originating party and will be used as CLI if no P-Asserted-Identity header is provided

The To: line also shows the dialled party, although it's important to note that the RURI is what is used to route the call, not the To line.

Call ID

The Call ID is unique and generated by the originating UA. Each call had a unique Call ID and this information can be useful when identifying calls.

CSeq

CSeq is a Command Sequence number and is required in every request, typically this will be incremented by 1 with each new request.

This can be used to determine if a request is new or re-transmitted (i.e. a reply was never received)

A CANCEL or ACK request will always contain the same CSeq number of the INVITE message it is replying to.

Contact

The Contact header is used for sending future requests (such as ACK and BYE) relating to this call.

SDP

The body of an INVITE request is an SDP ("Session Description Protocol") message, that defines the media attributes for the call.

This information is used to negotiate the media on the call between endpoints (e.g. what IP media should be sent to/from and also what codec(s) to offer)

v=

This is the "version" line, and is always v=0

o=

This is the "origin" line, and contains useful information, although is not used for call routing purposes. The first parameter ("root" in this example) is the username on the host, although often this is populated with a dummy value. The next is the session ID, whilst there's no standard for this most SIP platforms use a unix timestamp for this value. The next parameter is the session version, again it is recommended the timestamp is used here. The next two will always be "IN" (Internet) and "IP4" (IPv4) followed, finally, by the IP address of the machine which created the session.

s=

This is the "subject" line, and is typically "SIP Call", the name of the PBX (e.g. Asterisk) or empty; it's not used by the SIP platform.

c=

This is the "contact" or "connection" line, and contains the IP address for the RTP media. 

m=

This is the "media" line and defines the port to be used, together with the codecs supported e.g. m=audio 57152 RTP/AVP 8 101

Looking at this in turn; 'audio' denotes that this is a voice call, '57152' is the port that will be used for RTP media.

RTP/AVP followed by digits denote the codec offers, 0 and 8 are "reserved" and always represent PCMU (uLaw) and PCMA (aLaw) respectively, any other codes here will be defined by 'rtpmap' attributes, explained below;

a=

These are the "attribute" lines and refer to specific codecs, for examples a=rtpmap:18 G729/8000 indicates that payload type 18 represents G.729

Another exmaple of an attribute, would be DTMF which may appears as a=rtpmap:101 telephon-event/8000 indicating that RFC2833 DTMF is being used on this call.

Packetisation time (or "ptime") is also shown in an attribute line e.g. a=ptime:20

So in our example INVITE (with SDP) we can see this is a call from an anonymised number to 443301223043, it's offering G711u and G711a codecs, and RFC 2833 DTMF. The PBX is at 178.22.139.77 and expects RTP media on port 57152

100 Trying

Almost immediately, you'll get back a 100 Trying message from us that looks like this;

SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK4c3b.89da53d6c866068371492213a605b2b4.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.78;rport=5060;branch=z9hG4bKUBp1X76ZFr2UD
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814375 INVITE
Content-Length: 0

This is simply an acknowledgement that the request was received, note that the CSeq number and Call ID will correspond to that in your original INVITE.

No SDP is returned at this stage, because we haven't determined the routing of the call, or if it will even complete.

180 Ringing / 183 Session Progress

Here is where the paths can diverge a bit, assuming the number was valid, all fraud checks passed, and you've got credit on your account etc the call will be passed to the PSTN and you'll get back a 180 or 183.

A 180 Ringing message indicates the call is ringing at the remote end and doesn't contain any additional information or SDP.

At this stage your PBX or phone will generate ringback tone

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK4c3b.89da53d6c866068371492213a605b2b4.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.78;rport=5060;branch=z9hG4bKUBp1X76ZFr2UD
Record-Route: <sip:10.0.0.0;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Record-Route: <sip:178.22.139.77;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Record-Route: <sip:178.22.139.78;lr>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>;tag=as3aeeee26
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814375 INVITE
Server: Sipcentric PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:443301223043@10.0.0.0:5070>
Content-Length: 0

A 183 Session Progress is otherwise known as "Early Media", this will include RTP data, sometimes this will contain local-specific ringback tone (e.g. when calling an international destination and the remote network provides it) alternatively this is also often used for playback of a Recorded Announcement ("RCAN")

You are not charged for a call at 183 Session Progress stage so some carriers use this to play back a message indicating that a number is not in service and will subsequently follow the message with a rejection (e.g. 404)

200 OK

Your call has been answered, this is the final stage of negotiating the call setup. This will look similar to the INVITE but the SDP provides information about the remote party.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK4c3b.89da53d6c866068371492213a605b2b4.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.78;rport=5060;branch=z9hG4bKUBp1X76ZFr2UD
Record-Route: <sip:10.0.0.0;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Record-Route: <sip:178.22.139.77;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Record-Route: <sip:178.22.139.78;lr>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>;tag=as3aeeee26
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814375 INVITE
Server: Sipcentric PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:443301223043@10.0.0.0:5070>
Content-Type: application/sdp
Content-Length: 272

v=0
o=root 1047519444 1047519444 IN IP4 178.22.139.77
s=Sipcentric PBX
c=IN IP4 178.22.139.77
t=0 0
a=rtpengine:f2a5fcbb4287
m=audio 58140 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:58141
a=ptime:20

The SDP lines are similar to those in the INVITE above, the c= line now contains the IP address your platform will send media to in order to be heard by the remote party, the m= line will indicate what codec to use together with any parameters in the a=rtpmap lines.

At this point the call is now established, and two way audio should take place.

ACK

Your platform should acknowledge the 200 OK. This important, if the 200 OK is not ACK'd the call will be torn down automatically after a short time.

ACK sip:443301223043@10.0.0.0:5070 SIP/2.0
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK4c3b.2691d73829e65160d4fe9628f6526b8b.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.8;rport=5060;branch=z9hG4bK99Qvp2jH7mt1F
Route: <sip:178.22.139.77;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Route: <sip:10.0.0.0;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Max-Forwards: 69
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>;tag=as3aeeee26
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814375 ACK
Contact: <sip:mod_sofia@178.22.139.77:5060>
Content-Length: 0

Note that the CSeq has increased (as ACK is - somewhat counter-intuitively - considered to be a new request, not a reply) , but the Call ID remains the same.

BYE

When the call ends a BYE is sent by the party ending the call. The BYE is a simple message with the same Call ID as the original INVITE but a different CSeq.

BYE sip:443301223043@10.0.0.0:5070 SIP/2.0
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK1c3b.61c7c4b79af4b0d2ac6f87486783087f.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.8;rport=5060;branch=z9hG4bK7SQX4F7BmXZ8D
Route: <sip:178.22.139.77;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Route: <sip:10.0.0.0;r2=on;lr;ftag=BgKUj7H2K9Ber;did=9b9.d0d>
Max-Forwards: 69
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>;tag=as3aeeee26
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814376 BYE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Reason: Q.850;cause=16
Content-Length: 0

On receipt of this BYE the call is hung up. BYE is a new request (like an INVITE) and therefore the other party will respond with a 200 OK just as they would to an INVITE.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 178.22.139.77;branch=z9hG4bK1c3b.61c7c4b79af4b0d2ac6f87486783087f.0
Via: SIP/2.0/UDP 178.22.139.78;received=178.22.139.78;rport=5060;branch=z9hG4bK7SQX4F7BmXZ8D
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=BgKUj7H2K9Ber
To: <sip:443301223043@example.domain.com>;tag=as3aeeee26
Call-ID: b9e213cb-196f-123b-7e91-0242ac110006
CSeq: 48814376 BYE
Server: Sipcentric PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Note that the 200 OK message contains the same CSeq as the BYE message (and indicates it's acknowledging a BYE)

When it doesn't work

The above illustrates a successful call, obviously calls occasionally fail. A failed call will never receive a 200 OK message, instead (either after the 100 Trying, or after a 183 Session Progress on occasion) you will receive a message with an error code and a human readable message.

Some common rejections are shown below, but the all have some things in common.

Usually, we will also send a Reason and/or X-Reason header in the response, these provide more detailed information on why your call failed.

Where present the Reason header will include a numeric Cause Code, this is the "ISDN Cause Code" which indicates the remote cause code received from the remote network e.g.

SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 178.22.139.77;branch=z9hG4bK6bf7.93a853cfad6222579dab5d443aa44baf.0;rport=42372
Via: SIP/2.0/UDP 178.22.139.78:5060;branch=z9hG4bK0d8345c3
Max-Forwards: 69
From: "Anonymous" <sip:Anonymous@178.22.139.77>;tag=as28effd24
To: <sip:443301223043@example.domain.com:5060>;tag=DKeF79X92U5Qg
Call-ID: 1899043948a29d49228911e632970b23@178.22.139.77:5060
CSeq: 102 INVITE
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=1;text="UNALLOCATED_NUMBER"
Content-Length: 0
X-sw-nocontinue: true
P-Asserted-Identity: "443301223043" <sip:443301223043@example.domain.com>

The X-Reason header is used more for Simwood-specific messages, such as triggering a fraud prevention measure, or account balance being insufficient for the call.

SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP 178.22.139.77;branch=z9hG4bK0104.d79755492bcc0e8d09f8c9c413ca17a4.0;rport=40560
Via: SIP/2.0/UDP 178.22.139.78:5060;branch=z9hG4bK1sansay1959765875rdb2197
Max-Forwards: 67
From: "Anonymous" <sip:Anonymous@178.22.139.77>;tag=sansay1959765875rdb2197
To: <sip:+443301223043@example.domain.com:>;tag=QDX7H4a59t1yH
Call-ID: 372154961-0-DNS0-955440532@178.22.139.78
CSeq: 1 INVITE
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=52;text="OUTGOING_CALL_BARRED"
Content-Length: 0
X-sw-nocontinue: true
X-Warning: CLI Should be in E164 Format
X-Reason: Account out of credit
Remote-Party-ID: "+443301223043" <sip:+443301223043@example.domain.com>;party=calling;privacy=off;screen=no

Common Responses

When a call fails you'll receive a response code in the form 4xx, 5xx or 6xx. These are similar to HTTP codes (e.g. 404 in HTTP is "Page Not Found", in SIP it's "Not Found" or "Unrecognised Number")

A typical failed call looks like this

SIP/2.0 404 Not Found
Via: SIP/2.0/TCP 178.22.139.77;branch=z9hG4bK6bf7.93a853cfad6222579dab5d443aa44baf.0;rport=42372
Via: SIP/2.0/UDP 178.22.139.78:5060;branch=z9hG4bK0d8345c3
Max-Forwards: 69
From: "Anonymous" <sip:Anonymous@178.22.139.77>;tag=as28effd24
To: <sip:443301223043@example.domain.com:5060>;tag=DKeF79X92U5Qg
Call-ID: 1899043948a29d49228911e632970b23@178.22.139.77:5060
CSeq: 102 INVITE
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=1;text="UNALLOCATED_NUMBER"
Content-Length: 0
X-sw-nocontinue: true
P-Asserted-Identity: "443301223043" <sip:443301223043@example.domain.com>

In this example, the number dialled was not recognised.

As a guide, 4xx errors are specific to either the request (e.g. Bad Request) or the destination (Busy, Not Found etc) whereas 5xx errors are specific to the network (either our own, or further upstream). 6xx errors are to be considered "permanent" and shouldn't be retried.

Some of the most common (and some uncommon) codes are below

400 Bad Request
401 Unauthorised
402 Payment Required
403 Forbidden
404 Not Found
406 Not Acceptable
407 Proxy Auth Required
408 Timeout
410 Gone
433 Anonymity Disallowed
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
484 Address Incomplete
486 Busy Here
488 Not Acceptable Here

500 Server Internal Error
502 Bad Gateway
503 Service Unavailable

600 Busy Everywhere
603 Decline

 

Related articles

Comments

0 comments

Article is closed for comments.