A revisit on SIP

Month's ago I had put a post up on the basics of SIP and said that I was later going to get a little more in detail on the protocol. That post was mainly a very high level view with the core components. Now what I would like to do is take it one step further and start explaining some of the headers and how to read the SIP messages correctly.

I think one of the biggest issues with SIP is the pure amount of messages that are sent for every transaction.  Every time you setup a call you get an INVITE, every time you go on hold, INVITES are sent with certain SDP characteristics announcing a hold status so the call doesn't get torn down.  Every time something registers you get a REGISTER message.  Basically, everything is recorded down on what is going on.

Below is a basic SIP header from an INVITE, we will go over each header field that is relevant and annotate which ones are mandatory.  The thing is with SIP, you are required to have certain SIP headers regardless of what is going on.  While others may be optional, headers like To:, From:, Via:, Call-ID:, etc. are all necessary components to the SIP protocol.

INVITE sip:3212@10.0.0.153:5060;user=phone SIP/2.0

Via: SIP/2.0/UDP 10.0.0.4:5060;branch=z9hG4bKs3uc2t20dgj04lkn51s1.1

From: <sip:2226541300@10.0.1.3:51088;user=phone>;tag=127.0.0.1+1+a5380157+652ceee3

To: <sip:3212@97.208.31.204:5060;user=phone>

CSeq: 818076443 INVITE

Expires: 180

Min-SE: 3600

Session-Expires: 3600

Supported: replaces, timer

Content-Length: 313

Request-Disposition: fork, sequential

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

Call-ID: 9AB0E358-1FFEC2pzsxRAnf9OsjW3of1wROpUYiBxisHiIwiB6zBrtY79UsAJ92FonzIYhJx1BEJKAr

P-Asserted-Identity: <sip:2226541300@10.0.1.3;user=phone>

Privacy: none

Max-Forwards: 66

Contact: <sip:2226541300@10.0.1.3;user=phone>

Content-Type: application/sdp

User-Agent: Alcatel-Lucent 5020 MGC-8 8.1.0.11.SP1.1

v=0

o=root 2085757204 2085757204 IN IP4 10.0.0.4

s=session

c=IN IP4 10.0.0.4

t=0 0

m=audio 34732 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

a=sendrecv

So with the above, I highlighted a few lines that I will go over.  First and foremost this is a INVITE meaning an endpoint is sending a request.  I am capitalizing this information because all requests are always CAPITALIZED, and will always get a response back, regardless if it is a success or failure.  The six requests that you can get in SIP are INVITE, CANCEL, BYE, REGISTER, ACK, and OPTIONS.  Responses would be something like a 200 ok, ringing, trying, etc.  These are always in response to a SIP REQUEST.  Now, yes I know there are others like a PRACK and SUBSCRIBE but those are not the six main requests/methods.  Again, everything starting in CAPITAL letters is a request and anything starting with a number is a response such as a 180 ringing.  See below for a response to a SIP request.  Please note this one does not coincide with the SIP message I posted above.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 182.168.250.49:5060;branch=z9hG4bK786d156c;rport=5060
Contact: <sip:9011@182.168.246.213:35134;rinstance=7af05ded7e7e49e6>
To: <sip:9011@182.168.246.213:35134;rinstance=7af05ded7e7e49e6>;tag=9a00d038
From: "9012"<sip:9012@182.168.250.49>;tag=as66995cd4
Call-ID: 7cebe5d1060b11452571a22e0e2cb919@192.168.250.49
CSeq: 102 INVITE
User-Agent: X-Lite release 1002tx stamp 29712
Content-Length: 0

Now I wish I had a way of generating some SIP traffic right now but I don't have access to a test lab for SIP at the moment since my demo license expired and I'm not in the habit of using a production network for labbing and testing unless absolutely necessary.  Anyways, as you can see, the above message is a response as it starts with a number and generally is not capitalized.  You still see all the same basic headers here only without the SDP.  Please note these are SIP messages I have used from the web and I have changed some of the information intentionally just in case there is a confidentiality issue.

Now a bit more on the OPTIONS request.  This is becoming more and more common as we move forward into a pure IP telephony environment.  Amongst other things, OPTIONS is used heavily for something called an OPTIONS PING which monitors the status of a egress point on a gateway.  If it doesn't respond it can mark it as dead and go out another route.  The great thing about this is, before SIP, this wasn't really possible and you have to wait for timeouts to occur in the H.323 and MGCP world or worse, manually change it over.  The rest of the requests I have already gone over in the other post and can be easily discovered on the web.  At this point, I am assuming you have a high level knowledge of SIP. 

I'd like to go over some of the SDP markers in the first SIP message.  As you can see, it is quite extensive.  The bad part is, with voice, video, and presentations that list will double in size to create even more of an eye sore.  Starting with the "c=" line in the SDP we can see an IP address and that it is IPv4.  This line identifies where media is coming from and where it should be sent to.  This can be a good place to look to make sure that your network is working the way it should be.

Originator or "o=" is an indicator of who is initiating the connection.  This has a username (if applicable), their IP, and who they are.  It is as simple as that.  There are more stipulations as to how the field should be populated and those can be found in RFC 4566 if you want to get into the nitty gritty.

Next is the all important "a=" line which marks what codecs you are going to be advertising and accepting.  PCMA/8000 is G.711a-law and PCMU/8000 is G.711u-law.  In the United States we use u-law inclusively. Another way to remember it is u-law for the U<---nited States.  (Thanks Jeremy Ciaroa for that one!).  Other codecs can also be listed here like G729 as listed above, iLBC, etc.  

You will also see things like "a=sendrcv".  This can be an indication of what is going on with the media.  Is it expecting to send only, receive only, do both, or go inactive completely?  There are four different  attributes in this particular that you will commonly see:

1. a=sendrecv
2. a=sendonly
3. a=recvonly
4. a=inactive

Normally, in a hold situation you will see a a=sendonly followed by a response of a=recvonly.  This is indicative of a stream going on hold.  A new transaction is sent just for the hold feature.  Now, this isn't the only time you will see these tags but the most common in a phone environment is hold/resume.  so why is one send only and the other receive only?  Well the user placing someone on hold is presumed to be send only because they are going to be streaming music on hold from CUCM or something of the sort while the distant end will only be receiving and not sending and voice packets back.  You should only see your RX on your Cisco phone bumping substantially during this time.  The other possiblity during a hold session is a=inactive.  This indicates nothing is being sent or received and basically dead air is all that remains.  SIP has to maintain the connection somehow, so you will continue to see SIP INVITES and 200 ok messages with a=inactive until the session is resumed.  How else would you maintain that call?

Well, looking at everything above I think I will cut this post here.  I will continue on with more headers and SDP lines in a future post.  I don't want to risk someone falling asleep on me now since it is imperative you understand SIP as the replacement technology for H.323...if we were get there in our lifetime.  It seems like PRIs are still everywhere while SIP is being slowly implemented in more and more places.