- Session Initiation Protocol Tutorial
- SIP - Home
- SIP - Introduction
- SIP - Network Elements
- SIP - Basic Call Flow
- SIP - Messaging
- SIP - Response Codes
- SIP - Headers
- SIP - Session Description Protocol
- SIP - The Offer/Answer Model
- SIP - Mobility
- SIP - Forking
- SIP - Proxies & Routing
- SIP to PSTN
- SIP - Codecs
- SIP - B2BUA
- SIP Useful Resources
- SIP - Quick Guide
- SIP - Useful Resources
- SIP - Discussion
SIP - Request Only Header Fields
Authorization
The Authorization header field is used to carry the credentials of a UA in a request to a server.
It can be sent in reply to a 401 Unauthorized response containing challenge information.
Event
This header field is used in a SUBSCRIBE or NOTIFY method to indicate which event package is being used by the method.
In a SUBSCRIBE, it lists the event package to which the client would like to subscribe.
In a NOTIFY, it lists the event package that the notification contains state information about.
Join
The Join header field is used in an INVITE to request that the dialog (session) be joined with an existing dialog (session).
The parameters of the Join header field identify a dialog by the Call-ID, To tag, and From tag in a similar way to the Replaces header field.
If the Join header field references a point-to-point dialog between two user agents, the Join header field is effectively a request to turn the call into a conference call.
If the dialog is already part of a conference, the Join header field is a request to be added into the conference.
Proxy-Authorization
The Proxy-Authorization header field is to carry the credentials of a UA in a request to a server.
It can be sent in reply to a 407 Proxy Authentication Required response containing challenge information.
A proxy receiving a request containing a Proxy-Authorization header field searches for its own realm, and if found it processes the entry.
If the credentials are correct, any remaining entries are kept in the request when it is forwarded to the next proxy.
Proxy-Require
The Proxy-Require header field is used to list features and extensions that a UA requires a proxy to support in order to process the request.
A 420 Bad Extension response is returned by the proxy listing any unsupported feature in an Unsupported header field.
If the support of this option is desired but not required, it is listed in a Supported header field instead.
Max-Forwards
The Max-Forwards header field is used to indicate the maximum number of hops that a SIP request may take.
The value of the header field is decremented by each proxy that forwards the request.
A proxy receiving the header field with a value of zero discards the message and sends a 483 Too Many Hops response back to the originator.
Max-Forwards is a mandatory header field in requests as per RFC 3261.
The recommended value is 70 hops.
Priority
The Priority header field is used by a UAC to set the urgency of a request. Values are non-urgent, normal, urgent, and emergency.
Refer-To
The Refer-To header field is a mandatory header field in a REFER request, which contains the URI or URL resource that is being referenced. It may contain any type of URI from a sip or sips to a telURI.
Referred-By
The Referred-By header field is an optional header field in a REFER request and a request triggered by a REFER.
It provides the recipient of a triggered request with information that the request was generated as a result of a REFER and the originator of the REFER.
An unsigned Referred-By header field may be rejected with 429 Provide Referror Identity response code.
Replaces
Replaces is used for replacing an existing call with a new call.
A UA in an established dialog receiving another INVITE with a Replaces header field that matches the existing dialog must accept the INVITE, terminate the existing dialog with a BYE, and transfer all resources and state from the existing dialog to the newly established dialog.
If the Replaces header field matches no dialog, the INVITE must be rejected with a 481 Dialog Does Not Exist response.
Request-Disposition
The Request-Disposition header field can be used to request servers to either proxy, redirect.
Example: Request-Disposition: redirect
Require
The Require header field is used to list features and extensions that a UAC requires a UAS to support in order to process the request.
A 420 Bad Extension response is returned by the UAS listing any unsupported features in an Unsupported header field.
Example: Require: rel100
Route
The Route header field is used to provide routing information for requests.
RFC 3261 introduces two types of routing: strict routing and loose routing, which have similar meaning as the IP routing modes of the same name.
In strict routing, a proxy must use the first URI in the Route header field to rewrite the Request-URI, which is then forwarded.
In loose routing, a proxy does not rewrite the Request-URI, but either forwards the request to the first URI in the Route header field or to another loose routing element.
In loose routing, the request must route through every server in the Route list before it may be routed based on the Request-URI.
In strict routing, the request must only route through the set of servers in the Route header field with the Request-URI being rewritten at each hop.
A proxy or UAC can tell if the next element in the route set supports loose routing by the presence of an lr parameter.
Example: Route: sip:proxy@example.com;lr
RAck
The RAck header field is used within a response to a PRACK request to reliably acknowledge a provisional response that contained an RSeq header field.
Its value is combination of CSeq and the RSeq from the provisional response.
The reliable sequence number is incremented for each response sent reliably.
Example: RAck: 3452337 17 INVITE
Session-Expires
The Session-Expires header field is used to specify the expiration time of the session.
To extend a session, either UA can send a re-INVITE or UPDATE with a new Session-Expires header field.
It will come into picture once call has been established.
SIP-If-Match
The SIP-If-Match header field is part of the SIP publication mechanism. It is included in a PUBLISH request meant to refresh, modify, or remove previously published state.
The header field contains the entity tag of the state information that was returned in a SIP-ETag header field in a 2xx response to an earlier PUBLISH.
If the entity-tag is no longer valid, the server will return a 412 Conditional Request Failed response.
Example: SIP-If-Match: 56jforRr1pd
Subscription-State
The Subscription-State header field is a required header field in a NOTIFY request. It indicates the current state of a subscription. Values defined include active, pending, or terminated.
Example: Subscription-State: terminated; reason = rejected