10 Registrations

10.1 Overview

   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:bob@biloxi.com,
   for example, to one or more URIs that are somehow "closer" to the
   desired user, sip:bob@engineering.biloxi.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
   currently residing.

   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.

   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-
   record.

   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-
           party registration.

      Call-ID: All registrations from a UAC SHOULD use the same Call-ID
           header field value for registrations sent to a particular
           registrar.

           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.

                                                 bob
                                               +----+
                                               | UA |
                                               |    |
                                               +----+
                                                  |
                                                  |3)INVITE
                                                  |   carol@chicago.com
         chicago.com        +--------+            V
         +---------+ 2)Store|Location|4)Query +-----+
         |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
         +---------+        +--------+=======>+-----+
               A                      5)Resp      |
               |                                  |
               |                                  |
     1)REGISTER|                                  |
               |                                  |
            +----+                                |
            | UA |<-------------------------------+
   cube2214a|    |                            6)INVITE
            +----+                    carol@cube2214a.chicago.com
             carol

                      Figure 2: REGISTER example

      The following Contact header parameters have a special meaning in
           REGISTER requests:

      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:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
   A SIP UA can choose to register telephone numbers (with the tel URL,
   RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
   as Contacts for an address-of-record, for example.

   For example, Carol, with address-of-record "sip:carol@chicago.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
   endpoint.

   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
   registrar.

   If the address-of-record in the To header field of a REGISTER request
   is a SIPS URI, then any Contact header field values in the request
   SHOULD also be SIPS URIs.  Clients should only register non-SIPS URIs
   under a SIPS address-of-record when the security of the resource
   represented 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.

   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
   policy.)

   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
   other UAs.

   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 [4].  For example, the UA for
   the user "sip:carol@chicago.com" addresses the REGISTER request to
   "sip:chicago.com".

   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" (224.0.1.75 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 [33]); 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
      network.

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
         remaining steps.

         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
            requested expiration.

         -  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
         performance.

         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 request.

         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
   dialog.

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
   response.

   Example OPTIONS request:

      OPTIONS sip:carol@chicago.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
      Max-Forwards: 70
      To: <sip:carol@chicago.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:alice@pc33.atlanta.com>
      Accept: application/sdp
      Content-Length: 0

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 [13].

   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
       ;received=192.0.2.4
      To: <sip:carol@chicago.com>;tag=93810874
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 63104 OPTIONS
      Contact: <sip:carol@chicago.com>
      Contact: <mailto:carol@chicago.com>
      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
      Accept: application/sdp
      Accept-Encoding: gzip
      Accept-Language: en
      Supported: foo
      Content-Type: application/sdp
      Content-Length: 274

      (SDP not shown)

12 Dialogs

   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
   dialog IDs.

   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
   below.

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

12.2.1.1 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,
   respectively.

      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 8.1.1.5.  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
   the request.

   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
   parameters.

   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
   set contains:

      <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

   The request will be formed with the following Request-URI and Route
   header field:

   METHOD sip:proxy1
   Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

      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-
      router).

   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).

12.2.1.2 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 8.1.3.4.

      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
      state.

   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
   numbers.

   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
   server transaction.

   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.