in Index   Prev   Next

RFC 3261

SIP: Session Initiation Protocol

Pages: 269
Proposed Standard
Obsoletes:  2543
Updated by:  326538534320491653935621562656305922595460266141666568787462746382178591876088988996
Part 3 of 13 – Pages 34 to 55
First   Prev   Next

Top   ToC   RFC3261 - Page 34   prevText

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.
Top   ToC   RFC3261 - Page 35

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). 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 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI.
Top   ToC   RFC3261 - Page 36 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, 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 <>
Top   ToC   RFC3261 - Page 37 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" <> ;tag=a48s From:;tag=887s From: Anonymous <>;tag=hyh8 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
Top   ToC   RFC3261 - Page 38
   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

   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


      Call-ID: 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 discusses construction of the CSeq for requests within a dialog. Example: CSeq: 4711 INVITE
Top   ToC   RFC3261 - Page 39 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. 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, 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
Top   ToC   RFC3261 - Page 40
   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. 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. 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
Top   ToC   RFC3261 - Page 41
   traversed understand that extension, it MUST insert a Proxy-Require
   header field into the request listing the option tag for that

   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. 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, 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
Top   ToC   RFC3261 - Page 42
   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. 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. 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.
Top   ToC   RFC3261 - Page 43 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. 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.
Top   ToC   RFC3261 - Page 44
   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 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

   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:


   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

   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
Top   ToC   RFC3261 - Page 45
   In all other respects, requests sent upon receipt of a redirect
   response SHOULD re-use the header fields and bodies of the original

   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. 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.
Top   ToC   RFC3261 - Page 46
   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. 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
Top   ToC   RFC3261 - Page 47
   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. 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. 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.
Top   ToC   RFC3261 - Page 48
   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.


      UAC->UAS:   INVITE 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.
Top   ToC   RFC3261 - Page 49

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. 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.
Top   ToC   RFC3261 - Page 50
   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. 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
Top   ToC   RFC3261 - Page 51
   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
Top   ToC   RFC3261 - Page 52
   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

   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

   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.
Top   ToC   RFC3261 - Page 53
      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.
Top   ToC   RFC3261 - Page 54
   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
Top   ToC   RFC3261 - Page 55
   defined in Section, 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.

(next page on part 4)

Next Section