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.
Max-Forwards: 70
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:aprokop@10.101.6.120>;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.
Contact: sip:aprokop@10.101.6.120;transport=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 |
| Accept-Contact | a |
| Allow-Events | u |
| Call-ID | i |
| Contact | m |
| Content-Encoding | e |
| Content-Length | l |
| Content-Type | c |
| Event | o |
| From | f |
| Referred-By | b |
| Refer-to | r |
| Subject | s |
| Supported | k |
| To | t |
| Via | v |
Using my previous Contact header example:
m: sip:aprokop@10.101.6.120;transport=udp
is the same as
Contact: sip:aprokop@10.101.6.120;transport=udp
Enough Said
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.
Tao, Zen, and Tomorrow 
Hi Andrew – for those who like their headers even smaller the 3GPP/IETF have also added (for IMS use primarily, although open to other uses) SIP header compression (http://tools.ietf.org/html/rfc3320). I guess SigComp might also come in handy if you have a Path MTU that is small too. I’ve certainly had problems with PMTU and very large SIP messages having to be fragmented.
Neill.
Thank you, Neill. I learned even more about headers. I have been out of IMS for several years and have yet to see that flow down to Enterprise SIP. I’ll take a look at your link to see how it works.
Hello Andrew,
Request you to please clarify on below mentioned scenario regarding Contact header.
A-> INV-> B
A<- 200 OK(with contact header) ACK-> B( ACK sent to address present in contact header)
Here for the first INV sent to B, B responded with an address in 200 ok for Contact header.
Now, A sends a REINV to B.
A-> RE-INV->B
A-< 200 ok(no contact header) <-B
Now, A has not received contact header from B for REINV.
So, will A use contact header sent by B for initial INV for sending ACK for REINV.
My understanding is that , contact header value is used for all future requests. Hence in this case, even if B has not sent contact header for REINVITE, A will use the value received in initial INVITE and send ACK to it.
I expect that using the previous Contact header for that session is the correct behavior. Are you seeing this happen or just wondering about it?
Hello Andrew,
Thanks for your response.
This is happening (as per your expectation). Contact header value of initial INVITE’s 200 OK is getting used if there is no contact header present in 200 OK for REINVITE.
Regards,
Ravi Prakash
Hi Andrew, how is the Call-ID field generated? Is it left up to the discretion of the provider? The Call-ID we have is @ Is this a standard or just a convention that we use?
It’s left up to the sender, but the common practice is GUID@IP-Address.
Hi Andrew,
what is different between SIP error code – 406,606,488,415.