SIP Request Header explained

SIP Request header explained for UAC behavior outside of a dialog.

Valid SIP request formulated by UAC must contain following seven header fields:

Mandatory Request Line: method, Request-URI and SIP version

To

From

Call-ID

CSeq

Max-Forwards

Via

Those headers are the fundamental building blocks of SIP message and are jointly used to provide Critical Message Routing Services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages and unique id of transactions.


Let's look at SIP NOTIFY message
=================
Server sending the NOTIFY message to IP phone ( Extension 57644)

NOTIFY sip:57644@192.168.2.10 SIP/2.0
Via: SIP/2.0/UDP sipserver.phone:5060;branch=z9hG4bK490bfd1d
Max-Forwards: 70
From: "pbx" <sip:pbx@sipserver.phone&gt;;tag=as5bea1e93
To: <sip:57644@192.168.2.10>
Contact: <sip:pbx@sipserver.phone:5060>
Call-ID: 154a4e1246b2d33f7257e1c965625efa@sipserver.phone:5060
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX 1.8.7.1
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 93

Messages-Waiting: no
Message-Account: sip:pbx@sipserver.phone:5060
Voice-Message: 0/2 (0/0)

---

IP Phone responding to the server by sending 200 OK

<--- SIP read from UDP:192.168.2.10:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP sipserver.phone:5060;branch=z9hG4bK490bfd1d
From: "pbx" <sip:pbx@sipserver.phone>;tag=as5bea1e93
To: "57644" <sip:57644@192.168.2.10>;tag=886BDB1C-E1C3AFC1
CSeq: 102 NOTIFY
Call-ID: 154a4e1246b2d33f7257e1c965625efa@sipserver.phone:5060
Contact: <sip:57644@192.168.2.10>
Event: message-summary
User-Agent: PolycomSoundPointIP-SPIP_331-UA/3.3.2.0413
Accept-Language: en
Content-Length: 0
=====================

Request-URI should be set to the value of URI in TO field [ Except Request-URI of REGISTER]

To: Specifies the desired 'logical' recipient of the request or 'address-of-record' of the target. This may or may not be the ultimate recipient of the request. To header field allows for a display name. Request outside of a dialog shouldn't contain To tag;

Example:
To: <sip:57644@192.168.2.10>

From: indicates the logical identity of the initiator of the request. This field is used by SIP elements to determine which processing rules to apply to a request. From field must contain a new 'tag' parameter, chosen by UAC.

Example:
From: "pbx" <sip:pbx@sipserver.phone>;tag=as5bea1e93



Call-ID: acts as a unique identifier to group together a series of messages. It must be the same for all requests and responses sent by either UA in a dialog.

Example:
Call-ID: 154a4e1246b2d33f7257e1c965625efa@sipserver.phone:5060


CSeq: serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request.

Example:
CSeq: 102 NOTIFY



Max-Forwards: It serves to limit the number of hops a request can transit on the way to its destination. UAC must insert a Max-Forwards header field in each request it originates with a value that SHOULD be 70.

Via: It indicates the transport used for the transaction and identifies the location where the response is to be sent.

Via: SIP/2.0/UDP sipserver.phone:5060;branch=z9hG4bK490bfd1d


When UAC creates a request, it must insert a Via header into that request. Via header must contain a branch parameter. Branch parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server. Branch ID should always start with "z9hG4bk".


Contact: It provides a SIP URI at which the UA would like to receive requests.


Contact: <sip:57644@192.168.2.10>


Why 'tag' is introduced as mandatory in RFC 3261?

'tag' parameter is used in "To" and "From" header fields of SIP messages. Two 'tags' (one from each participant) along with Call-ID serves as a general mechanism to identify a dialog.

When UA sends a request outside of a dialog, it contains a From tag only, providing 'half' of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field.

The forking of SIP requests means that multiple dialogs can be established form a single request. This also explains the need for the two-sided dialog identifier.

'tag' must be globally unique 32 bits random string generated by UA. This uniqueness results different tag in To and From header of an INVITE request. This is essential for an UA to invite itself to a session Example: Hairpinning of calls in PSTN gateways.

Tags are useful for fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. UAS can select the tag in such a way that backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it.



References:
http://rfc-ref.org/RFC-TEXTS/3261/chapter8.html