Whenever I get down and dirty with SIP, I can’t help but write about one or more of its various headers. In fact, in a recent article, Understanding SIP Registration, I must have mentioned at least six different headers. While I expect that most discussions involving headers are self-explanatory, there are some aspects that deserve a deeper dive. For example, did you know that there are some headers that can only appear in request messages? Did you know that some headers are known by two names?
For the next page or so, allow me to clue you in on some of the lesser knows aspects of SIP headers.
First, you need to know that headers fall into four different classifications. They are:
General Header Fields. These headers apply to both request and response messages. Examples include Call-ID, To, From, Via, and CSeq.
Entity Header Fields. Entity headers apply only to the message body of a SIP request or response. These include Content-Length, Content-Type, Content-Encoding, Content-Language, and Content-Disposition. Content-Length must carry a non-zero value before the other entity headers will appear in a SIP message.
Request Header Fields. As the name implies, these headers only appear in a request message. They act as request modifiers and allow the client to pass additional information about the request and about the client itself to the server. Examples include Require, Subject, Authorization, and Priority.
Response Header Fields. The opposite of request header fields, these headers only appear in a response message. Examples include WWW-Authenticate, Unsupported, and Warning.
A header consists of a header name followed by a colon and one or more header-values. Multiple header-values are separated by commas.
For instance, Max-Forwards is a very simple header and always contains a single header-value.
A header such as WWW-Authenticate can be very involved with quite a few header-values. Notice how each header-value is separated by a comma.
WWW-Authenticate: Digest realm=”avaya.com”, qop=”auth”, nonce=”ea9c8e88df84f1cec4341ae6cbe5a359″, opaque=””, stale=FALSE, algorithm=MD5
Header-values can be modified. A modification is specified by a semi-colon after the header-value.
The To and From headers are good examples of headers with header-value modifications. For example, the following From header contains the sender’s information modified with a From-Tag.
From: “Andrew Prokop” <sip:firstname.lastname@example.org>;tag=35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
The Contact header is also commonly modified. Here, the user is aprokop and the modifier specifies that he will be sending SIP via UDP.
Keep it Simple, Stupid
Headers can be a bit wordy and other than making SIP messages easier to read, there is no good reason for them to be so long. To help shrink the size of a packet, SIP allows some headers to use a compact format. This takes an otherwise long header name and condenses it into a single character.
Only a few headers come in both a long and compact format. Why? I have no idea. Perhaps one day someone will define compact formats for every header, but until now, these are all I have been able to identify.
|Long Format||Compact Format|
Using my previous Contact header example:
is the same as
That’s it. Everything you wanted to know about SIP headers, but were afraid to ask. I hope you found it helpful. Even I learned a little something while doing the research for this article and that’s always a good thing.