Call-ID

The Call-ID general-header field uniquely identifies a specific invitation or all registrations of a specific client. Note that a single multimedia conference can give rise to several calls with different Call-IDs. For example, if a user invites a single individual several times to the same (long-running) conference.

Contact

The Contact general-header field can appear in INVITE, ACK, and REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In general, it provides a URL where the user can be reached for further communications.

Content-Length

The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.

Content-Type

The Content-Type entity-header field indicates the media type of the message-body sent to the recipient.

Cseq

Users MUST add the CSeq (command sequence) general-header field to every request. A CSeq header field in a request contains the request method and a single decimal sequence number chosen by the requesting client, unique within a single value of Call-ID. The sequence number MUST be expressed as a 32-bit unsigned integer. The initial value of the sequence number is arbitrary, but MUST be less than 2**31. Consecutive requests that differ in request method, headers, or body, but have the same Call-ID MUST contain strictly monotonically increasing and contiguous sequence numbers; sequence numbers do not wrap around. Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a "re-invitation") acquires a new, higher sequence number. A server MUST echo the CSeq value from the request in its response. If the Method value is missing in the received CSeq header field, the server fills it in appropriately.

Date

Date is a general-header field. Its syntax is:

SIP-date = rfc1123-date

Note that unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [29] formatting for dates.

Diversion

Expires

The Expires entity-header field gives the date and time after which the message content expires.

This header field is currently defined only for the REGISTER and INVITE methods. For REGISTER, it is a request and response-header field. In a REGISTER request, the client indicates how long it wants the registration to be valid. In the response, the server indicates the earliest expiration time of all registrations. The server MAYchoose a shorter time interval than that requested by the client, but SHOULD NOT choose a longer one.

From

Requests and responses MUST contain a From general-header field, indicating the initiator of the request. The From field MAY contain the "tag" parameter. The server copies the From header field from the request to the response. The optional "display-name" is meant to be rendered by a human-user interface. A system SHOULD use the display name "Anonymous" if the identity of the client is to remain hidden.

The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers"elements. A server that receives a SIP-URL with these elements removes them before further processing.

Max-Forwards

The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid chain.

The Max-Forwards value is a decimal integer indicating the remaining number of times this request message is allowed to be forwarded.

Each proxy or gateway recipient of a request containing a Max-Forwards header field MUST check and update its value before forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request. Instead, for the OPTIONS and REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (too many hops).

If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).

Require

The Require request-header field is used by clients to tell useragent servers about options that the client expects the server to support in order to properly process the request. If a server does not understand the option, it MUST respond by returning status code 420 (bad extension) and list those options it does not understand in the Unsupported header.

Server

The Server response-header field contains information about the software used by the user agent server to handle the request.

Timestamp

The timestamp general-header field describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and it MAY use any time scale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that have elapsed since receiving the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the time out value for retransmissions.

To

The To general-header field specifies recipient of the request, with the same SIP URL syntax as the From field.

Requests and responses MUST contain a To general-header field, indicating the desired recipient of the request. The optional "display-name"is meant to be rendered by a human-user interface. The UAS or redirect server copies the To header field into its response, and MUST add a "tag" parameter if the request contained more than one Via header field.

User-Agent

The User-Agent general-header field contains information about the client user agent originating the request.

Via

The Via field indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unusual routing situations.