21 Response Codes

   The response codes are consistent with, and extend, HTTP/1.1 response
   codes.  Not all HTTP/1.1 response codes are appropriate, and only
   those that are appropriate are given here.  Other HTTP/1.1 response
   codes SHOULD NOT be used.  Also, SIP defines a new class, 6xx.

21.1 Provisional 1xx

   Provisional responses, also known as informational responses,
   indicate that the server contacted is performing some further action
   and does not yet have a definitive response.  A server sends a 1xx
   response if it expects to take more than 200 ms to obtain a final
   response.  Note that 1xx responses are not transmitted reliably.
   They never cause the client to send an ACK.  Provisional (1xx)
   responses MAY contain message bodies, including session descriptions.

21.1.1 100 Trying

   This response indicates that the request has been received by the
   next-hop server and that some unspecified action is being taken on
   behalf of this call (for example, a database is being consulted).
   This response, like all other provisional responses, stops
   retransmissions of an INVITE by a UAC.  The 100 (Trying) response is
   different from other provisional responses, in that it is never
   forwarded upstream by a stateful proxy.

21.1.2 180 Ringing

   The UA receiving the INVITE is trying to alert the user.  This
   response MAY be used to initiate local ringback.

21.1.3 181 Call Is Being Forwarded

   A server MAY use this status code to indicate that the call is being
   forwarded to a different set of destinations.

21.1.4 182 Queued

   The called party is temporarily unavailable, but the server has
   decided to queue the call rather than reject it.  When the callee
   becomes available, it will return the appropriate final status
   response.  The reason phrase MAY give further details about the
   status of the call, for example, "5 calls queued; expected waiting
   time is 15 minutes".  The server MAY issue several 182 (Queued)
   responses to update the caller about the status of the queued call.

21.1.5 183 Session Progress

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.  The
   Reason-Phrase, header fields, or message body MAY be used to convey
   more details about the call progress.

21.2 Successful 2xx

   The request was successful.

21.2.1 200 OK

   The request has succeeded.  The information returned with the
   response depends on the method used in the request.

21.3 Redirection 3xx

   3xx responses give information about the user's new location, or
   about alternative services that might be able to satisfy the call.

21.3.1 300 Multiple Choices

   The address in the request resolved to several choices, each with its
   own specific location, and the user (or UA) can select a preferred
   communication end point and redirect its request to that location.

   The response MAY include a message body containing a list of resource
   characteristics and location(s) from which the user or UA can choose
   the one most appropriate, if allowed by the Accept request header
   field.  However, no MIME types have been defined for this message
   body.

   The choices SHOULD also be listed as Contact fields (Section 20.10).
   Unlike HTTP, the SIP response MAY contain several Contact fields or a
   list of addresses in a Contact field.  UAs MAY use the Contact header
   field value for automatic redirection or MAY ask the user to confirm
   a choice.  However, this specification does not define any standard
   for such automatic selection.

      This status response is appropriate if the callee can be reached
      at several different locations and the server cannot or prefers
      not to proxy the request.

21.3.2 301 Moved Permanently

   The user can no longer be found at the address in the Request-URI,
   and the requesting client SHOULD retry at the new address given by
   the Contact header field (Section 20.10).  The requestor SHOULD
   update any local directories, address books, and user location caches
   with this new value and redirect future requests to the address(es)
   listed.

21.3.3 302 Moved Temporarily

   The requesting client SHOULD retry the request at the new address(es)
   given by the Contact header field (Section 20.10).  The Request-URI
   of the new request uses the value of the Contact header field in the
   response.

   The duration of the validity of the Contact URI can be indicated
   through an Expires (Section 20.19) header field or an expires
   parameter in the Contact header field.  Both proxies and UAs MAY
   cache this URI for the duration of the expiration time.  If there is
   no explicit expiration time, the address is only valid once for
   recursing, and MUST NOT be cached for future transactions.

   If the URI cached from the Contact header field fails, the Request-
   URI from the redirected request MAY be tried again a single time.

      The temporary URI may have become out-of-date sooner than the
      expiration time, and a new temporary URI may be available.

21.3.4 305 Use Proxy

   The requested resource MUST be accessed through the proxy given by
   the Contact field.  The Contact field gives the URI of the proxy.
   The recipient is expected to repeat this single request via the
   proxy.  305 (Use Proxy) responses MUST only be generated by UASs.

21.3.5 380 Alternative Service

   The call was not successful, but alternative services are possible.

   The alternative services are described in the message body of the
   response.  Formats for such bodies are not defined here, and may be
   the subject of future standardization.

21.4 Request Failure 4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (for example, adding appropriate authorization).
   However, the same request to a different server might be successful.

21.4.1 400 Bad Request

   The request could not be understood due to malformed syntax.  The
   Reason-Phrase SHOULD identify the syntax problem in more detail, for
   example, "Missing Call-ID header field".

21.4.2 401 Unauthorized

   The request requires user authentication.  This response is issued by
   UASs and registrars, while 407 (Proxy Authentication Required) is
   used by proxy servers.

21.4.3 402 Payment Required

   Reserved for future use.

21.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help, and the request SHOULD NOT be repeated.

21.4.5 404 Not Found

   The server has definitive information that the user does not exist at
   the domain specified in the Request-URI.  This status is also
   returned if the domain in the Request-URI does not match any of the
   domains handled by the recipient of the request.

21.4.6 405 Method Not Allowed

   The method specified in the Request-Line is understood, but not
   allowed for the address identified by the Request-URI.

   The response MUST include an Allow header field containing a list of
   valid methods for the indicated address.

21.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities that have content characteristics not acceptable
   according to the Accept header field sent in the request.

21.4.8 407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized), but indicates that the
   client MUST first authenticate itself with the proxy.  SIP access
   authentication is explained in Sections 26 and 22.3.

   This status code can be used for applications where access to the
   communication channel (for example, a telephony gateway) rather than
   the callee requires authentication.

21.4.9 408 Request Timeout

   The server could not produce a response within a suitable amount of
   time, for example, if it could not determine the location of the user
   in time.  The client MAY repeat the request without modifications at
   any later time.

21.4.10 410 Gone

   The requested resource is no longer available at the server and no
   forwarding address is known.  This condition is expected to be
   considered permanent.  If the server does not know, or has no
   facility to determine, whether or not the condition is permanent, the
   status code 404 (Not Found) SHOULD be used instead.

21.4.11 413 Request Entity Too Large

   The server is refusing to process a request because the request
   entity-body is larger than the server is willing or able to process.
   The server MAY close the connection to prevent the client from
   continuing the request.

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client MAY try again.

21.4.12 414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret.

21.4.13 415 Unsupported Media Type

   The server is refusing to service the request because the message
   body of the request is in a format not supported by the server for
   the requested method.  The server MUST return a list of acceptable
   formats using the Accept, Accept-Encoding, or Accept-Language header
   field, depending on the specific problem with the content.  UAC
   processing of this response is described in Section 8.1.3.5.

21.4.14 416 Unsupported URI Scheme

   The server cannot process the request because the scheme of the URI
   in the Request-URI is unknown to the server.  Client processing of
   this response is described in Section 8.1.3.5.

21.4.15 420 Bad Extension

   The server did not understand the protocol extension specified in a
   Proxy-Require (Section 20.29) or Require (Section 20.32) header
   field.  The server MUST include a list of the unsupported extensions
   in an Unsupported header field in the response.  UAC processing of
   this response is described in Section 8.1.3.5.

21.4.16 421 Extension Required

   The UAS needs a particular extension to process the request, but this
   extension is not listed in a Supported header field in the request.
   Responses with this status code MUST contain a Require header field
   listing the required extensions.

   A UAS SHOULD NOT use this response unless it truly cannot provide any
   useful service to the client.  Instead, if a desirable extension is
   not listed in the Supported header field, servers SHOULD process the
   request using baseline SIP capabilities and any extensions supported
   by the client.

21.4.17 423 Interval Too Brief

   The server is rejecting the request because the expiration time of
   the resource refreshed by the request is too short.  This response
   can be used by a registrar to reject a registration whose Contact
   header field expiration time was too small.  The use of this response
   and the related Min-Expires header field are described in Sections
   10.2.8, 10.3, and 20.23.

21.4.18 480 Temporarily Unavailable

   The callee's end system was contacted successfully but the callee is
   currently unavailable (for example, is not logged in, logged in but
   in a state that precludes communication with the callee, or has
   activated the "do not disturb" feature).  The response MAY indicate a
   better time to call in the Retry-After header field.  The user could
   also be available elsewhere (unbeknownst to this server).  The reason
   phrase SHOULD indicate a more precise cause as to why the callee is
   unavailable.  This value SHOULD be settable by the UA.  Status 486
   (Busy Here) MAY be used to more precisely indicate a particular
   reason for the call failure.

   This status is also returned by a redirect or proxy server that
   recognizes the user identified by the Request-URI, but does not
   currently have a valid forwarding location for that user.

21.4.19 481 Call/Transaction Does Not Exist

   This status indicates that the UAS received a request that does not
   match any existing dialog or transaction.

21.4.20 482 Loop Detected

   The server has detected a loop (Section 16.3 Item 4).

21.4.21 483 Too Many Hops

   The server received a request that contains a Max-Forwards (Section
   20.22) header field with the value zero.

21.4.22 484 Address Incomplete

   The server received a request with a Request-URI that was incomplete.
   Additional information SHOULD be provided in the reason phrase.

      This status code allows overlapped dialing.  With overlapped
      dialing, the client does not know the length of the dialing
      string.  It sends strings of increasing lengths, prompting the
      user for more input, until it no longer receives a 484 (Address
      Incomplete) status response.

21.4.23 485 Ambiguous

   The Request-URI was ambiguous.  The response MAY contain a listing of
   possible unambiguous addresses in Contact header fields.  Revealing
   alternatives can infringe on privacy of the user or the organization.
   It MUST be possible to configure a server to respond with status 404
   (Not Found) or to suppress the listing of possible choices for
   ambiguous Request-URIs.

   Example response to a request with the Request-URI
   sip:lee@example.com:

      SIP/2.0 485 Ambiguous
      Contact: Carol Lee <sip:carol.lee@example.com>
      Contact: Ping Lee <sip:p.lee@example.com>
      Contact: Lee M. Foote <sips:lee.foote@example.com>

      Some email and voice mail systems provide this functionality.  A
      status code separate from 3xx is used since the semantics are
      different: for 300, it is assumed that the same person or service
      will be reached by the choices provided.  While an automated
      choice or sequential search makes sense for a 3xx response, user
      intervention is required for a 485 (Ambiguous) response.

21.4.24 486 Busy Here

   The callee's end system was contacted successfully, but the callee is
   currently not willing or able to take additional calls at this end
   system.  The response MAY indicate a better time to call in the
   Retry-After header field.  The user could also be available

   elsewhere, such as through a voice mail service.  Status 600 (Busy
   Everywhere) SHOULD be used if the client knows that no other end
   system will be able to accept this call.

21.4.25 487 Request Terminated

   The request was terminated by a BYE or CANCEL request.  This response
   is never returned for a CANCEL request itself.

21.4.26 488 Not Acceptable Here

   The response has the same meaning as 606 (Not Acceptable), but only
   applies to the specific resource addressed by the Request-URI and the
   request may succeed elsewhere.

   A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to the Accept
   header field in the INVITE (or application/sdp if not present), the
   same as a message body in a 200 (OK) response to an OPTIONS request.

21.4.27 491 Request Pending

   The request was received by a UAS that had a pending request within
   the same dialog.  Section 14.2 describes how such "glare" situations
   are resolved.

21.4.28 493 Undecipherable

   The request was received by a UAS that contained an encrypted MIME
   body for which the recipient does not possess or will not provide an
   appropriate decryption key.  This response MAY have a single body
   containing an appropriate public key that should be used to encrypt
   MIME bodies sent to this UA.  Details of the usage of this response
   code can be found in Section 23.2.

21.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred.

21.5.1 500 Server Internal Error

   The server encountered an unexpected condition that prevented it from
   fulfilling the request.  The client MAY display the specific error
   condition and MAY retry the request after several seconds.

   If the condition is temporary, the server MAY indicate when the
   client may retry the request using the Retry-After header field.

21.5.2 501 Not Implemented

   The server does not support the functionality required to fulfill the
   request.  This is the appropriate response when a UAS does not
   recognize the request method and is not capable of supporting it for
   any user.  (Proxies forward all requests regardless of method.)

   Note that a 405 (Method Not Allowed) is sent when the server
   recognizes the request method, but that method is not allowed or
   supported.

21.5.3 502 Bad Gateway

   The server, while acting as a gateway or proxy, received an invalid
   response from the downstream server it accessed in attempting to
   fulfill the request.

21.5.4 503 Service Unavailable

   The server is temporarily unable to process the request due to a
   temporary overloading or maintenance of the server.  The server MAY
   indicate when the client should retry the request in a Retry-After
   header field.  If no Retry-After is given, the client MUST act as if
   it had received a 500 (Server Internal Error) response.

   A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   attempt to forward the request to an alternate server.  It SHOULD NOT
   forward any other requests to that server for the duration specified
   in the Retry-After header field, if present.

   Servers MAY refuse the connection or drop the request instead of
   responding with 503 (Service Unavailable).

21.5.5 504 Server Time-out

   The server did not receive a timely response from an external server
   it accessed in attempting to process the request.  408 (Request
   Timeout) should be used instead if there was no response within the
   period specified in the Expires header field from the upstream
   server.

21.5.6 505 Version Not Supported

   The server does not support, or refuses to support, the SIP protocol
   version that was used in the request.  The server is indicating that
   it is unable or unwilling to complete the request using the same
   major version as the client, other than with this error message.

21.5.7 513 Message Too Large

   The server was unable to process the request since the message length
   exceeded its capabilities.

21.6 Global Failures 6xx

   6xx responses indicate that a server has definitive information about
   a particular user, not just the particular instance indicated in the
   Request-URI.

21.6.1 600 Busy Everywhere

   The callee's end system was contacted successfully but the callee is
   busy and does not wish to take the call at this time.  The response
   MAY indicate a better time to call in the Retry-After header field.
   If the callee does not wish to reveal the reason for declining the
   call, the callee uses status code 603 (Decline) instead.  This status
   response is returned only if the client knows that no other end point
   (such as a voice mail system) will answer the request.  Otherwise,
   486 (Busy Here) should be returned.

21.6.2 603 Decline

   The callee's machine was successfully contacted but the user
   explicitly does not wish to or cannot participate.  The response MAY
   indicate a better time to call in the Retry-After header field.  This
   status response is returned only if the client knows that no other
   end point will answer the request.

21.6.3 604 Does Not Exist Anywhere

   The server has authoritative information that the user indicated in
   the Request-URI does not exist anywhere.

21.6.4 606 Not Acceptable

   The user's agent was contacted successfully but some aspects of the
   session description such as the requested media, bandwidth, or
   addressing style were not acceptable.

   A 606 (Not Acceptable) response means that the user wishes to
   communicate, but cannot adequately support the session described.
   The 606 (Not Acceptable) response MAY contain a list of reasons in a
   Warning header field describing why the session described cannot be
   supported.  Warning reason codes are listed in Section 20.43.

   A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to the Accept
   header field in the INVITE (or application/sdp if not present), the
   same as a message body in a 200 (OK) response to an OPTIONS request.

   It is hoped that negotiation will not frequently be needed, and when
   a new user is being invited to join an already existing conference,
   negotiation may not be possible.  It is up to the invitation
   initiator to decide whether or not to act on a 606 (Not Acceptable)
   response.

   This status response is returned only if the client knows that no
   other end point will answer the request.

22 Usage of HTTP Authentication

   SIP provides a stateless, challenge-based mechanism for
   authentication that is based on authentication in HTTP.  Any time
   that a proxy server or UA receives a request (with the exceptions
   given in Section 22.1), it MAY challenge the initiator of the request
   to provide assurance of its identity.  Once the originator has been
   identified, the recipient of the request SHOULD ascertain whether or
   not this user is authorized to make the request in question.  No
   authorization systems are recommended or discussed in this document.

   The "Digest" authentication mechanism described in this section
   provides message authentication and replay protection only, without
   message integrity or confidentiality.  Protective measures above and
   beyond those provided by Digest need to be taken to prevent active
   attackers from modifying SIP requests and responses.

   Note that due to its weak security, the usage of "Basic"
   authentication has been deprecated.  Servers MUST NOT accept
   credentials using the "Basic" authorization scheme, and servers also
   MUST NOT challenge with "Basic".  This is a change from RFC 2543.

22.1 Framework

   The framework for SIP authentication closely parallels that of HTTP
   (RFC 2617 [17]).  In particular, the BNF for auth-scheme, auth-param,
   challenge, realm, realm-value, and credentials is identical (although
   the usage of "Basic" as a scheme is not permitted).  In SIP, a UAS
   uses the 401 (Unauthorized) response to challenge the identity of a
   UAC.  Additionally, registrars and redirect servers MAY make use of
   401 (Unauthorized) responses for authentication, but proxies MUST
   NOT, and instead MAY use the 407 (Proxy Authentication Required)

   response.  The requirements for inclusion of the Proxy-Authenticate,
   Proxy-Authorization, WWW-Authenticate, and Authorization in the
   various messages are identical to those described in RFC 2617 [17].

   Since SIP does not have the concept of a canonical root URL, the
   notion of protection spaces is interpreted differently in SIP.  The
   realm string alone defines the protection domain.  This is a change
   from RFC 2543, in which the Request-URI and the realm together
   defined the protection domain.

      This previous definition of protection domain caused some amount
      of confusion since the Request-URI sent by the UAC and the
      Request-URI received by the challenging server might be different,
      and indeed the final form of the Request-URI might not be known to
      the UAC.  Also, the previous definition depended on the presence
      of a SIP URI in the Request-URI and seemed to rule out alternative
      URI schemes (for example, the tel URL).

   Operators of user agents or proxy servers that will authenticate
   received requests MUST adhere to the following guidelines for
   creation of a realm string for their server:

      o  Realm strings MUST be globally unique.  It is RECOMMENDED that
         a realm string contain a hostname or domain name, following the
         recommendation in Section 3.2.1 of RFC 2617 [17].

      o  Realm strings SHOULD present a human-readable identifier that
         can be rendered to a user.

   For example:

      INVITE sip:bob@biloxi.com SIP/2.0
      Authorization: Digest realm="biloxi.com", <...>

   Generally, SIP authentication is meaningful for a specific realm, a
   protection domain.  Thus, for Digest authentication, each such
   protection domain has its own set of usernames and passwords.  If a
   server does not require authentication for a particular request, it
   MAY accept a default username, "anonymous", which has no password
   (password of "").  Similarly, UACs representing many users, such as
   PSTN gateways, MAY have their own device-specific username and
   password, rather than accounts for particular users, for their realm.

   While a server can legitimately challenge most SIP requests, there
   are two requests defined by this document that require special
   handling for authentication: ACK and CANCEL.

   Under an authentication scheme that uses responses to carry values
   used to compute nonces (such as Digest), some problems come up for
   any requests that take no response, including ACK.  For this reason,
   any credentials in the INVITE that were accepted by a server MUST be
   accepted by that server for the ACK.  UACs creating an ACK message
   will duplicate all of the Authorization and Proxy-Authorization
   header field values that appeared in the INVITE to which the ACK
   corresponds.  Servers MUST NOT attempt to challenge an ACK.

   Although the CANCEL method does take a response (a 2xx), servers MUST
   NOT attempt to challenge CANCEL requests since these requests cannot
   be resubmitted.  Generally, a CANCEL request SHOULD be accepted by a
   server if it comes from the same hop that sent the request being
   canceled (provided that some sort of transport or network layer
   security association, as described in Section 26.2.1, is in place).

   When a UAC receives a challenge, it SHOULD render to the user the
   contents of the "realm" parameter in the challenge (which appears in
   either a WWW-Authenticate header field or Proxy-Authenticate header
   field) if the UAC device does not already know of a credential for
   the realm in question.  A service provider that pre-configures UAs
   with credentials for its realm should be aware that users will not
   have the opportunity to present their own credentials for this realm
   when challenged at a pre-configured device.

   Finally, note that even if a UAC can locate credentials that are
   associated with the proper realm, the potential exists that these
   credentials may no longer be valid or that the challenging server
   will not accept these credentials for whatever reason (especially
   when "anonymous" with no password is submitted).  In this instance a
   server may repeat its challenge, or it may respond with a 403
   Forbidden.  A UAC MUST NOT re-attempt requests with the credentials
   that have just been rejected (though the request may be retried if
   the nonce was stale).

22.2 User-to-User Authentication

   When a UAS receives a request from a UAC, the UAS MAY authenticate
   the originator before the request is processed.  If no credentials
   (in the Authorization header field) are provided in the request, the
   UAS can challenge the originator to provide credentials by rejecting
   the request with a 401 (Unauthorized) status code.

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages.  The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the realm.

   An example of the WWW-Authenticate header field in a 401 challenge
   is:

      WWW-Authenticate: Digest
              realm="biloxi.com",
              qop="auth,auth-int",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

   When the originating UAC receives the 401 (Unauthorized), it SHOULD,
   if it is able, re-originate the request with the proper credentials.
   The UAC may require input from the originating user before
   proceeding.  Once authentication credentials have been supplied
   (either directly by the user, or discovered in an internal keyring),
   UAs SHOULD cache the credentials for a given value of the To header
   field and "realm" and attempt to re-use these values on the next
   request for that destination.  UAs MAY cache credentials in any way
   they would like.

   If no credentials for a realm can be located, UACs MAY attempt to
   retry the request with a username of "anonymous" and no password (a
   password of "").

   Once credentials have been located, any UA that wishes to
   authenticate itself with a UAS or registrar -- usually, but not
   necessarily, after receiving a 401 (Unauthorized) response -- MAY do
   so by including an Authorization header field with the request.  The
   Authorization field value consists of credentials containing the
   authentication information of the UA for the realm of the resource
   being requested as well as parameters required in support of
   authentication and replay protection.

   An example of the Authorization header field is:

      Authorization: Digest username="bob",
              realm="biloxi.com",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              uri="sip:bob@biloxi.com",
              qop=auth,
              nc=00000001,
              cnonce="0a4f113b",
              response="6629fae49393a05397450978507c4ef1",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

   When a UAC resubmits a request with its credentials after receiving a
   401 (Unauthorized) or 407 (Proxy Authentication Required) response,
   it MUST increment the CSeq header field value as it would normally
   when sending an updated request.

22.3 Proxy-to-User Authentication

   Similarly, when a UAC sends a request to a proxy server, the proxy
   server MAY authenticate the originator before the request is
   processed.  If no credentials (in the Proxy-Authorization header
   field) are provided in the request, the proxy can challenge the
   originator to provide credentials by rejecting the request with a 407
   (Proxy Authentication Required) status code.  The proxy MUST populate
   the 407 (Proxy Authentication Required) message with a Proxy-
   Authenticate header field value applicable to the proxy for the
   requested resource.

   The use of Proxy-Authenticate and Proxy-Authorization parallel that
   described in [17], with one difference.  Proxies MUST NOT add values
   to the Proxy-Authorization header field.  All 407 (Proxy
   Authentication Required) responses MUST be forwarded upstream toward
   the UAC following the procedures for any other response.  It is the
   UAC's responsibility to add the Proxy-Authorization header field
   value containing credentials for the realm of the proxy that has
   asked for authentication.

      If a proxy were to resubmit a request adding a Proxy-Authorization
      header field value, it would need to increment the CSeq in the new
      request.  However, this would cause the UAC that submitted the
      original request to discard a response from the UAS, as the CSeq
      value would be different.

   When the originating UAC receives the 407 (Proxy Authentication
   Required) it SHOULD, if it is able, re-originate the request with the
   proper credentials.  It should follow the same procedures for the
   display of the "realm" parameter that are given above for responding
   to 401.

   If no credentials for a realm can be located, UACs MAY attempt to
   retry the request with a username of "anonymous" and no password (a
   password of "").

   The UAC SHOULD also cache the credentials used in the re-originated
   request.

   The following rule is RECOMMENDED for proxy credential caching:

   If a UA receives a Proxy-Authenticate header field value in a 401/407
   response to a request with a particular Call-ID, it should
   incorporate credentials for that realm in all subsequent requests
   that contain the same Call-ID.  These credentials MUST NOT be cached
   across dialogs; however, if a UA is configured with the realm of its
   local outbound proxy, when one exists, then the UA MAY cache

   credentials for that realm across dialogs.  Note that this does mean
   a future request in a dialog could contain credentials that are not
   needed by any proxy along the Route header path.

   Any UA that wishes to authenticate itself to a proxy server --
   usually, but not necessarily, after receiving a 407 (Proxy
   Authentication Required) response -- MAY do so by including a Proxy-
   Authorization header field value with the request.  The Proxy-
   Authorization request-header field allows the client to identify
   itself (or its user) to a proxy that requires authentication.  The
   Proxy-Authorization header field value consists of credentials
   containing the authentication information of the UA for the proxy
   and/or realm of the resource being requested.

   A Proxy-Authorization header field value applies only to the proxy
   whose realm is identified in the "realm" parameter (this proxy may
   previously have demanded authentication using the Proxy-Authenticate
   field).  When multiple proxies are used in a chain, a Proxy-
   Authorization header field value MUST NOT be consumed by any proxy
   whose realm does not match the "realm" parameter specified in that
   value.

   Note that if an authentication scheme that does not support realms is
   used in the Proxy-Authorization header field, a proxy server MUST
   attempt to parse all Proxy-Authorization header field values to
   determine whether one of them has what the proxy server considers to
   be valid credentials.  Because this is potentially very time-
   consuming in large networks, proxy servers SHOULD use an
   authentication scheme that supports realms in the Proxy-Authorization
   header field.

   If a request is forked (as described in Section 16.7), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.

      When a proxy server issues a challenge in response to a request,
      it will not proxy the request until the UAC has retried the
      request with valid credentials.  A forking proxy may forward a
      request simultaneously to multiple proxy servers that require
      authentication, each of which in turn will not forward the request
      until the originating UAC has authenticated itself in their
      respective realm.  If the UAC does not provide credentials for

      each challenge, the proxy servers that issued the challenges will
      not forward requests to the UA where the destination user might be
      located, and therefore, the virtues of forking are largely lost.

   When resubmitting its request in response to a 401 (Unauthorized) or
   407 (Proxy Authentication Required) that contains multiple
   challenges, a UAC MAY include an Authorization value for each WWW-
   Authenticate value and a Proxy-Authorization value for each Proxy-
   Authenticate value for which the UAC wishes to supply a credential.
   As noted above, multiple credentials in a request SHOULD be
   differentiated by the "realm" parameter.

   It is possible for multiple challenges associated with the same realm
   to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication
   Required).  This can occur, for example, when multiple proxies within
   the same administrative domain, which use a common realm, are reached
   by a forking request.  When it retries a request, a UAC MAY therefore
   supply multiple credentials in Authorization or Proxy-Authorization
   header fields with the same "realm" parameter value.  The same
   credentials SHOULD be used for the same realm.

22.4 The Digest Authentication Scheme

   This section describes the modifications and clarifications required
   to apply the HTTP Digest authentication scheme to SIP.  The SIP
   scheme usage is almost completely identical to that for HTTP [17].

   Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39],
   SIP servers supporting RFC 2617 MUST ensure they are backwards
   compatible with RFC 2069.  Procedures for this backwards
   compatibility are specified in RFC 2617.  Note, however, that SIP
   servers MUST NOT accept or request Basic authentication.

   The rules for Digest authentication follow those defined in [17],
   with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
   differences:

      1.  The URI included in the challenge has the following BNF:

          URI  =  SIP-URI / SIPS-URI

      2.  The BNF in RFC 2617 has an error in that the 'uri' parameter
          of the Authorization header field for HTTP Digest

          authentication is not enclosed in quotation marks.  (The
          example in Section 3.5 of RFC 2617 is correct.)  For SIP, the
          'uri' MUST be enclosed in quotation marks.

      3.  The BNF for digest-uri-value is:

          digest-uri-value  =  Request-URI ; as defined in Section 25

      4.  The example procedure for choosing a nonce based on Etag does
          not work for SIP.

      5.  The text in RFC 2617 [17] regarding cache operation does not
          apply to SIP.

      6.  RFC 2617 [17] requires that a server check that the URI in the
          request line and the URI included in the Authorization header
          field point to the same resource.  In a SIP context, these two
          URIs may refer to different users, due to forwarding at some
          proxy.  Therefore, in SIP, a server MAY check that the
          Request-URI in the Authorization header field value
          corresponds to a user for whom the server is willing to accept
          forwarded or direct requests, but it is not necessarily a
          failure if the two fields are not equivalent.

      7.  As a clarification to the calculation of the A2 value for
          message integrity assurance in the Digest authentication
          scheme, implementers should assume, when the entity-body is
          empty (that is, when SIP messages have no body) that the hash
          of the entity-body resolves to the MD5 hash of an empty
          string, or:

             H(entity-body) = MD5("") =
          "d41d8cd98f00b204e9800998ecf8427e"

      8.  RFC 2617 notes that a cnonce value MUST NOT be sent in an
          Authorization (and by extension Proxy-Authorization) header
          field if no qop directive has been sent.  Therefore, any
          algorithms that have a dependency on the cnonce (including
          "MD5-Sess") require that the qop directive be sent.  Use of
          the "qop" parameter is optional in RFC 2617 for the purposes
          of backwards compatibility with RFC 2069; since RFC 2543 was
          based on RFC 2069, the "qop" parameter must unfortunately
          remain optional for clients and servers to receive.  However,
          servers MUST always send a "qop" parameter in WWW-Authenticate
          and Proxy-Authenticate header field values.  If a client
          receives a "qop" parameter in a challenge header field, it
          MUST send the "qop" parameter in any resulting authorization
          header field.

   RFC 2543 did not allow usage of the Authentication-Info header field
   (it effectively used RFC 2069).  However, we now allow usage of this
   header field, since it provides integrity checks over the bodies and
   provides mutual authentication.  RFC 2617 [17] defines mechanisms for
   backwards compatibility using the qop attribute in the request.
   These mechanisms MUST be used by a server to determine if the client
   supports the new mechanisms in RFC 2617 that were not specified in
   RFC 2069.

23 S/MIME

   SIP messages carry MIME bodies and the MIME standard includes
   mechanisms for securing MIME contents to ensure both integrity and
   confidentiality (including the 'multipart/signed' and
   'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]
   and RFC 2633 [24]).  Implementers should note, however, that there
   may be rare network intermediaries (not typical proxy servers) that
   rely on viewing or modifying the bodies of SIP messages (especially
   SDP), and that secure MIME may prevent these sorts of intermediaries
   from functioning.

      This applies particularly to certain types of firewalls.

      The PGP mechanism for encrypting the header fields and bodies of
      SIP messages described in RFC 2543 has been deprecated.

23.1 S/MIME Certificates

   The certificates that are used to identify an end-user for the
   purposes of S/MIME differ from those used by servers in one important
   respect - rather than asserting that the identity of the holder
   corresponds to a particular hostname, these certificates assert that
   the holder is identified by an end-user address.  This address is
   composed of the concatenation of the "userinfo" "@" and "domainname"
   portions of a SIP or SIPS URI (in other words, an email address of
   the form "bob@biloxi.com"), most commonly corresponding to a user's
   address-of-record.

   These certificates are also associated with keys that are used to
   sign or encrypt bodies of SIP messages.  Bodies are signed with the
   private key of the sender (who may include their public key with the
   message as appropriate), but bodies are encrypted with the public key
   of the intended recipient.  Obviously, senders must have
   foreknowledge of the public key of recipients in order to encrypt
   message bodies.  Public keys can be stored within a UA on a virtual
   keyring.

   Each user agent that supports S/MIME MUST contain a keyring
   specifically for end-users' certificates.  This keyring should map
   between addresses of record and corresponding certificates.  Over
   time, users SHOULD use the same certificate when they populate the
   originating URI of signaling (the From header field) with the same
   address-of-record.

   Any mechanisms depending on the existence of end-user certificates
   are seriously limited in that there is virtually no consolidated
   authority today that provides certificates for end-user applications.
   However, users SHOULD acquire certificates from known public
   certificate authorities.  As an alternative, users MAY create self-
   signed certificates.  The implications of self-signed certificates
   are explored further in Section 26.4.2.  Implementations may also use
   pre-configured certificates in deployments in which a previous trust
   relationship exists between all SIP entities.

   Above and beyond the problem of acquiring an end-user certificate,
   there are few well-known centralized directories that distribute
   end-user certificates.  However, the holder of a certificate SHOULD
   publish their certificate in any public directories as appropriate.
   Similarly, UACs SHOULD support a mechanism for importing (manually or
   automatically) certificates discovered in public directories
   corresponding to the target URIs of SIP requests.

23.2 S/MIME Key Exchange

   SIP itself can also be used as a means to distribute public keys in
   the following manner.

   Whenever the CMS SignedData message is used in S/MIME for SIP, it
   MUST contain the certificate bearing the public key necessary to
   verify the signature.

   When a UAC sends a request containing an S/MIME body that initiates a
   dialog, or sends a non-INVITE request outside the context of a
   dialog, the UAC SHOULD structure the body as an S/MIME
   'multipart/signed' CMS SignedData body.  If the desired CMS service
   is EnvelopedData (and the public key of the target user is known),
   the UAC SHOULD send the EnvelopedData message encapsulated within a
   SignedData message.

   When a UAS receives a request containing an S/MIME CMS body that
   includes a certificate, the UAS SHOULD first validate the
   certificate, if possible, with any available root certificates for
   certificate authorities.  The UAS SHOULD also determine the subject
   of the certificate (for S/MIME, the SubjectAltName will contain the
   appropriate identity) and compare this value to the From header field

   of the request.  If the certificate cannot be verified, because it is
   self-signed, or signed by no known authority, or if it is verifiable
   but its subject does not correspond to the From header field of
   request, the UAS MUST notify its user of the status of the
   certificate (including the subject of the certificate, its signer,
   and any key fingerprint information) and request explicit permission
   before proceeding.  If the certificate was successfully verified and
   the subject of the certificate corresponds to the From header field
   of the SIP request, or if the user (after notification) explicitly
   authorizes the use of the certificate, the UAS SHOULD add this
   certificate to a local keyring, indexed by the address-of-record of
   the holder of the certificate.

   When a UAS sends a response containing an S/MIME body that answers
   the first request in a dialog, or a response to a non-INVITE request
   outside the context of a dialog, the UAS SHOULD structure the body as
   an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS
   service is EnvelopedData, the UAS SHOULD send the EnvelopedData
   message encapsulated within a SignedData message.

   When a UAC receives a response containing an S/MIME CMS body that
   includes a certificate, the UAC SHOULD first validate the
   certificate, if possible, with any appropriate root certificate.  The
   UAC SHOULD also determine the subject of the certificate and compare
   this value to the To field of the response; although the two may very
   well be different, and this is not necessarily indicative of a
   security breach.  If the certificate cannot be verified because it is
   self-signed, or signed by no known authority, the UAC MUST notify its
   user of the status of the certificate (including the subject of the
   certificate, its signator, and any key fingerprint information) and
   request explicit permission before proceeding.  If the certificate
   was successfully verified, and the subject of the certificate
   corresponds to the To header field in the response, or if the user
   (after notification) explicitly authorizes the use of the
   certificate, the UAC SHOULD add this certificate to a local keyring,
   indexed by the address-of-record of the holder of the certificate.
   If the UAC had not transmitted its own certificate to the UAS in any
   previous transaction, it SHOULD use a CMS SignedData body for its
   next request or response.

   On future occasions, when the UA receives requests or responses that
   contain a From header field corresponding to a value in its keyring,
   the UA SHOULD compare the certificate offered in these messages with
   the existing certificate in its keyring.  If there is a discrepancy,
   the UA MUST notify its user of a change of the certificate
   (preferably in terms that indicate that this is a potential security
   breach) and acquire the user's permission before continuing to

   process the signaling.  If the user authorizes this certificate, it
   SHOULD be added to the keyring alongside any previous value(s) for
   this address-of-record.

   Note well however, that this key exchange mechanism does not
   guarantee the secure exchange of keys when self-signed certificates,
   or certificates signed by an obscure authority, are used - it is
   vulnerable to well-known attacks.  In the opinion of the authors,
   however, the security it provides is proverbially better than
   nothing; it is in fact comparable to the widely used SSH application.
   These limitations are explored in greater detail in Section 26.4.2.

   If a UA receives an S/MIME body that has been encrypted with a public
   key unknown to the recipient, it MUST reject the request with a 493
   (Undecipherable) response.  This response SHOULD contain a valid
   certificate for the respondent (corresponding, if possible, to any
   address of record given in the To header field of the rejected
   request) within a MIME body with a 'certs-only' "smime-type"
   parameter.

   A 493 (Undecipherable) sent without any certificate indicates that
   the respondent cannot or will not utilize S/MIME encrypted messages,
   though they may still support S/MIME signatures.

   Note that a user agent that receives a request containing an S/MIME
   body that is not optional (with a Content-Disposition header
   "handling" parameter of "required") MUST reject the request with a
   415 Unsupported Media Type response if the MIME type is not
   understood.  A user agent that receives such a response when S/MIME
   is sent SHOULD notify its user that the remote device does not
   support S/MIME, and it MAY subsequently resend the request without
   S/MIME, if appropriate; however, this 415 response may constitute a
   downgrade attack.

   If a user agent sends an S/MIME body in a request, but receives a
   response that contains a MIME body that is not secured, the UAC
   SHOULD notify its user that the session could not be secured.
   However, if a user agent that supports S/MIME receives a request with
   an unsecured body, it SHOULD NOT respond with a secured body, but if
   it expects S/MIME from the sender (for example, because the sender's
   From header field value corresponds to an identity on its keychain),
   the UAS SHOULD notify its user that the session could not be secured.

   A number of conditions that arise in the previous text call for the
   notification of the user when an anomalous certificate-management
   event occurs.  Users might well ask what they should do under these
   circumstances.  First and foremost, an unexpected change in a
   certificate, or an absence of security when security is expected, are

   causes for caution but not necessarily indications that an attack is
   in progress.  Users might abort any connection attempt or refuse a
   connection request they have received; in telephony parlance, they
   could hang up and call back.  Users may wish to find an alternate
   means to contact the other party and confirm that their key has
   legitimately changed.  Note that users are sometimes compelled to
   change their certificates, for example when they suspect that the
   secrecy of their private key has been compromised.  When their
   private key is no longer private, users must legitimately generate a
   new key and re-establish trust with any users that held their old
   key.

   Finally, if during the course of a dialog a UA receives a certificate
   in a CMS SignedData message that does not correspond with the
   certificates previously exchanged during a dialog, the UA MUST notify
   its user of the change, preferably in terms that indicate that this
   is a potential security breach.

23.3 Securing MIME bodies

   There are two types of secure MIME bodies that are of interest to
   SIP: use of these bodies should follow the S/MIME specification [24]
   with a few variations.

      o  "multipart/signed" MUST be used only with CMS detached
         signatures.

            This allows backwards compatibility with non-S/MIME-
            compliant recipients.

      o  S/MIME bodies SHOULD have a Content-Disposition header field,
         and the value of the "handling" parameter SHOULD be "required."

      o  If a UAC has no certificate on its keyring associated with the
         address-of-record to which it wants to send a request, it
         cannot send an encrypted "application/pkcs7-mime" MIME message.
         UACs MAY send an initial request such as an OPTIONS message
         with a CMS detached signature in order to solicit the
         certificate of the remote side (the signature SHOULD be over a
         "message/sip" body of the type described in Section 23.4).

            Note that future standardization work on S/MIME may define
            non-certificate based keys.

      o  Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"
         (see Section 2.5.2 of [24]) attribute to express their
         capabilities and preferences for further communications.  Note
         especially that senders MAY use the "preferSignedData"

         capability to encourage receivers to respond with CMS
         SignedData messages (for example, when sending an OPTIONS
         request as described above).

      o  S/MIME implementations MUST at a minimum support SHA1 as a
         digital signature algorithm, and 3DES as an encryption
         algorithm.  All other signature and encryption algorithms MAY
         be supported.  Implementations can negotiate support for these
         algorithms with the "SMIMECapabilities" attribute.
         → RFC 3853, Section 3

      o  Each S/MIME body in a SIP message SHOULD be signed with only
         one certificate.  If a UA receives a message with multiple
         signatures, the outermost signature should be treated as the
         single certificate for this body.  Parallel signatures SHOULD
         NOT be used.

         The following is an example of an encrypted S/MIME SDP body
         within a SIP message:

        INVITE sip:bob@biloxi.com SIP/2.0
        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
        To: Bob <sip:bob@biloxi.com>
        From: Alice <sip:alice@atlanta.com>;tag=1928301774
        Call-ID: a84b4c76e66710
        CSeq: 314159 INVITE
        Max-Forwards: 70
        Contact: <sip:alice@pc33.atlanta.com>
        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
             name=smime.p7m
        Content-Disposition: attachment; filename=smime.p7m;
           handling=required

      *******************************************************
      * Content-Type: application/sdp                       *
      *                                                     *
      * v=0                                                 *
      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
      * s=-                                                 *
      * t=0 0                                               *
      * c=IN IP4 pc33.atlanta.com                           *
      * m=audio 3456 RTP/AVP 0 1 3 99                       *
      * a=rtpmap:0 PCMU/8000                                *
      *******************************************************

23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP

   As a means of providing some degree of end-to-end authentication,
   integrity or confidentiality for SIP header fields, S/MIME can
   encapsulate entire SIP messages within MIME bodies of type
   "message/sip" and then apply MIME security to these bodies in the
   same manner as typical SIP bodies.  These encapsulated SIP requests
   and responses do not constitute a separate dialog or transaction,
   they are a copy of the "outer" message that is used to verify
   integrity or to supply additional information.

   If a UAS receives a request that contains a tunneled "message/sip"
   S/MIME body, it SHOULD include a tunneled "message/sip" body in the
   response with the same smime-type.

   Any traditional MIME bodies (such as SDP) SHOULD be attached to the
   "inner" message so that they can also benefit from S/MIME security.
   Note that "message/sip" bodies can be sent as a part of a MIME
   "multipart/mixed" body if any unsecured MIME types should also be
   transmitted in a request.

23.4.1 Integrity and Confidentiality Properties of SIP Headers

   When the S/MIME integrity or confidentiality mechanisms are used,
   there may be discrepancies between the values in the "inner" message
   and values in the "outer" message.  The rules for handling any such
   differences for all of the header fields described in this document
   are given in this section.

   Note that for the purposes of loose timestamping, all SIP messages
   that tunnel "message/sip" SHOULD contain a Date header in both the
   "inner" and "outer" headers.

23.4.1.1 Integrity

   Whenever integrity checks are performed, the integrity of a header
   field should be determined by matching the value of the header field
   in the signed body with that in the "outer" messages using the
   comparison rules of SIP as described in 20.

   Header fields that can be legitimately modified by proxy servers are:
   Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
   Authorization.  If these header fields are not intact end-to-end,
   implementations SHOULD NOT consider this a breach of security.
   Changes to any other header fields defined in this document
   constitute an integrity violation; users MUST be notified of a
   discrepancy.

23.4.1.2 Confidentiality

   When messages are encrypted, header fields may be included in the
   encrypted body that are not present in the "outer" message.

   Some header fields must always have a plaintext version because they
   are required header fields in requests and responses - these include:

   To, From, Call-ID, CSeq, Contact.  While it is probably not useful to
   provide an encrypted alternative for the Call-ID, CSeq, or Contact,
   providing an alternative to the information in the "outer" To or From
   is permitted.  Note that the values in an encrypted body are not used
   for the purposes of identifying transactions or dialogs - they are
   merely informational.  If the From header field in an encrypted body
   differs from the value in the "outer" message, the value within the
   encrypted body SHOULD be displayed to the user, but MUST NOT be used
   in the "outer" header fields of any future messages.

   Primarily, a user agent will want to encrypt header fields that have
   an end-to-end semantic, including: Subject, Reply-To, Organization,
   Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,
   Authentication-Info, Expires, In-Reply-To, Require, Supported,
   Unsupported, Retry-After, User-Agent, Server, and Warning.  If any of
   these header fields are present in an encrypted body, they should be
   used instead of any "outer" header fields, whether this entails
   displaying the header field values to users or setting internal
   states in the UA.  They SHOULD NOT however be used in the "outer"
   headers of any future messages.

   If present, the Date header field MUST always be the same in the
   "inner" and "outer" headers.

   Since MIME bodies are attached to the "inner" message,
   implementations will usually encrypt MIME-specific header fields,
   including: MIME-Version, Content-Type, Content-Length, Content-
   Language, Content-Encoding and Content-Disposition.  The "outer"
   message will have the proper MIME header fields for S/MIME bodies.
   These header fields (and any MIME bodies they preface) should be
   treated as normal MIME header fields and bodies received in a SIP
   message.

   It is not particularly useful to encrypt the following header fields:
   Min-Expires, Timestamp, Authorization, Priority, and WWW-
   Authenticate.  This category also includes those header fields that
   can be changed by proxy servers (described in the preceding section).
   UAs SHOULD never include these in an "inner" message if they are not

   included in the "outer" message.  UAs that receive any of these
   header fields in an encrypted body SHOULD ignore the encrypted
   values.

   Note that extensions to SIP may define additional header fields; the
   authors of these extensions should describe the integrity and
   confidentiality properties of such header fields.  If a SIP UA
   encounters an unknown header field with an integrity violation, it
   MUST ignore the header field.

23.4.2 Tunneling Integrity and Authentication

   Tunneling SIP messages within S/MIME bodies can provide integrity for
   SIP header fields if the header fields that the sender wishes to
   secure are replicated in a "message/sip" MIME body signed with a CMS
   detached signature.

   Provided that the "message/sip" body contains at least the
   fundamental dialog identifiers (To, From, Call-ID, CSeq), then a
   signed MIME body can provide limited authentication.  At the very
   least, if the certificate used to sign the body is unknown to the
   recipient and cannot be verified, the signature can be used to
   ascertain that a later request in a dialog was transmitted by the
   same certificate-holder that initiated the dialog.  If the recipient
   of the signed MIME body has some stronger incentive to trust the
   certificate (they were able to validate it, they acquired it from a
   trusted repository, or they have used it frequently) then the
   signature can be taken as a stronger assertion of the identity of the
   subject of the certificate.

   In order to eliminate possible confusions about the addition or
   subtraction of entire header fields, senders SHOULD replicate all
   header fields from the request within the signed body.  Any message
   bodies that require integrity protection MUST be attached to the
   "inner" message.

   If a Date header is present in a message with a signed body, the
   recipient SHOULD compare the header field value with its own internal
   clock, if applicable.  If a significant time discrepancy is detected
   (on the order of an hour or more), the user agent SHOULD alert the
   user to the anomaly, and note that it is a potential security breach.

   If an integrity violation in a message is detected by its recipient,
   the message MAY be rejected with a 403 (Forbidden) response if it is
   a request, or any existing dialog MAY be terminated.  UAs SHOULD
   notify users of this circumstance and request explicit guidance on
   how to proceed.

   The following is an example of the use of a tunneled "message/sip"
   body:

      INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
      To: Bob <sip:bob@biloxi.com>
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 314159 INVITE
      Max-Forwards: 70
      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: multipart/signed;
        protocol="application/pkcs7-signature";
        micalg=sha1; boundary=boundary42
      Content-Length: 568

      --boundary42
      Content-Type: message/sip

      INVITE sip:bob@biloxi.com SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
      To: Bob <bob@biloxi.com>
      From: Alice <alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710
      CSeq: 314159 INVITE
      Max-Forwards: 70
      Date: Thu, 21 Feb 2002 13:02:03 GMT
      Contact: <sip:alice@pc33.atlanta.com>
      Content-Type: application/sdp
      Content-Length: 147

      v=0
      o=UserA 2890844526 2890844526 IN IP4 here.com
      s=Session SDP
      c=IN IP4 pc33.atlanta.com
      t=0 0
      m=audio 49172 RTP/AVP 0
      a=rtpmap:0 PCMU/8000

      --boundary42
      Content-Type: application/pkcs7-signature; name=smime.p7s
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p7s;
         handling=required

      ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
      4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
      n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
      7GhIGfHfYT64VQbnj756

      --boundary42--

23.4.3 Tunneling Encryption

   It may also be desirable to use this mechanism to encrypt a
   "message/sip" MIME body within a CMS EnvelopedData message S/MIME
   body, but in practice, most header fields are of at least some use to
   the network; the general use of encryption with S/MIME is to secure
   message bodies like SDP rather than message headers.  Some
   informational header fields, such as the Subject or Organization
   could perhaps warrant end-to-end security.  Headers defined by future
   SIP applications might also require obfuscation.

   Another possible application of encrypting header fields is selective
   anonymity.  A request could be constructed with a From header field
   that contains no personal information (for example,
   sip:anonymous@anonymizer.invalid).  However, a second From header
   field containing the genuine address-of-record of the originator
   could be encrypted within a "message/sip" MIME body where it will
   only be visible to the endpoints of a dialog.

      Note that if this mechanism is used for anonymity, the From header
      field will no longer be usable by the recipient of a message as an
      index to their certificate keychain for retrieving the proper
      S/MIME key to associated with the sender.  The message must first
      be decrypted, and the "inner" From header field MUST be used as an
      index.

   In order to provide end-to-end integrity, encrypted "message/sip"
   MIME bodies SHOULD be signed by the sender.  This creates a
   "multipart/signed" MIME body that contains an encrypted body and a
   signature, both of type "application/pkcs7-mime".

   In the following example, of an encrypted and signed message, the
   text boxed in asterisks ("*") is encrypted:

        INVITE sip:bob@biloxi.com SIP/2.0
        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
        To: Bob <sip:bob@biloxi.com>
        From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
        Call-ID: a84b4c76e66710
        CSeq: 314159 INVITE
        Max-Forwards: 70
        Date: Thu, 21 Feb 2002 13:02:03 GMT
        Contact: <sip:pc33.atlanta.com>
        Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42
        Content-Length: 568

        --boundary42
        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
             name=smime.p7m
        Content-Transfer-Encoding: base64
        Content-Disposition: attachment; filename=smime.p7m
           handling=required

      ***********************************************************
      * Content-Type: message/sip                               *
      *                                                         *
      * INVITE sip:bob@biloxi.com SIP/2.0                       *
      * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
      * To: Bob <bob@biloxi.com>                                *
      * From: Alice <alice@atlanta.com>;tag=1928301774          *
      * Call-ID: a84b4c76e66710                                 *
      * CSeq: 314159 INVITE                                     *
      * Max-Forwards: 70                                        *
      * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
      * Contact: <sip:alice@pc33.atlanta.com>                   *
      *                                                         *
      * Content-Type: application/sdp                           *
      *                                                         *
      * v=0                                                     *
      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com     *
      * s=Session SDP                                           *
      * t=0 0                                                   *
      * c=IN IP4 pc33.atlanta.com                               *
      * m=audio 3456 RTP/AVP 0 1 3 99                           *
      * a=rtpmap:0 PCMU/8000                                    *
      ***********************************************************

        --boundary42
        Content-Type: application/pkcs7-signature; name=smime.p7s
        Content-Transfer-Encoding: base64
        Content-Disposition: attachment; filename=smime.p7s;
           handling=required

        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756

        --boundary42-