SIP - Request & Response Header Fields

Accept

The Accept header field is used to indicate acceptable message Internet media types in the message body.

  • The header field describes media types using the format type/sub-type commonly used in the Internet.

  • If not present, the assumed acceptable message body format is application/sdp.

  • A list of media types can have preferences set using q value parameters.

Accept-Encoding

The Accept-Encoding header field is used to specify acceptable message body encoding schemes.

  • Encoding can be used to ensure a SIP message with a large message body fits inside a single UDP datagram.

  • The use of q value parameters can set preferences. If none of the listed schemes are acceptable to the UAC, a 406 Not Acceptable response is returned. If not included, the assumed encoding will be text/plain.

To

To indicates the final recipient of the request. Any response generated by a UA will contain this header field with the addition of a tag. It is a mandatory header.

  • Any response generated by a proxy must have a tag added to the To header field.

  • The To header field URI is never used for routing.

From

From header field indicates the originator of the request. It is one of two addresses used to identify a dialog.

  • A From header field may contain a tag used to identify a particular call.

  • It may contain a display name, in which case the URI is enclosed in <>.

  • It is a mandatory header.

Call-ID

The Call-ID header field is mandatory in all SIP requests and responses. It is used to uniquely identify a call between two user agents.

  • A Call-ID must be unique across calls.

  • All registrations for a user agent should use the same Call-ID.

  • A Call-ID is always created by a user agent and is never modified by a server.

  • It is a cryptographically random identifier.

Via

Via is used to record the SIP route taken by a request which helps to route a response back to the originator.

  • A UA generating a request records its own address in a Via header field.

  • A proxy forwarding the request adds a Via header field containing its own address to the top of the list of Via header fields.

  • A proxy or UA generating a response to a request copies all the Via header fields from the request in order into the response, then sends the response to the address specified in the top Via header field.

  • A proxy receiving a response checks the top Via header field and matches its own address.

  • If it does not match, the response has been discarded.

  • The top Via header field is then removed, and the response forwarded to the address specified in the next Via header field.

  • Via header fields contain protocol name, version number, and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc.) and may contain port numbers and parameters such as received, rport, branch, maddr, and ttl.

  • A received tag is added to a Via header field if a UA or proxy receives the request from a different address than that specified in the top Via header field.

  • A branch parameter is added to Via header fields by UAs and proxies, which is computed as a hash function of the Request-URI, and the To, From, Call-ID, and CSeq number.

CSeq

The CSeq header field is a required header field in every request. It contains a decimal number that increases for each request.

  • Usually, it increases by 1 for each new request, with the exception of CANCEL and ACK requests, which use the CSeq number of the INVITE request to which it refers.

  • The CSeq count is used by UASs to determine out-of-sequence requests or to differentiate between a new request (different CSeq) or a retransmission (same CSeq).

  • The CSeq header field is used by UACs to match a response to the request it references.

  • For example, a UAC that sends an INVITE request then a CANCEL request can tell by the method in the CSeq of a 200 OK response if it is a response to the invitation or cancellation request.

Contact

The Contact header field is used to convey the other user about the address of the request originator. Once a Contact header field has been received, the URI can be cached and used for routing future requests within a dialog.

For example, a Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message and all future requests during this call to bypass proxies and go directly to the called party.

Record-Route

The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session (dialog) between two UAs.

Normally, the presence of a Contact header field allows UAs to send messages directly bypassing the proxy chain used in the initial request.

  • A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included.

  • A proxy wishing to implement this inserts the header field containing its own URI, or adds its URI to an already present Record-Route header field.

  • The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request.

  • The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests.

Organization

The Organization header field is used to indicate the organization to which the originator of the message belongs.

  • It can also be inserted by proxies as a message is passed from one organization to another.

  • Like all SIP header fields, it can be used by proxies for making routing decisions and by UAs for making call screening decisions.

Retry-After

It is used to indicate when a resource or service may be available again.

  • In 503 Service Unavailable responses, it indicates when the server will be available.

  • In 404 Not Found, 600 Busy Everywhere, and 603 Decline responses, it indicates when the called UA may be available again.

  • It contains time period in ‘sec’.

Subject

The optional Subject header field is used to indicate the subject of the media session.

The contents of the header field can also be displayed during alerting to aid the user in deciding whether to accept the call.

Example:
Subject: How are you?

Supported

The Supported header field is used to list one or more options implemented bya UA or server.

  • It is typically included in responses to OPTIONS requests.

  • If no options are implemented, the header field is not included.

  • If a UAC lists an option in a Supported header field, proxies or UASs may use the option during the call.

  • If the option must be used or supported, the Require header field is used instead.

Example:
Supported: rel100

Expires

The Expires header field is used to indicate the time interval in which the request or message contents are valid.

  • When present in an INVITE request, the header field sets a time limit on the completion of the INVITE request.

  • That is, the UAC must receive a final response (non-1xx) within the time period or the INVITE request is automatically cancelled with a 408 Request Timeout response.

  • Once the session is established, the value from the Expires header field in the original INVITE has no effect—the Session-Expires header field must be used for this purpose.

  • If present in a REGISTER request, the header field sets the time limit on the URIs in Contact header fields that do not contain an expires parameter.

  • Expires is also used in SUBSCRIBE requests to indicate the subscription duration.

Example:
Expires: 30

User-Agent

This header field is used to convey information about the UA originating the request.

session_initiation_protocol_headers.htm
Advertisements