SIP Learning Part III - Essential headers continued

C-Seq Header 

this header is used to identify the order of transactions. It consits a sequence number and a method. The method must match that of the request. For non-REGISTER requests outside of a dialog, the sequence number is arbitrary. The sequence number MUST be expressible as 32 bit unsigned integer and MUST be less than 2**31. 

for e.g. CSeq : 4711 INVITE 

Max - Forwards 

This header limits the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-forwards value reaches 0 before the request races its destination, it will be rejected with a 483 (too many hops) error response. 

When UAC constructs a request, Max-Forwards header is set as 70, which is chosen value sufficient enough to safely reach the destination on a network without any loops. Lower values should be used with caution and only in networks where topologies are known by the UA. 

Via header 

The Via header filed indicates the transport used for the transaction and identifies the location where the response to be seen. When UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be sip 2.0, respectively. The Via header field must contains a branch parameter. This parameter is used to identify the transaction created by that request. this parameter is used by both client and server. 

The branch parameter must be unique for each of the request client generates except for Cancel and ACK. these request must contain the branch value of the request that it Cancels or ACKs. 

The branchId inserted by an element compliant with this specification MUST always begin with the characters “z9hG4bK” which is known as magic cookie that ensrure the uniqueness of the number. 

Contact 

The Contact header filed provides a SIP or SIPs URI that can be used to contact that specific instance of the UA for subsequent requests. The contact header field must be present and exactly one SIP or SIPS URI in any request that can result in the establishment of a dialoag. 

If the request-URI or the top most Route header field contains a SIPS URI, the n the contact header also should contain a SIPS URI. 

Supported and Require

If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a supported header field in the request listing the option tags for those extensions. The Options tags listed MUST only refer to prevent servers from insisting that clients implement nonstandard vendor - defined features in order to receive service. If the UAC want to insist that any proxies through which the request is traversed should understand the extension, then it can include a Proxy-Require header for this purpose. 

Additional Message Components

After a new request has been created, and the header described as mandatory are properly constructed, any additional optional header fields are added, as are any header fields specific to the method. 

SIP Requests may contain MIME encoded body regardless of the body that a  request contains , certain header fields must be formulated to characterize the contents of the body. 

references:

https://www.ietf.org/rfc/rfc3261.txt