SIP offers a discovery capability. If a user wants to initiate a
session with another user, SIP must discover the current host(s) at
which the destination user is reachable. This discovery process is
frequently accomplished by SIP network elements such as proxy servers
and redirect servers which are responsible for receiving a request,
determining where to send it based on knowledge of the location of
the user, and then sending it there. To do this, SIP network
elements consult an abstract service known as a location service,
which provides address bindings for a particular domain. These
address bindings map an incoming SIP or SIPS URI, sip:firstname.lastname@example.org,
for example, to one or more URIs that are somehow "closer" to the
desired user, sip:email@example.com, for example.
Ultimately, a proxy will consult a location service that maps a
received URI to the user agent(s) at which the desired recipient is
Registration creates bindings in a location service for a particular
domain that associates an address-of-record URI with one or more
contact addresses. Thus, when a proxy for that domain receives a
request whose Request-URI matches the address-of-record, the proxy
will forward the request to the contact addresses registered to that
address-of-record. Generally, it only makes sense to register an
address-of-record at a domain's location service when requests for
that address-of-record would be routed to that domain. In most
cases, this means that the domain of the registration will need to
match the domain in the URI of the address-of-record.
There are many ways by which the contents of the location service can
be established. One way is administratively. In the above example,
Bob is known to be a member of the engineering department through
access to a corporate database. However, SIP provides a mechanism
for a UA to create a binding explicitly. This mechanism is known as
Registration entails sending a REGISTER request to a special type of
UAS known as a registrar. A registrar acts as the front end to the
location service for a domain, reading and writing mappings based on
the contents of REGISTER requests. This location service is then
typically consulted by a proxy server that is responsible for routing
requests for that domain.
An illustration of the overall registration process is given in
Figure 2. Note that the registrar and proxy server are logical roles
that can be played by a single device in a network; for purposes of
clarity the two are separated in this illustration. Also note that
UAs may send requests through a proxy server in order to reach a
registrar if the two are separate elements.
SIP does not mandate a particular mechanism for implementing the
location service. The only requirement is that a registrar for some
domain MUST be able to read and write data to the location service,
and a proxy or a redirect server for that domain MUST be capable of
reading that same data. A registrar MAY be co-located with a
particular SIP proxy server for the same domain.
10.2 Constructing the REGISTER Request
REGISTER requests add, remove, and query bindings. A REGISTER
request can add a new binding between an address-of-record and one or
more contact addresses. Registration on behalf of a particular
address-of-record can be performed by a suitably authorized third
party. A client can also remove previous bindings or query to
determine which bindings are currently in place for an address-of-
Except as noted, the construction of the REGISTER request and the
behavior of clients sending a REGISTER request is identical to the
general UAC behavior described in Section 8.1 and Section 17.1.
A REGISTER request does not establish a dialog. A UAC MAY include a
Route header field in a REGISTER request based on a pre-existing
route set as described in Section 8.1. The Record-Route header field
has no meaning in REGISTER requests or responses, and MUST be ignored
if present. In particular, the UAC MUST NOT create a new route set
based on the presence or absence of a Record-Route header field in
any response to a REGISTER request.
The following header fields, except Contact, MUST be included in a
REGISTER request. A Contact header field MAY be included:
Request-URI: The Request-URI names the domain of the location
service for which the registration is meant (for example,
"sip:chicago.com"). The "userinfo" and "@" components of the
SIP URI MUST NOT be present.
To: The To header field contains the address of record whose
registration is to be created, queried, or modified. The To
header field and the Request-URI field typically differ, as
the former contains a user name. This address-of-record MUST
be a SIP URI or SIPS URI.
From: The From header field contains the address-of-record of the
person responsible for the registration. The value is the
same as the To header field unless the request is a third-
Call-ID: All registrations from a UAC SHOULD use the same Call-ID
header field value for registrations sent to a particular
If the same client were to use different Call-ID values, a
registrar could not detect whether a delayed REGISTER request
might have arrived out of order.
CSeq: The CSeq value guarantees proper ordering of REGISTER
requests. A UA MUST increment the CSeq value by one for each
REGISTER request with the same Call-ID.
Contact: REGISTER requests MAY contain a Contact header field with
zero or more values containing address bindings.
UAs MUST NOT send a new registration (that is, containing new Contact
header field values, as opposed to a retransmission) until they have
received a final response from the registrar for the previous one or
the previous REGISTER request has timed out.
| UA |
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
A 5)Resp |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
Figure 2: REGISTER example
The following Contact header parameters have a special meaning in
action: The "action" parameter from RFC 2543 has been deprecated.
UACs SHOULD NOT use the "action" parameter.
expires: The "expires" parameter indicates how long the UA would
like the binding to be valid. The value is a number
indicating seconds. If this parameter is not provided, the
value of the Expires header field is used instead.
Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or 136 years) as equivalent to 2**32-1.
Malformed values SHOULD be treated as equivalent to 3600.
10.2.1 Adding Bindings
The REGISTER request sent to a registrar includes the contact
address(es) to which SIP requests for the address-of-record should be
forwarded. The address-of-record is included in the To header field
of the REGISTER request.
The Contact header field values of the request typically consist of
SIP or SIPS URIs that identify particular SIP endpoints (for example,
"sip:firstname.lastname@example.org"), but they MAY use any URI scheme.
A SIP UA can choose to register telephone numbers (with the tel URL,
RFC 2806 ) or email addresses (with a mailto URL, RFC 2368 )
as Contacts for an address-of-record, for example.
For example, Carol, with address-of-record "sip:email@example.com",
would register with the SIP registrar of the domain chicago.com. Her
registrations would then be used by a proxy server in the chicago.com
domain to route requests for Carol's address-of-record to her SIP
Once a client has established bindings at a registrar, it MAY send
subsequent registrations containing new bindings or modifications to
existing bindings as necessary. The 2xx response to the REGISTER
request will contain, in a Contact header field, a complete list of
bindings that have been registered for this address-of-record at this
If the address-of-record in the To header field of a REGISTER requestis a SIPS URI, then any Contact header field values in the requestSHOULD also be SIPS URIs. Clients should only register non-SIPS URIsunder a SIPS address-of-record when the security of the resourcerepresented by the contact address is guaranteed by other means.This may be applicable to URIs that invoke protocols other than SIP,or SIP devices secured by protocols other than TLS.
If the Address of Record in the To header field of a REGISTER
request is a SIPS URI, then the UAC MUST also include only SIPS
URIs in any Contact header field value in the requests.
Registrations do not need to update all bindings. Typically, a UA
only updates its own contact addresses.
10.2.1.1 Setting the Expiration Interval of Contact Addresses
When a client sends a REGISTER request, it MAY suggest an expiration
interval that indicates how long the client would like the
registration to be valid. (As described in Section 10.3, the
registrar selects the actual time interval based on its local
There are two ways in which a client can suggest an expiration
interval for a binding: through an Expires header field or an
"expires" Contact header parameter. The latter allows expiration
intervals to be suggested on a per-binding basis when more than one
binding is given in a single REGISTER request, whereas the former
suggests an expiration interval for all Contact header field values
that do not contain the "expires" parameter.
If neither mechanism for expressing a suggested expiration time is
present in a REGISTER, the client is indicating its desire for the
server to choose.
10.2.1.2 Preferences among Contact Addresses
If more than one Contact is sent in a REGISTER request, the
registering UA intends to associate all of the URIs in these Contact
header field values with the address-of-record present in the To
field. This list can be prioritized with the "q" parameter in the
Contact header field. The "q" parameter indicates a relative
preference for the particular Contact header field value compared to
other bindings for this address-of-record. Section 16.6 describes
how a proxy server uses this preference indication.
10.2.2 Removing Bindings
Registrations are soft state and expire unless refreshed, but can
also be explicitly removed. A client can attempt to influence the
expiration interval selected by the registrar as described in Section
10.2.1. A UA requests the immediate removal of a binding by
specifying an expiration interval of "0" for that contact address in
a REGISTER request. UAs SHOULD support this mechanism so that
bindings can be removed before their expiration interval has passed.
The REGISTER-specific Contact header field value of "*" applies to
all registrations, but it MUST NOT be used unless the Expires header
field is present with a value of "0".
Use of the "*" Contact header field value allows a registering UA
to remove all bindings associated with an address-of-record
without knowing their precise values.
10.2.3 Fetching Bindings
A success response to any REGISTER request contains the complete list
of existing bindings, regardless of whether the request contained a
Contact header field. If no Contact header field is present in a
REGISTER request, the list of bindings is left unchanged.
10.2.4 Refreshing Bindings
Each UA is responsible for refreshing the bindings that it has
previously established. A UA SHOULD NOT refresh bindings set up by
The 200 (OK) response from the registrar contains a list of Contact
fields enumerating all current bindings. The UA compares each
contact address to see if it created the contact address, using
comparison rules in Section 19.1.4. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the
Expires field value. The UA then issues a REGISTER request for each
of its bindings before the expiration interval has elapsed. It MAY
combine several updates into one REGISTER request.
A UA SHOULD use the same Call-ID for all registrations during a
single boot cycle. Registration refreshes SHOULD be sent to the same
network address as the original registration, unless redirected.
10.2.5 Setting the Internal Clock
If the response for a REGISTER request contains a Date header field,
the client MAY use this header field to learn the current time in
order to set any internal clocks.
10.2.6 Discovering a Registrar
UAs can use three ways to determine the address to which to send
registrations: by configuration, using the address-of-record, and
multicast. A UA can be configured, in ways beyond the scope of this
specification, with a registrar address. If there is no configured
registrar address, the UA SHOULD use the host part of the address-
of-record as the Request-URI and address the request there, using the
normal SIP server location mechanisms . For example, the UA for
the user "sip:firstname.lastname@example.org" addresses the REGISTER request to
Finally, a UA can be configured to use multicast. Multicast
registrations are addressed to the well-known "all SIP servers"
multicast address "sip.mcast.net" (22.214.171.124 for IPv4). No well-
known IPv6 multicast address has been allocated; such an allocation
will be documented separately when needed. SIP UAs MAY listen to
that address and use it to become aware of the location of other
local users (see ); however, they do not respond to the request.
Multicast registration may be inappropriate in some environments,
for example, if multiple businesses share the same local area
10.2.7 Transmitting a Request
Once the REGISTER method has been constructed, and the destination of
the message identified, UACs follow the procedures described in
Section 8.1.2 to hand off the REGISTER to the transaction layer.
If the transaction layer returns a timeout error because the REGISTER
yielded no response, the UAC SHOULD NOT immediately re-attempt a
registration to the same registrar.
An immediate re-attempt is likely to also timeout. Waiting some
reasonable time interval for the conditions causing the timeout to
be corrected reduces unnecessary load on the network. No specific
interval is mandated.
10.2.8 Error Responses
If a UA receives a 423 (Interval Too Brief) response, it MAY retry
the registration after making the expiration interval of all contact
addresses in the REGISTER request equal to or greater than the
expiration interval within the Min-Expires header field of the 423
(Interval Too Brief) response.
10.3 Processing REGISTER Requests
A registrar is a UAS that responds to REGISTER requests and maintains
a list of bindings that are accessible to proxy servers and redirect
servers within its administrative domain. A registrar handles
requests according to Section 8.2 and Section 17.2, but it accepts
only REGISTER requests. A registrar MUST not generate 6xx responses.
A registrar MAY redirect REGISTER requests as appropriate. One
common usage would be for a registrar listening on a multicast
interface to redirect multicast REGISTER requests to its own unicast
interface with a 302 (Moved Temporarily) response.
Registrars MUST ignore the Record-Route header field if it is
included in a REGISTER request. Registrars MUST NOT include a
Record-Route header field in any response to a REGISTER request.
A registrar might receive a request that traversed a proxy which
treats REGISTER as an unknown request and which added a Record-
Route header field value.
A registrar has to know (for example, through configuration) the set
of domain(s) for which it maintains bindings. REGISTER requests MUST
be processed by a registrar in the order that they are received.
REGISTER requests MUST also be processed atomically, meaning that a
particular REGISTER request is either processed completely or not at
all. Each REGISTER message MUST be processed independently of any
other registration or binding changes.
When receiving a REGISTER request, a registrar follows these steps:
1. The registrar inspects the Request-URI to determine whether it
has access to bindings for the domain identified in the
Request-URI. If not, and if the server also acts as a proxy
server, the server SHOULD forward the request to the addressed
domain, following the general behavior for proxying messages
described in Section 16.
2. To guarantee that the registrar supports any necessary
extensions, the registrar MUST process the Require header field
values as described for UASs in Section 8.2.2.
3. A registrar SHOULD authenticate the UAC. Mechanisms for the
authentication of SIP user agents are described in Section 22.
Registration behavior in no way overrides the generic
authentication framework for SIP. If no authentication
mechanism is available, the registrar MAY take the From address
as the asserted identity of the originator of the request.
4. The registrar SHOULD determine if the authenticated user is
authorized to modify registrations for this address-of-record.
For example, a registrar might consult an authorization
database that maps user names to a list of addresses-of-record
for which that user has authorization to modify bindings. If
the authenticated user is not authorized to modify bindings,
the registrar MUST return a 403 (Forbidden) and skip the
In architectures that support third-party registration, one
entity may be responsible for updating the registrations
associated with multiple addresses-of-record.
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps. The URI
MUST then be converted to a canonical form. To do that, all
URI parameters MUST be removed (including the user-param), and
any escaped characters MUST be converted to their unescaped
form. The result serves as an index into the list of bindings.
6. The registrar checks whether the request contains the Contact
header field. If not, it skips to the last step. If the
Contact header field is present, the registrar checks if there
is one Contact field value that contains the special value "*"
and an Expires field. If the request has additional Contact
fields or an expiration time other than zero, the request is
invalid, and the server MUST return a 400 (Invalid Request) and
skip the remaining steps. If not, the registrar checks whether
the Call-ID agrees with the value stored for each binding. If
not, it MUST remove the binding. If it does agree, it MUST
remove the binding only if the CSeq in the request is higher
than the value stored for that binding. Otherwise, the update
MUST be aborted and the request fails.
7. The registrar now processes each contact address in the Contact
header field in turn. For each address, it determines the
expiration interval as follows:
- If the field value has an "expires" parameter, that value
MUST be taken as the requested expiration.
- If there is no such parameter, but the request has an
Expires header field, that value MUST be taken as the
- If there is neither, a locally-configured default value MUST
be taken as the requested expiration.
The registrar MAY choose an expiration less than the requested
expiration interval. If and only if the requested expiration
interval is greater than zero AND smaller than one hour AND
less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too
Brief). This response MUST contain a Min-Expires header field
that states the minimum expiration interval the registrar is
willing to honor. It then skips the remaining steps.
Allowing the registrar to set the registration interval
protects it against excessively frequent registration refreshes
while limiting the state that it needs to maintain and
decreasing the likelihood of registrations going stale. The
expiration interval of a registration is frequently used in the
creation of services. An example is a follow-me service, where
the user may only be available at a terminal for a brief
period. Therefore, registrars should accept brief
registrations; a request should only be rejected if the
interval is so short that the refreshes would degrade registrar
For each address, the registrar then searches the list of
current bindings using the URI comparison rules. If the
binding does not exist, it is tentatively added. If the
binding does exist, the registrar checks the Call-ID value. If
the Call-ID value in the existing binding differs from the
Call-ID value in the request, the binding MUST be removed if
the expiration time is zero and updated otherwise. If they are
the same, the registrar compares the CSeq value. If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above. If not, the update MUST be
aborted and the request fails.
This algorithm ensures that out-of-order requests from the same
UA are ignored.
Each binding record records the Call-ID and CSeq values from
The binding updates MUST be committed (that is, made visible to
the proxy or redirect server) if and only if all binding
updates and additions succeed. If any one of them fails (for
example, because the back-end database commit failed), the
request MUST fail with a 500 (Server Error) response and all
tentative binding updates MUST be removed.
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.
11 Querying for Capabilities
The SIP method OPTIONS allows a UA to query another UA or a proxy
server as to its capabilities. This allows a client to discover
information about the supported methods, content types, extensions,
codecs, etc. without "ringing" the other party. For example, before
a client inserts a Require header field into an INVITE listing an
option that it is not certain the destination UAS supports, the
client can query the destination UAS with an OPTIONS to see if this
option is returned in a Supported header field. All UAs MUST support
the OPTIONS method.
The target of the OPTIONS request is identified by the Request-URI,
which could identify another UA or a SIP server. If the OPTIONS is
addressed to a proxy server, the Request-URI is set without a user
part, similar to the way a Request-URI is set for a REGISTER request.
Alternatively, a server receiving an OPTIONS request with a Max-
Forwards header field value of 0 MAY respond to the request
regardless of the Request-URI.
This behavior is common with HTTP/1.1. This behavior can be used
as a "traceroute" functionality to check the capabilities of
individual hop servers by sending a series of OPTIONS requests
with incremented Max-Forwards values.
As is the case for general UA behavior, the transaction layer can
return a timeout error if the OPTIONS yields no response. This may
indicate that the target is unreachable and hence unavailable.
An OPTIONS request MAY be sent as part of an established dialog to
query the peer on capabilities that may be utilized later in the
11.1 Construction of OPTIONS Request
An OPTIONS request is constructed using the standard rules for a SIP
request as discussed in Section 8.1.1.
A Contact header field MAY be present in an OPTIONS.
An Accept header field SHOULD be included to indicate the type of
message body the UAC wishes to receive in the response. Typically,
this is set to a format that is used to describe the media
capabilities of a UA, such as SDP (application/sdp).
The response to an OPTIONS request is assumed to be scoped to the
Request-URI in the original request. However, only when an OPTIONS
is sent as part of an established dialog is it guaranteed that future
requests will be received by the server that generated the OPTIONS
Example OPTIONS request:
OPTIONS sip:email@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
From: Alice <sip:firstname.lastname@example.org>;tag=1928301774
CSeq: 63104 OPTIONS
11.2 Processing of OPTIONS Request
The response to an OPTIONS is constructed using the standard rules
for a SIP response as discussed in Section 8.2.6. The response code
chosen MUST be the same that would have been chosen had the request
been an INVITE. That is, a 200 (OK) would be returned if the UAS is
ready to accept a call, a 486 (Busy Here) would be returned if the
UAS is busy, etc. This allows an OPTIONS request to be used to
determine the basic state of a UAS, which can be an indication of
whether the UAS will accept an INVITE request.
An OPTIONS request received within a dialog generates a 200 (OK)
response that is identical to one constructed outside a dialog and
does not have any impact on the dialog.
This use of OPTIONS has limitations due to the differences in proxy
handling of OPTIONS and INVITE requests. While a forked INVITE can
result in multiple 200 (OK) responses being returned, a forked
OPTIONS will only result in a single 200 (OK) response, since it is
treated by proxies using the non-INVITE handling. See Section 16.7
for the normative details.
If the response to an OPTIONS is generated by a proxy server, the
proxy returns a 200 (OK), listing the capabilities of the server.
The response does not contain a message body.
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
fields SHOULD be present in a 200 (OK) response to an OPTIONS
request. If the response is generated by a proxy, the Allow header
field SHOULD be omitted as it is ambiguous since a proxy is method
agnostic. Contact header fields MAY be present in a 200 (OK)
response and have the same semantics as in a 3xx response. That is,
they may list a set of alternative names and methods of reaching the
user. A Warning header field MAY be present.
A message body MAY be sent, the type of which is determined by the
Accept header field in the OPTIONS request (application/sdp is the
default if the Accept header field is not present). If the types
include one that can describe media capabilities, the UAS SHOULD
include a body in the response for that purpose. Details on the
construction of such a body in the case of application/sdp are
described in .
Example OPTIONS response generated by a UAS (corresponding to the
request in Section 11.1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
From: Alice <sip:email@example.com>;tag=1928301774
CSeq: 63104 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
(SDP not shown)
A key concept for a user agent is that of a dialog. A dialog
represents a peer-to-peer SIP relationship between two user agents
that persists for some time. The dialog facilitates sequencing of
messages between the user agents and proper routing of requests
between both of them. The dialog represents a context in which to
interpret SIP messages. Section 8 discussed method independent UA
processing for requests and responses outside of a dialog. This
section discusses how those requests and responses are used to
construct a dialog, and then how subsequent requests and responses
are sent within a dialog.
A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA. The
tags are opaque tokens that facilitate the generation of unique
A dialog ID is also associated with all responses and with any
request that contains a tag in the To field. The rules for computing
the dialog ID of a message depend on whether the SIP element is a UAC
or UAS. For a UAC, the Call-ID value of the dialog ID is set to the
Call-ID of the message, the remote tag is set to the tag in the To
field of the message, and the local tag is set to the tag in the From
field of the message (these rules apply to both requests and
responses). As one would expect for a UAS, the Call-ID value of the
dialog ID is set to the Call-ID of the message, the remote tag is set
to the tag in the From field of the message, and the local tag is set
to the tag in the To field of the message.
A dialog contains certain pieces of state needed for further message
transmissions within the dialog. This state consists of the dialog
ID, a local sequence number (used to order requests from the UA to
its peer), a remote sequence number (used to order requests from its
peer to the UA), a local URI, a remote URI, remote target, a boolean
flag called "secure", and a route set, which is an ordered list of
URIs. The route set is the list of servers that need to be traversed
to send a request to the peer. A dialog can also be in the "early"
state, which occurs when it is created with a provisional response,
and then transition to the "confirmed" state when a 2xx final
response arrives. For other responses, or if no response arrives at
all on that dialog, the early dialog terminates.
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses
to requests with specific methods. Within this specification, only
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog. A dialog established by a non-final
response to a request is in the "early" state and it is called an
early dialog. Extensions MAY define other means for creating
dialogs. Section 13 gives more details that are specific to the
INVITE method. Here, we describe the process for creation of dialog
state that is not dependent on the method.
UAs MUST assign values to the dialog ID components as described
12.1.1 UAS behavior
When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values. The UAS MUST add a Contact header field to
the response. The Contact header field contains an address where the
UAS would like to be contacted for subsequent requests in the dialog
(which includes the ACK for a 2xx response in the case of an INVITE).
Generally, the host portion of this URI is the IP address or FQDN of
the host. The URI provided in the Contact header field MUST be a SIP
or SIPS URI. If the request that initiated the dialog contained a
SIPS URI in the Request-URI or in the top Record-Route header field
value, if there was any, or the Contact header field if there was no
Record-Route header field, the Contact header field in the response
MUST be a SIPS URI. The URI SHOULD have global scope (that is, the
same URI can be used in messages outside this dialog). The same way,
the scope of the URI in the Contact header field of the INVITE is not
limited to this dialog either. It can therefore be used in messages
to the UAC even outside this dialog.
The UAS then constructs the state of the dialog. This state MUST be
maintained for the duration of the dialog.
If the request arrived over TLS, and the Request-URI contained a SIPS
URI, the "secure" flag is set to TRUE.
The route set MUST be set to the list of URIs in the Record-Route
header field from the request, taken in order and preserving all URI
parameters. If no Record-Route header field is present in the
request, the route set MUST be set to the empty set. This route set,
even if empty, overrides any pre-existing route set for future
requests in this dialog. The remote target MUST be set to the URI
from the Contact header field of the request.
The remote sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The local sequence
number MUST be empty. The call identifier component of the dialog ID
MUST be set to the value of the Call-ID in the request. The local
tag component of the dialog ID MUST be set to the tag in the To field
in the response to the request (which always includes a tag), and the
remote tag component of the dialog ID MUST be set to the tag from the
From field in the request. A UAS MUST be prepared to receive a
request without a tag in the From field, in which case the tag is
considered to have a value of null.
This is to maintain backwards compatibility with RFC 2543, which
did not mandate From tags.
The remote URI MUST be set to the URI in the From field, and the
local URI MUST be set to the URI in the To field.
12.1.2 UAC Behavior
When a UAC sends a request that can establish a dialog (such as an
INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
the same SIP URI can be used in messages outside this dialog) in the
Contact header field of the request. If the request has a Request-
URI or a topmost Route header field value with a SIPS URI, the
Contact header field MUST contain a SIPS URI.
When a UAC receives a response that establishes a dialog, it
constructs the state of the dialog. This state MUST be maintained
for the duration of the dialog.
If the request was sent over TLS, and the Request-URI contained a
SIPS URI, the "secure" flag is set to TRUE.
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters. If no Record-Route header field is present in
the response, the route set MUST be set to the empty set. This route
set, even if empty, overrides any pre-existing route set for future
requests in this dialog. The remote target MUST be set to the URI
from the Contact header field of the response.
The local sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The remote sequence
number MUST be empty (it is established when the remote UA sends a
request within the dialog). The call identifier component of the
dialog ID MUST be set to the value of the Call-ID in the request.
The local tag component of the dialog ID MUST be set to the tag in
the From field in the request, and the remote tag component of the
dialog ID MUST be set to the tag in the To field of the response. A
UAC MUST be prepared to receive a response without a tag in the To
field, in which case the tag is considered to have a value of null.
This is to maintain backwards compatibility with RFC 2543, which
did not mandate To tags.
The remote URI MUST be set to the URI in the To field, and the local
URI MUST be set to the URI in the From field.
12.2 Requests within a Dialog
Once a dialog has been established between two UAs, either of them
MAY initiate new transactions as needed within the dialog. The UA
sending the request will take the UAC role for the transaction. The
UA receiving the request will take the UAS role. Note that these may
be different roles than the UAs held during the transaction that
established the dialog.
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do. For dialogs that have been established with an
INVITE, the only target refresh request defined is re-INVITE (see
Section 14). Other extensions may define different target refresh
requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI,
and not the route set formed from the Record-Route. Updating the
latter would introduce severe backwards compatibility problems with
RFC 2543-compliant systems.
12.2.1 UAC Behavior
126.96.36.199 Generating the Request
A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog.
The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID. If the value of the remote or local tags is null,
the tag parameter MUST be omitted from the To or From header fields,
Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.
The Call-ID of the request MUST be set to the Call-ID of the dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers
equal the requests being acknowledged or cancelled). Therefore, if
the local sequence number is not empty, the value of the local
sequence number MUST be incremented by one, and this value MUST be
placed into the CSeq header field. If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of
Section 188.8.131.52. The method field in the CSeq header field value
MUST match the method of the request.
With a length of 32 bits, a client could generate, within a single
call, one request a second for about 136 years before needing to
wrap around. The initial value of the sequence number is chosen
so that subsequent requests within the same call will not wrap
around. A non-zero initial value allows clients to use a time-
based initial sequence number. A client could, for example,
choose the 31 most significant bits of a 32-bit second clock as an
initial sequence number.
The UAC uses the remote target and route set to build the Request-URI
and Route header field of the request.
If the route set is empty, the UAC MUST place the remote target URI
into the Request-URI. The UAC MUST NOT add a Route header field to
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
If the route set is not empty, and its first URI does not contain the
lr parameter, the UAC MUST place the first URI from the route set
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the remote target URI into the
Route header field as the last value.
For example, if the remote target is sip:user@remoteua and the route
The request will be formed with the following Request-URI and Route
If the first URI of the route set does not contain the lr
parameter, the proxy indicated does not understand the routing
mechanisms described in this document and will act as specified in
RFC 2543, replacing the Request-URI with the first Route header
field value it receives while forwarding the message. Placing the
Request-URI at the end of the Route header field preserves the
information in that Request-URI across the strict router (it will
be returned to the Request-URI when the request reaches a loose-
A UAC SHOULD include a Contact header field in any target refresh
requests within a dialog, and unless there is a need to change it,
the URI SHOULD be the same as used in previous requests within the
dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.
As discussed in Section 12.2.2, a Contact header field in a target
refresh request updates the remote target URI. This allows a UA to
provide a new contact address, should its address change during the
duration of the dialog.
However, requests that are not target refresh requests do not affect
the remote target URI for the dialog.
The rest of the request is formed as described in Section 8.1.1.
Once the request has been constructed, the address of the server is
computed and the request is sent, using the same procedures for
requests outside of a dialog (Section 8.1.2).
The procedures in Section 8.1.2 will normally result in the
request being sent to the address indicated by the topmost Route
header field value or the Request-URI if no Route header field is
present. Subject to certain restrictions, they allow the request
to be sent to an alternate address (such as a default outbound
proxy not represented in the route set).
184.108.40.206 Processing the Responses
The UAC will receive responses to the request from the transaction
layer. If the client transaction returns a timeout, this is treated
as a 408 (Request Timeout) response.
The behavior of a UAC that receives a 3xx response for a request sent
within a dialog is the same as if the request had been sent outside a
dialog. This behavior is described in Section 220.127.116.11.
Note, however, that when the UAC tries alternative locations, it
still uses the route set for the dialog to build the Route header
of the request.
When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.
If the response for a request within a dialog is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if
no response at all is received for the request (the client
transaction would inform the TU about the timeout.)
For INVITE initiated dialogs, terminating the dialog consists of
sending a BYE.
12.2.2 UAS Behavior
Requests sent within a dialog, as any other requests, are atomic. If
a particular request is accepted by the UAS, all the state changes
associated with it are performed. If the request is rejected, none
of the state changes are performed.
Note that some requests, such as INVITEs, affect several pieces of
The UAS will receive the request from the transaction layer. If the
request has a tag in the To header field, the UAS core computes the
dialog identifier corresponding to the request and compares it with
existing dialogs. If there is a match, this is a mid-dialog request.
In that case, the UAS first applies the same processing rules for
requests outside of a dialog, discussed in Section 8.2.
If the request has a tag in the To header field, but the dialog
identifier does not match any existing dialogs, the UAS may have
crashed and restarted, or it may have received a request for a
different (possibly failed) UAS (the UASs can construct the To tags
so that a UAS can identify that the tag was for a UAS for which it is
providing recovery). Another possibility is that the incoming
request has been simply misrouted. Based on the To tag, the UAS MAY
either accept or reject the request. Accepting the request for
acceptable To tags provides robustness, so that dialogs can persist
even through crashes. UAs wishing to support this capability must
take into consideration some issues such as choosing monotonically
increasing CSeq sequence numbers even across reboots, reconstructing
the route set, and accepting out-of-range RTP timestamps and sequence
If the UAS wishes to reject the request because it does not wish to
recreate the dialog, it MUST respond to the request with a 481
(Call/Transaction Does Not Exist) status code and pass that to the
Requests that do not change in any way the state of a dialog may be
received within a dialog (for example, an OPTIONS request). They are
processed as if they had been received outside the dialog.
If the remote sequence number is empty, it MUST be set to the value
of the sequence number in the CSeq header field value in the request.
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response. If the remote sequence number was not empty, and
the sequence number of the request is greater than the remote
sequence number, the request is in order. It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one. This is not an error condition, and a UAS SHOULD be
prepared to receive and process requests with CSeq values more than
one higher than the previous received request. The UAS MUST then set
the remote sequence number to the value of the sequence number in the
CSeq header field value in the request.
If a proxy challenges a request generated by the UAC, the UAC has
to resubmit the request with credentials. The resubmitted request
will have a new CSeq number. The UAS will never see the first
request, and thus, it will notice a gap in the CSeq number space.
Such a gap does not represent any error condition.
When a UAS receives a target refresh request, it MUST replace the
dialog's remote target URI with the URI from the Contact header field
in that request, if present.
12.3 Termination of a Dialog
Independent of the method, if a request outside of a dialog generates
a non-2xx final response, any early dialogs created through
provisional responses to that request are terminated. The mechanism
for terminating confirmed dialogs is method specific. In this
specification, the BYE method terminates a session and the dialog
associated with it. See Section 15 for details.