8 General User Agent Behavior

   A user agent represents an end system.  It contains a user agent
   client (UAC), which generates requests, and a user agent server
   (UAS), which responds to them.  A UAC is capable of generating a
   request based on some external stimulus (the user clicking a button,
   or a signal on a PSTN line) and processing a response.  A UAS is
   capable of receiving a request and generating a response based on
   user input, external stimulus, the result of a program execution, or
   some other mechanism.

   When a UAC sends a request, the request passes through some number of
   proxy servers, which forward the request towards the UAS. When the
   UAS generates a response, the response is forwarded towards the UAC.

   UAC and UAS procedures depend strongly on two factors.  First, based
   on whether the request or response is inside or outside of a dialog,
   and second, based on the method of a request.  Dialogs are discussed
   thoroughly in Section 12; they represent a peer-to-peer relationship
   between user agents and are established by specific SIP methods, such
   as INVITE.

   In this section, we discuss the method-independent rules for UAC and
   UAS behavior when processing requests that are outside of a dialog.
   This includes, of course, the requests which themselves establish a
   dialog.

   Security procedures for requests and responses outside of a dialog
   are described in Section 26.  Specifically, mechanisms exist for the
   UAS and UAC to mutually authenticate.  A limited set of privacy
   features are also supported through encryption of bodies using
   S/MIME.

8.1 UAC Behavior

   This section covers UAC behavior outside of a dialog.

8.1.1 Generating the Request

   A valid SIP request formulated by a UAC MUST, at a minimum, contain
   the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
   and Via; all of these header fields are mandatory in all SIP
   requests.  These six header fields are the fundamental building
   blocks of a SIP message, as they jointly provide for most of the
   critical message routing services including the addressing of
   messages, the routing of responses, limiting message propagation,
   ordering of messages, and the unique identification of transactions.
   These header fields are in addition to the mandatory request line,
   which contains the method, Request-URI, and SIP version.

   Examples of requests sent outside of a dialog include an INVITE to
   establish a session (Section 13) and an OPTIONS to query for
   capabilities (Section 11).

8.1.1.1 Request-URI

   The initial Request-URI of the message SHOULD be set to the value of
   the URI in the To field.  One notable exception is the REGISTER
   method; behavior for setting the Request-URI of REGISTER is given in
   Section 10.  It may also be undesirable for privacy reasons or
   convenience to set these fields to the same value (especially if the
   originating UA expects that the Request-URI will be changed during
   transit).

   In some special circumstances, the presence of a pre-existing route
   set can affect the Request-URI of the message.  A pre-existing route
   set is an ordered set of URIs that identify a chain of servers, to
   which a UAC will send outgoing requests that are outside of a dialog.
   Commonly, they are configured on the UA by a user or service provider
   manually, or through some other non-SIP mechanism.  When a provider
   wishes to configure a UA with an outbound proxy, it is RECOMMENDED
   that this be done by providing it with a pre-existing route set with
   a single URI, that of the outbound proxy.

   When a pre-existing route set is present, the procedures for
   populating the Request-URI and Route header field detailed in Section
   12.2.1.1 MUST be followed (even though there is no dialog), using the
   desired Request-URI as the remote target URI.

8.1.1.2 To

   The To header field first and foremost specifies the desired
   "logical" recipient of the request, or the address-of-record of the
   user or resource that is the target of this request.  This may or may
   not be the ultimate recipient of the request.  The To header field
   MAY contain a SIP or SIPS URI, but it may also make use of other URI
   schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
   All SIP implementations MUST support the SIP URI scheme.  Any
   implementation that supports TLS MUST support the SIPS URI scheme.
   The To header field allows for a display name.

   A UAC may learn how to populate the To header field for a particular
   request in a number of ways.  Usually the user will suggest the To
   header field through a human interface, perhaps inputting the URI
   manually or selecting it from some sort of address book.  Frequently,
   the user will not enter a complete URI, but rather a string of digits
   or letters (for example, "bob").  It is at the discretion of the UA
   to choose how to interpret this input.  Using the string to form the
   user part of a SIP URI implies that the UA wishes the name to be
   resolved in the domain to the right-hand side (RHS) of the at-sign in
   the SIP URI (for instance, sip:bob@example.com).  Using the string to
   form the user part of a SIPS URI implies that the UA wishes to
   communicate securely, and that the name is to be resolved in the
   domain to the RHS of the at-sign.  The RHS will frequently be the
   home domain of the requestor, which allows for the home domain to
   process the outgoing request.  This is useful for features like
   "speed dial" that require interpretation of the user part in the home
   domain.  The tel URL may be used when the UA does not wish to specify
   the domain that should interpret a telephone number that has been
   input by the user.  Rather, each domain through which the request
   passes would be given that opportunity.  As an example, a user in an
   airport might log in and send requests through an outbound proxy in
   the airport.  If they enter "411" (this is the phone number for local
   directory assistance in the United States), that needs to be
   interpreted and processed by the outbound proxy in the airport, not
   the user's home domain.  In this case, tel:411 would be the right
   choice.

   A request outside of a dialog MUST NOT contain a To tag; the tag in
   the To field of a request identifies the peer of the dialog.  Since
   no dialog is established, no tag is present.

   For further information on the To header field, see Section 20.39.
   The following is an example of a valid To header field:

      To: Carol <sip:carol@chicago.com>

8.1.1.3 From

   The From header field indicates the logical identity of the initiator
   of the request, possibly the user's address-of-record.  Like the To
   header field, it contains a URI and optionally a display name.  It is
   used by SIP elements to determine which processing rules to apply to
   a request (for example, automatic call rejection).  As such, it is
   very important that the From URI not contain IP addresses or the FQDN
   of the host on which the UA is running, since these are not logical
   names.

   The From header field allows for a display name.  A UAC SHOULD use
   the display name "Anonymous", along with a syntactically correct, but
   otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
   identity of the client is to remain hidden.

   Usually, the value that populates the From header field in requests
   generated by a particular UA is pre-provisioned by the user or by the
   administrators of the user's local domain.  If a particular UA is
   used by multiple users, it might have switchable profiles that
   include a URI corresponding to the identity of the profiled user.
   Recipients of requests can authenticate the originator of a request
   in order to ascertain that they are who their From header field
   claims they are (see Section 22 for more on authentication).

   The From field MUST contain a new "tag" parameter, chosen by the UAC.
   See Section 19.3 for details on choosing a tag.

   For further information on the From header field, see Section 20.20.
   Examples:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
      From: sip:+12125551212@phone2net.com;tag=887s
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

8.1.1.4 Call-ID

   The Call-ID header field acts as a unique identifier to group
   together a series of messages.  It MUST be the same for all requests
   and responses sent by either UA in a dialog.  It SHOULD be the same
   in each registration from a UA.

   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.  Note that when requests are retried after certain

   failure responses that solicit an amendment to a request (for
   example, a challenge for authentication), these retried requests are
   not considered new requests, and therefore do not need new Call-ID
   header fields; see Section 8.1.3.5.

   Use of cryptographically random identifiers (RFC 1750 [12]) in the
   generation of Call-IDs is RECOMMENDED.  Implementations MAY use the
   form "localid@host".  Call-IDs are case-sensitive and are simply
   compared byte-by-byte.

      Using cryptographically random identifiers provides some
      protection against session hijacking and reduces the likelihood of
      unintentional Call-ID collisions.

   No provisioning or human interface is required for the selection of
   the Call-ID header field value for a request.

   For further information on the Call-ID header field, see Section
   20.8.

   Example:

      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

8.1.1.5 CSeq

   The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

   Section 12.2.1.1 discusses construction of the CSeq for requests
   within a dialog.

   Example:

      CSeq: 4711 INVITE

8.1.1.6 Max-Forwards

   The Max-Forwards header field serves to limit the number of hops a
   request can transit on the way to its destination.  It consists of an
   integer that is decremented by one at each hop.  If the Max-Forwards
   value reaches 0 before the request reaches its destination, it will
   be rejected with a 483(Too Many Hops) error response.

   A UAC MUST insert a Max-Forwards header field into each request it
   originates with a value that SHOULD be 70.  This number was chosen to
   be sufficiently large to guarantee that a request would not be
   dropped in any SIP network when there were no loops, but not so large
   as to consume proxy resources when a loop does occur.  Lower values
   should be used with caution and only in networks where topologies are
   known by the UA.

8.1.1.7 Via

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

   The branch parameter value MUST be unique across space and time for
   all requests sent by the UA.  The exceptions to this rule are CANCEL
   and ACK for non-2xx responses.  As discussed below, a CANCEL request
   will have the same value of the branch parameter as the request it
   cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
   response will also have the same branch ID as the INVITE whose
   response it acknowledges.

      The uniqueness property of the branch ID parameter, to facilitate
      its use as a transaction ID, was not part of RFC 2543.

   The branch ID inserted by an element compliant with this
   specification MUST always begin with the characters "z9hG4bK".  These
   7 characters are used as a magic cookie (7 is deemed sufficient to
   ensure that an older RFC 2543 implementation would not pick such a
   value), so that servers receiving the request can determine that the
   branch ID was constructed in the fashion described by this

   specification (that is, globally unique).  Beyond this requirement,
   the precise format of the branch token is implementation-defined.

   The Via header maddr, ttl, and sent-by components will be set when
   the request is processed by the transport layer (Section 18).

   Via processing for proxies is described in Section 16.6 Item 8 and
   Section 16.7 Item 3.

8.1.1.8 Contact

   The Contact header field provides a SIP or SIPS URI that can be used
   to contact that specific instance of the UA for subsequent requests.
   The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request.  For these requests, the scope of the
   Contact is global.  That is, the Contact header field value contains
   the URI at which the UA would like to receive requests, and this URI
   MUST be valid even if used in subsequent requests outside of any
   dialogs.

   If the Request-URI or top Route header field value contains a SIPS
   URI, the Contact header field MUST contain a SIPS URI as well.

   For further information on the Contact header field, see Section
   20.10.

8.1.1.9 Supported and Require

   If the UAC supports extensions to SIP that can be applied by the
   server to the response, the UAC SHOULD include a Supported header
   field in the request listing the option tags (Section 19.2) for those
   extensions.

   The option tags listed MUST only refer to extensions defined in
   standards-track RFCs.  This is to prevent servers from insisting that
   clients implement non-standard, vendor-defined features in order to
   receive service.  Extensions defined by experimental and
   informational RFCs are explicitly excluded from usage with the
   Supported header field in a request, since they too are often used to
   document vendor-defined extensions.

   If the UAC wishes to insist that a UAS understand an extension that
   the UAC will apply to the request in order to process the request, it
   MUST insert a Require header field into the request listing the
   option tag for that extension.  If the UAC wishes to apply an
   extension to the request and insist that any proxies that are

   traversed understand that extension, it MUST insert a Proxy-Require
   header field into the request listing the option tag for that
   extension.

   As with the Supported header field, the option tags in the Require
   and Proxy-Require header fields MUST only refer to extensions defined
   in standards-track RFCs.

8.1.1.10 Additional Message Components

   After a new request has been created, and the header fields described
   above have been properly constructed, any additional optional header
   fields are added, as are any header fields specific to the method.

   SIP requests MAY contain a MIME-encoded message-body.  Regardless of
   the type of body that a request contains, certain header fields must
   be formulated to characterize the contents of the body.  For further
   information on these header fields, see Sections 20.11 through 20.15.

8.1.2 Sending the Request

   The destination for the request is then computed.  Unless there is
   local policy specifying otherwise, the destination MUST be determined
   by applying the DNS procedures described in [4] as follows.  If the
   first element in the route set indicated a strict router (resulting
   in forming the request as described in Section 12.2.1.1), the
   procedures MUST be applied to the Request-URI of the request.
   Otherwise, the procedures are applied to the first Route header field
   value in the request (if one exists), or to the request's Request-URI
   if there is no Route header field present.  These procedures yield an
   ordered set of address, port, and transports to attempt.  Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI.

   Local policy MAY specify an alternate set of destinations to attempt.
   If the Request-URI contains a SIPS URI, any alternate destinations
   MUST be contacted with TLS.  Beyond that, there are no restrictions
   on the alternate destinations if the request contains no Route header
   field.  This provides a simple alternative to a pre-existing route
   set as a way to specify an outbound proxy.  However, that approach
   for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
   route set with a single URI SHOULD be used instead.  If the request
   contains a Route header field, the request SHOULD be sent to the
   locations derived from its topmost value, but MAY be sent to any
   server that the UA is certain will honor the Route and Request-URI
   policies specified in this document (as opposed to those in RFC
   2543).  In particular, a UAC configured with an outbound proxy SHOULD

   attempt to send the request to the location indicated in the first
   Route header field value instead of adopting the policy of sending
   all messages to the outbound proxy.

      This ensures that outbound proxies that do not add Record-Route
      header field values will drop out of the path of subsequent
      requests.  It allows endpoints that cannot resolve the first Route
      URI to delegate that task to an outbound proxy.

   The UAC SHOULD follow the procedures defined in [4] for stateful
   elements, trying each address until a server is contacted.  Each try
   constitutes a new transaction, and therefore each carries a different
   topmost Via header field value with a new branch parameter.
   Furthermore, the transport value in the Via header field is set to
   whatever transport was determined for the target server.

8.1.3 Processing Responses

   Responses are first processed by the transport layer and then passed
   up to the transaction layer.  The transaction layer performs its
   processing and then passes the response up to the TU.  The majority
   of response processing in the TU is method specific.  However, there
   are some general behaviors independent of the method.

8.1.3.1 Transaction Layer Errors

   In some cases, the response returned by the transaction layer will
   not be a SIP message, but rather a transaction layer error.  When a
   timeout error is received from the transaction layer, it MUST be
   treated as if a 408 (Request Timeout) status code has been received.
   If a fatal transport error is reported by the transport layer
   (generally, due to fatal ICMP errors in UDP or connection failures in
   TCP), the condition MUST be treated as a 503 (Service Unavailable)
   status code.

8.1.3.2 Unrecognized Responses

   A UAC MUST treat any final response it does not recognize as being
   equivalent to the x00 response code of that class, and MUST be able
   to process the x00 response code for all classes.  For example, if a
   UAC receives an unrecognized response code of 431, it can safely
   assume that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code.  A
   UAC MUST treat any provisional response different than 100 that it
   does not recognize as 183 (Session Progress).  A UAC MUST be able to
   process 100 and 183 responses.

8.1.3.3 Vias

   If more than one Via header field value is present in a response, the
   UAC SHOULD discard the message.

      The presence of additional Via header field values that precede
      the originator of the request suggests that the message was
      misrouted or possibly corrupted.

8.1.3.4 Processing 3xx Responses

   Upon receipt of a redirection response (for example, a 301 response
   status code), clients SHOULD use the URI(s) in the Contact header
   field to formulate one or more new requests based on the redirected
   request.  This process is similar to that of a proxy recursing on a
   3xx class response as detailed in Sections 16.5 and 16.6.  A client
   starts with an initial target set containing exactly one URI, the
   Request-URI of the original request.  If a client wishes to formulate
   new requests based on a 3xx class response to that request, it places
   the URIs to try into the target set.  Subject to the restrictions in
   this specification, a client can choose which Contact URIs it places
   into the target set.  As with proxy recursion, a client processing
   3xx class responses MUST NOT add any given URI to the target set more
   than once.  If the original request had a SIPS URI in the Request-
   URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
   inform the user of the redirection to an insecure URI.

      Any new request may receive 3xx responses themselves containing
      the original URI as a contact.  Two locations can be configured to
      redirect to each other.  Placing any given URI in the target set
      only once prevents infinite redirection loops.

   As the target set grows, the client MAY generate new requests to the
   URIs in any order.  A common mechanism is to order the set by the "q"
   parameter value from the Contact header field value.  Requests to the
   URIs MAY be generated serially or in parallel.  One approach is to
   process groups of decreasing q-values serially and process the URIs
   in each q-value group in parallel.  Another is to perform only serial
   processing in decreasing q-value order, arbitrarily choosing between
   contacts of equal q-value.

   If contacting an address in the list results in a failure, as defined
   in the next paragraph, the element moves to the next address in the
   list, until the list is exhausted.  If the list is exhausted, then
   the request has failed.

   Failures SHOULD be detected through failure response codes (codes
   greater than 399); for network errors the client transaction will
   report any transport layer failures to the transaction user.  Note
   that some response codes (detailed in 8.1.3.5) indicate that the
   request can be retried; requests that are reattempted should not be
   considered failures.

   When a failure for a particular contact address is received, the
   client SHOULD try the next contact address.  This will involve
   creating a new client transaction to deliver a new request.

   In order to create a request based on a contact address in a 3xx
   response, a UAC MUST copy the entire URI from the target set into the
   Request-URI, except for the "method-param" and "header" URI
   parameters (see Section 19.1.1 for a definition of these parameters).
   It uses the "header" parameters to create header field values for the
   new request, overwriting header field values associated with the
   redirected request in accordance with the guidelines in Section
   19.1.5.

   Note that in some instances, header fields that have been
   communicated in the contact address may instead append to existing
   request header fields in the original redirected request.  As a
   general rule, if the header field can accept a comma-separated list
   of values, then the new header field value MAY be appended to any
   existing values in the original redirected request.  If the header
   field does not accept multiple values, the value in the original
   redirected request MAY be overwritten by the header field value
   communicated in the contact address.  For example, if a contact
   address is returned with the following value:

      sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E

   Then any Subject header field in the original redirected request is
   overwritten, but the HTTP URL is merely appended to any existing
   Call-Info header field values.

   It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
   used in the original redirected request, but the UAC MAY also choose
   to update the Call-ID header field value for new requests, for
   example.

   Finally, once the new request has been constructed, it is sent using
   a new client transaction, and therefore MUST have a new branch ID in
   the top Via field as discussed in Section 8.1.1.7.

   In all other respects, requests sent upon receipt of a redirect
   response SHOULD re-use the header fields and bodies of the original
   request.

   In some instances, Contact header field values may be cached at UAC
   temporarily or permanently depending on the status code received and
   the presence of an expiration interval; see Sections 21.3.2 and
   21.3.3.

8.1.3.5 Processing 4xx Responses

   Certain 4xx response codes require specific UA processing,
   independent of the method.

   If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
   response is received, the UAC SHOULD follow the authorization
   procedures of Section 22.2 and Section 22.3 to retry the request with
   credentials.

   If a 413 (Request Entity Too Large) response is received (Section
   21.4.11), the request contained a body that was longer than the UAS
   was willing to accept.  If possible, the UAC SHOULD retry the
   request, either omitting the body or using one of a smaller length.

   If a 415 (Unsupported Media Type) response is received (Section
   21.4.13), the request contained media types not supported by the UAS.
   The UAC SHOULD retry sending the request, this time only using
   content with types listed in the Accept header field in the response,
   with encodings listed in the Accept-Encoding header field in the
   response, and with languages listed in the Accept-Language in the
   response.

   If a 416 (Unsupported URI Scheme) response is received (Section
   21.4.14), the Request-URI used a URI scheme not supported by the
   server.  The client SHOULD retry the request, this time, using a SIP
   URI.

   If a 420 (Bad Extension) response is received (Section 21.4.15), the
   request contained a Require or Proxy-Require header field listing an
   option-tag for a feature not supported by a proxy or UAS.  The UAC
   SHOULD retry the request, this time omitting any extensions listed in
   the Unsupported header field in the response.

   In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.

   With other 4xx responses, including those yet to be defined, a retry
   may or may not be possible depending on the method and the use case.

8.2 UAS Behavior

   When a request outside of a dialog is processed by a UAS, there is a
   set of processing rules that are followed, independent of the method.
   Section 12 gives guidance on how a UAS can tell whether a request is
   inside or outside of a dialog.

   Note that request processing is atomic.  If a request is accepted,
   all state changes associated with it MUST be performed.  If it is
   rejected, all state changes MUST NOT be performed.

   UASs SHOULD process the requests in the order of the steps that
   follow in this section (that is, starting with authentication, then
   inspecting the method, the header fields, and so on throughout the
   remainder of this section).

8.2.1 Method Inspection

   Once a request is authenticated (or authentication is skipped), the
   UAS MUST inspect the method of the request.  If the UAS recognizes
   but does not support the method of a request, it MUST generate a 405
   (Method Not Allowed) response.  Procedures for generating responses
   are described in Section 8.2.6.  The UAS MUST also add an Allow
   header field to the 405 (Method Not Allowed) response.  The Allow
   header field MUST list the set of methods supported by the UAS
   generating the message.  The Allow header field is presented in
   Section 20.5.

   If the method is one supported by the server, processing continues.

8.2.2 Header Inspection

   If a UAS does not understand a header field in a request (that is,
   the header field is not defined in this specification or in any
   supported extension), the server MUST ignore that header field and
   continue processing the message.  A UAS SHOULD ignore any malformed
   header fields that are not necessary for processing requests.

8.2.2.1 To and Request-URI

   The To header field identifies the original recipient of the request
   designated by the user identified in the From field.  The original
   recipient may or may not be the UAS processing the request, due to
   call forwarding or other proxy operations.  A UAS MAY apply any
   policy it wishes to determine whether to accept requests when the To

   header field is not the identity of the UAS.  However, it is
   RECOMMENDED that a UAS accept requests even if they do not recognize
   the URI scheme (for example, a tel: URI) in the To header field, or
   if the To header field does not address a known or current user of
   this UAS.  If, on the other hand, the UAS decides to reject the
   request, it SHOULD generate a response with a 403 (Forbidden) status
   code and pass it to the server transaction for transmission.

   However, the Request-URI identifies the UAS that is to process the
   request.  If the Request-URI uses a scheme not supported by the UAS,
   it SHOULD reject the request with a 416 (Unsupported URI Scheme)
   response.  If the Request-URI does not identify an address that the
   UAS is willing to accept requests for, it SHOULD reject the request
   with a 404 (Not Found) response.  Typically, a UA that uses the
   REGISTER method to bind its address-of-record to a specific contact
   address will see requests whose Request-URI equals that contact
   address.  Other potential sources of received Request-URIs include
   the Contact header fields of requests and responses sent by the UA
   that establish or refresh dialogs.

8.2.2.2 Merged Requests

   If the request has no tag in the To header field, the UAS core MUST
   check the request against ongoing transactions.  If the From tag,
   Call-ID, and CSeq exactly match those associated with an ongoing
   transaction, but the request does not match that transaction (based
   on the matching rules in Section 17.2.3), the UAS core SHOULD
   generate a 482 (Loop Detected) response and pass it to the server
   transaction.

      The same request has arrived at the UAS more than once, following
      different paths, most likely due to forking.  The UAS processes
      the first such request received and responds with a 482 (Loop
      Detected) to the rest of them.

8.2.2.3 Require

   Assuming the UAS decides that it is the proper element to process the
   request, it examines the Require header field, if present.

   The Require header field is used by a UAC to tell a UAS about SIP
   extensions that the UAC expects the UAS to support in order to
   process the request properly.  Its format is described in Section
   20.32.  If a UAS does not understand an option-tag listed in a
   Require header field, it MUST respond by generating a response with
   status code 420 (Bad Extension).  The UAS MUST add an Unsupported
   header field, and list in it those options it does not understand
   amongst those in the Require header field of the request.

   Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
   request, or in an ACK request sent for a non-2xx response.  These
   header fields MUST be ignored if they are present in these requests.

   An ACK request for a 2xx response MUST contain only those Require and
   Proxy-Require values that were present in the initial request.

   Example:

      UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
                  Require: 100rel

      UAS->UAC:   SIP/2.0 420 Bad Extension
                  Unsupported: 100rel

      This behavior ensures that the client-server interaction will
      proceed without delay when all options are understood by both
      sides, and only slow down if options are not understood (as in the
      example above).  For a well-matched client-server pair, the
      interaction proceeds quickly, saving a round-trip often required
      by negotiation mechanisms.  In addition, it also removes ambiguity
      when the client requires features that the server does not
      understand.  Some features, such as call handling fields, are only
      of interest to end systems.

8.2.3 Content Processing

   Assuming the UAS understands any extensions required by the client,
   the UAS examines the body of the message, and the header fields that
   describe it.  If there are any bodies whose type (indicated by the
   Content-Type), language (indicated by the Content-Language) or
   encoding (indicated by the Content-Encoding) are not understood, and
   that body part is not optional (as indicated by the Content-
   Disposition header field), the UAS MUST reject the request with a 415
   (Unsupported Media Type) response.  The response MUST contain an
   Accept header field listing the types of all bodies it understands,
   in the event the request contained bodies of types not supported by
   the UAS.  If the request contained content encodings not understood
   by the UAS, the response MUST contain an Accept-Encoding header field
   listing the encodings understood by the UAS.  If the request
   contained content with languages not understood by the UAS, the
   response MUST contain an Accept-Language header field indicating the
   languages understood by the UAS.  Beyond these checks, body handling
   depends on the method and type.  For further information on the
   processing of content-specific header fields, see Section 7.4 as well
   as Section 20.11 through 20.15.

8.2.4 Applying Extensions

   A UAS that wishes to apply some extension when generating the
   response MUST NOT do so unless support for that extension is
   indicated in the Supported header field in the request.  If the
   desired extension is not supported, the server SHOULD rely only on
   baseline SIP and any other extensions supported by the client.  In
   rare circumstances, where the server cannot process the request
   without the extension, the server MAY send a 421 (Extension Required)
   response.  This response indicates that the proper response cannot be
   generated without support of a specific extension.  The needed
   extension(s) MUST be included in a Require header field in the
   response.  This behavior is NOT RECOMMENDED, as it will generally
   break interoperability.

   Any extensions applied to a non-421 response MUST be listed in a
   Require header field included in the response.  Of course, the server
   MUST NOT apply extensions not listed in the Supported header field in
   the request.  As a result of this, the Require header field in a
   response will only ever contain option tags defined in standards-
   track RFCs.

8.2.5 Processing the Request

   Assuming all of the checks in the previous subsections are passed,
   the UAS processing becomes method-specific.  Section 10 covers the
   REGISTER request, Section 11 covers the OPTIONS request, Section 13
   covers the INVITE request, and Section 15 covers the BYE request.

8.2.6 Generating the Response

   When a UAS wishes to construct a response to a request, it follows
   the general procedures detailed in the following subsections.
   Additional behaviors specific to the response code in question, which
   are not detailed in this section, may also be required.

   Once all procedures associated with the creation of a response have
   been completed, the UAS hands the response back to the server
   transaction from which it received the request.

8.2.6.1 Sending a Provisional Response

   One largely non-method-specific guideline for the generation of
   responses is that UASs SHOULD NOT issue a provisional response for a
   non-INVITE request.  Rather, UASs SHOULD generate a final response to
   a non-INVITE request as soon as possible.

   When a 100 (Trying) response is generated, any Timestamp header field
   present in the request MUST be copied into this 100 (Trying)
   response.  If there is a delay in generating the response, the UAS
   SHOULD add a delay value into the Timestamp value in the response.
   This value MUST contain the difference between the time of sending of
   the response and receipt of the request, measured in seconds.

8.2.6.2 Headers and Tags

   The From field of the response MUST equal the From header field of
   the request.  The Call-ID header field of the response MUST equal the
   Call-ID header field of the request.  The CSeq header field of the
   response MUST equal the CSeq field of the request.  The Via header
   field values in the response MUST equal the Via header field values
   in the request and MUST maintain the same ordering.

   If a request contained a To tag in the request, the To header field
   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present).  This serves to identify the UAS that is
   responding, possibly resulting in a component of a dialog ID.  The
   same tag MUST be used for all responses to that request, both final
   and provisional (again excepting the 100 (Trying)).  Procedures for
   the generation of tags are defined in Section 19.3.

8.2.7 Stateless UAS Behavior

   A stateless UAS is a UAS that does not maintain transaction state.
   It replies to requests normally, but discards any state that would
   ordinarily be retained by a UAS after a response has been sent.  If a
   stateless UAS receives a retransmission of a request, it regenerates
   the response and resends it, just as if it were replying to the first
   instance of the request. A UAS cannot be stateless unless the request
   processing for that method would always result in the same response
   if the requests are identical. This rules out stateless registrars,
   for example.  Stateless UASs do not use a transaction layer; they
   receive requests directly from the transport layer and send responses
   directly to the transport layer.

   The stateless UAS role is needed primarily to handle unauthenticated
   requests for which a challenge response is issued.  If
   unauthenticated requests were handled statefully, then malicious
   floods of unauthenticated requests could create massive amounts of

   transaction state that might slow or completely halt call processing
   in a UAS, effectively creating a denial of service condition; for
   more information see Section 26.1.5.

   The most important behaviors of a stateless UAS are the following:

      o  A stateless UAS MUST NOT send provisional (1xx) responses.

      o  A stateless UAS MUST NOT retransmit responses.

      o  A stateless UAS MUST ignore ACK requests.

      o  A stateless UAS MUST ignore CANCEL requests.

      o  To header tags MUST be generated for responses in a stateless
         manner - in a manner that will generate the same tag for the
         same request consistently.  For information on tag construction
         see Section 19.3.

   In all other respects, a stateless UAS behaves in the same manner as
   a stateful UAS.  A UAS can operate in either a stateful or stateless
   mode for each new request.

8.3 Redirect Servers

   In some architectures it may be desirable to reduce the processing
   load on proxy servers that are responsible for routing requests, and
   improve signaling path robustness, by relying on redirection.

   Redirection allows servers to push routing information for a request
   back in a response to the client, thereby taking themselves out of
   the loop of further messaging for this transaction while still aiding
   in locating the target of the request.  When the originator of the
   request receives the redirection, it will send a new request based on
   the URI(s) it has received.  By propagating URIs from the core of the
   network to its edges, redirection allows for considerable network
   scalability.

   A redirect server is logically constituted of a server transaction
   layer and a transaction user that has access to a location service of
   some kind (see Section 10 for more on registrars and location
   services).  This location service is effectively a database
   containing mappings between a single URI and a set of one or more
   alternative locations at which the target of that URI can be found.

   A redirect server does not issue any SIP requests of its own.  After
   receiving a request other than CANCEL, the server either refuses the
   request or gathers the list of alternative locations from the

   location service and returns a final response of class 3xx.  For
   well-formed CANCEL requests, it SHOULD return a 2xx response.  This
   response ends the SIP transaction.  The redirect server maintains
   transaction state for an entire SIP transaction.  It is the
   responsibility of clients to detect forwarding loops between redirect
   servers.

   When a redirect server returns a 3xx response to a request, it
   populates the list of (one or more) alternative locations into the
   Contact header field.  An "expires" parameter to the Contact header
   field values may also be supplied to indicate the lifetime of the
   Contact data.

   The Contact header field contains URIs giving the new locations or
   user names to try, or may simply specify additional transport
   parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)
   response may also give the same location and username that was
   targeted by the initial request but specify additional transport
   parameters such as a different server or multicast address to try, or
   a change of SIP transport from UDP to TCP or vice versa.

   However, redirect servers MUST NOT redirect a request to a URI equal
   to the one in the Request-URI; instead, provided that the URI does
   not point to itself, the server MAY proxy the request to the
   destination URI, or MAY reject it with a 404.

      If a client is using an outbound proxy, and that proxy actually
      redirects requests, a potential arises for infinite redirection
      loops.

   Note that a Contact header field value MAY also refer to a different
   resource than the one originally called.  For example, a SIP call
   connected to PSTN gateway may need to deliver a special informational
   announcement such as "The number you have dialed has been changed."

   A Contact response header field can contain any suitable URI
   indicating where the called party can be reached, not limited to SIP
   URIs.  For example, it could contain URIs for phones, fax, or irc (if
   they were defined) or a mailto:  (RFC 2368 [32]) URL.  Section 26.4.4
   discusses implications and limitations of redirecting a SIPS URI to a
   non-SIPS URI.

   The "expires" parameter of a Contact header field value indicates how
   long the URI is valid.  The value of the parameter is a number
   indicating seconds.  If this parameter is not provided, the value of
   the Expires header field determines how long the URI is valid.
   Malformed values SHOULD be treated as equivalent to 3600.

      This provides a modest level of backwards compatibility with RFC
      2543, which allowed absolute times in this header field.  If an
      absolute time is received, it will be treated as malformed, and
      then default to 3600.

   Redirect servers MUST ignore features that are not understood
   (including unrecognized header fields, any unknown option tags in
   Require, or even method names) and proceed with the redirection of
   the request in question.

9 Canceling a Request

   The previous section has discussed general UA behavior for generating
   requests and processing responses for requests of all methods.  In
   this section, we discuss a general purpose method, called CANCEL.

   The CANCEL request, as the name implies, is used to cancel a previous
   request sent by a client.  Specifically, it asks the UAS to cease
   processing the request and to generate an error response to that
   request.  CANCEL has no effect on a request to which a UAS has
   already given a final response.  Because of this, it is most useful
   to CANCEL requests to which it can take a server long time to
   respond.  For this reason, CANCEL is best for INVITE requests, which
   can take a long time to generate a response.  In that usage, a UAS
   that receives a CANCEL request for an INVITE, but has not yet sent a
   final response, would "stop ringing", and then respond to the INVITE
   with a specific error response (a 487).

   CANCEL requests can be constructed and sent by both proxies and user
   agent clients.  Section 15 discusses under what conditions a UAC
   would CANCEL an INVITE request, and Section 16.10 discusses proxy
   usage of CANCEL.

   A stateful proxy responds to a CANCEL, rather than simply forwarding
   a response it would receive from a downstream element.  For that
   reason, CANCEL is referred to as a "hop-by-hop" request, since it is
   responded to at each stateful proxy hop.

9.1 Client Behavior

   A CANCEL request SHOULD NOT be sent to cancel a request other than
   INVITE.

      Since requests other than INVITE are responded to immediately,
      sending a CANCEL for a non-INVITE request would always create a
      race condition.

   The following procedures are used to construct a CANCEL request.  The
   Request-URI, Call-ID, To, the numeric part of CSeq, and From header
   fields in the CANCEL request MUST be identical to those in the
   request being cancelled, including tags.  A CANCEL constructed by a
   client MUST have only a single Via header field value matching the
   top Via value in the request being cancelled.  Using the same values
   for these header fields allows the CANCEL to be matched with the
   request it cancels (Section 9.2 indicates how such matching occurs).
   However, the method part of the CSeq header field MUST have a value
   of CANCEL.  This allows it to be identified and processed as a
   transaction in its own right (See Section 17).

   If the request being cancelled contains a Route header field, the
   CANCEL request MUST include that Route header field's values.

      This is needed so that stateless proxies are able to route CANCEL
      requests properly.

   The CANCEL request MUST NOT contain any Require or Proxy-Require
   header fields.

   Once the CANCEL is constructed, the client SHOULD check whether it
   has received any response (provisional or final) for the request
   being cancelled (herein referred to as the "original request").

   If no provisional response has been received, the CANCEL request MUST
   NOT be sent; rather, the client MUST wait for the arrival of a
   provisional response before sending the request.  If the original
   request has generated a final response, the CANCEL SHOULD NOT be
   sent, as it is an effective no-op, since CANCEL has no effect on
   requests that have already generated a final response.  When the
   client decides to send the CANCEL, it creates a client transaction
   for the CANCEL and passes it the CANCEL request along with the
   destination address, port, and transport.  The destination address,
   port, and transport for the CANCEL MUST be identical to those used to
   send the original request.

      If it was allowed to send the CANCEL before receiving a response
      for the previous request, the server could receive the CANCEL
      before the original request.

   Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is

   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request.

9.2 Server Behavior

   The CANCEL method requests that the TU at the server side cancel a
   pending transaction.  The TU determines the transaction to be
   cancelled by taking the CANCEL request, and then assuming that the
   request method is anything but CANCEL or ACK and applying the
   transaction matching procedures of Section 17.2.3.  The matching
   transaction is the one to be cancelled.

   The processing of a CANCEL request at a server depends on the type of
   server.  A stateless proxy will forward it, a stateful proxy might
   respond to it and generate some CANCEL requests of its own, and a UAS
   will respond to it.  See Section 16.10 for proxy treatment of CANCEL.

   A UAS first processes the CANCEL request according to the general UAS
   processing described in Section 8.2.  However, since CANCEL requests
   are hop-by-hop and cannot be resubmitted, they cannot be challenged
   by the server in order to get proper credentials in an Authorization
   header field.  Note also that CANCEL requests do not contain a
   Require header field.

   If the UAS did not find a matching transaction for the CANCEL
   according to the procedure above, it SHOULD respond to the CANCEL
   with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction
   for the original request still exists, the behavior of the UAS on
   receiving a CANCEL request depends on whether it has already sent a
   final response for the original request.  If it has, the CANCEL
   request has no effect on the processing of the original request, no
   effect on any session state, and no effect on the responses generated
   for the original request.  If the UAS has not issued a final response
   for the original request, its behavior depends on the method of the
   original request.  If the original request was an INVITE, the UAS
   SHOULD immediately respond to the INVITE with a 487 (Request
   Terminated).  A CANCEL request has no impact on the processing of
   transactions with any other method defined in this specification.

   Regardless of the method of the original request, as long as the
   CANCEL matched an existing transaction, the UAS answers the CANCEL
   request itself with a 200 (OK) response.  This response is
   constructed following the procedures described in Section 8.2.6
   noting that the To tag of the response to the CANCEL and the To tag
   in the response to the original request SHOULD be the same.  The
   response to CANCEL is passed to the server transaction for
   transmission.