Understanding SIP Message Bodies

I was born and raised in Arizona, but for many years I’ve called Minnesota home. Yes, I understand that most people make the opposite move, but I truly love it here and no one is twisting my arm to stay. Okay, the first few winters were brutal, but I’ve even grown to appreciate/tolerate those.

Minnesota is known as the land of ten thousand lakes, but I’ve heard that it’s actually closer to twelve thousand. It wouldn’t surprise me if the number was even higher. Even here in the Twin Cities, you don’t have to drive very far to find a sizable lake. Coming from hot and dry Arizona, it was a shock to live around so much liquid.

Besides all these bodies of water, Minnesota is birthplace of our former governor, Jesse “the Body” Ventura. Politics aside, he was an extremely colorful character that raised the visibility of the state far more than nearly all the previous governors combined.

So, what does this have to do with SIP? Why, SIP message bodies, of course. On its own, SIP can establish sessions between two or more entities, but it’s those message bodies that make SIP more than an academic toy.

You may have heard it said that SIP is media agnostic. This means that SIP can establish a media connection of any type. Everyone is familiar with voice, video, and instant message. I once worked on a piece of software that used SIP to play chess across an IP network. The media consisted of the chess moves. I also wrote a SIP application that sent the contents of a clipboard from one PC to another.

There are no limits to the kinds of data connections SIP can facilitate.

There are two things that make SIP media independent. First, there is the SIP message body. Contained with the message body is a description of the media used by the session. For example, Session Description Protocol (SDP) is used for voice and video transmissions. XML is often used for instant message. My chess and clipboard programs used a homegrown descriptor that looked very similar to SDP.

For more information on SDP, please refer to my article, Understanding Session Description Protocol (SDP).

Second, SIP supports several headers that are used to define and describe the message body. Specifically, they are:

Content-Type: Content-Type indicates the media type of the message body sent to the recipient. Examples include application/SDP and text/html.

Content-Length: Content-Length indicates the size of the message body in octets (8-bit bytes). SIP messages that do not contain a message body will set Content-Length to 0 (zero).

Content-Language. Content-Language defines the language of the message body. For instance, a value of “fr” indicates that the message body is in French.

Content-Encoding. When present, Content-Encoding indicates what additional encodings have been applied to the message body and thus what decoding mechanism must be applied in order to read it. For example, qzip or tar are valid values for a compressed message body.

Content-Disposition. Content-Disposition describes how the message body or message body type (see discussion of multipart MIME below) is to be interpreted.

Of these headers, Content-Length will appear in every SIP message. As I mentioned earlier, a value of 0 indicates that there is no message body. However, if there is a message body, you will always see Content-Type. Content-Language isn’t required and defaults to English if the header isn’t present. Content-Encoding only appears if the message body has been encoded.

I will be honest and say that I rarely see Content-Disposition used in practice and when I have, it has always been set to “session.” Values such as “inline” and “render” are available, but I have yet to see those used in any of my SIP dealings.

What follows is SIP message with its message body. Note that Content-Encoding does not appear. This means that we can read the message body without having to first decode it.

PUBLISH sip:bob@mycompany.com SIP/2.0

Via: SIP/2.0/UDP 10.10.21.11;branch=z9hG4bK652hsge

To: <sip:bob@mycompany.com>

From: <sip:bob@mycompany.com>;tag=1234wxyz

Call-ID: 81818181@10.10.21.11

CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: 120

<?xml version=”1.0″ encoding=”UTF-8″?>

<presence xmlns=”urn:ietf:params:xml:ns:pidf”

entity=”pres:presentity@example.com”>

<tuple id=”efeef223″>

<status>

<basic>closed</basic>

</status>

<timestamp>2003-02-01T17:00:19Z</timestamp>

</tuple>

</presence>

Note that there is a single blank line between the end of the SIP message and the start of the message body. This is required by SIP. Also note that Content-Length counts the number of bytes after the blank line.

The last thing I want to discuss is multipart MIME. I previously mentioned multipart MIME (MM) in my article, Call Recording With SIPREC. Simply put, MM is used when a message body is divided into more than one part. In the case of call recording, one part would be SDP and the other SIPREC extensions. These two parts are processed independently and aren’t required to be related in any manner.

I’ve also seen MM used by Nortel CS1000 systems. The first part of an INVITE was SDP and the second consisted of Nortel proprietary values that would be ignored by non-Nortel SIP systems.

There is one more content header that comes into play with MM. Content-ID is used to “point” to a particular part. Content-ID allows one body to make reference to another. For more information, please find RFC 2045.

Speaking of RFCs, if you require more information on multipart MIME, I suggest you read RFC 5621, Message Body Handing in the Session Initiation Protocol. You will learn far more there than I could ever dream to teach you.

Well, there you have it. Everything you wanted to know about SIP message bodies, but were afraid to ask. Remember, message bodies are what makes SIP media independent and a protocol useful for everything from telephone calls to chess games.