tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5630

Proposed STD
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIP

The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Part 1 of 3, p. 1 to 13
None       Next RFC Part

Updates:    3261    3608


Top       ToC       Page 1 
Network Working Group                                           F. Audet
Request for Comments: 5630                                    Skype Labs
Updates: 3261, 3608                                         October 2009
Category: Standards Track


The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Abstract

   This document provides clarifications and guidelines concerning the
   use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
   It also makes normative changes to SIP.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright and License Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Background ......................................................3
      3.1. Models for Using TLS in SIP ................................3
           3.1.1. Server-Provided Certificate .........................3
           3.1.2. Mutual Authentication ...............................4
           3.1.3. Using TLS with SIP Instead of SIPS ..................4
           3.1.4. Usage of the transport=tls URI Parameter and
                  the TLS Via Parameter ...............................5
      3.2. Detection of Hop-by-Hop Security ...........................6
      3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7
   4. Overview of Operations ..........................................9
      4.1. Routing ...................................................11
   5. Normative Requirements .........................................13
      5.1. General User Agent Behavior ...............................13
           5.1.1. UAC Behavior .......................................13
                  5.1.1.1. Registration ..............................14
                  5.1.1.2. SIPS in a Dialog ..........................15
                  5.1.1.3. Derived Dialogs and Transactions ..........15
                  5.1.1.4. GRUU ......................................16
           5.1.2. UAS Behavior .......................................17
      5.2. Registrar Behavior ........................................18
           5.2.1. GRUU ...............................................18
      5.3. Proxy Behavior ............................................18
      5.4. Redirect Server Behavior ..................................20
   6. Call Flows .....................................................21
      6.1. Bob Registers His Contacts ................................22
      6.2. Alice Calls Bob's SIPS AOR ................................27
      6.3. Alice Calls Bob's SIP AOR Using TCP .......................36
      6.4. Alice Calls Bob's SIP AOR Using TLS .......................50
   7. Further Considerations .........................................51
   8. Security Considerations ........................................52
   9. IANA Considerations ............................................52
   10. Acknowledgments ...............................................52
   11. References ....................................................53
      11.1. Normative References .....................................53
      11.2. Informative References ...................................53
   Appendix A.  Bug Fixes for RFC 3261  ..............................55

Top      ToC       Page 3 
1.  Introduction

   The meaning and usage of the SIPS URI scheme and of Transport Layer
   Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have
   been a source of confusion for implementers.

   This document provides clarifications and guidelines concerning the
   use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
   It also makes normative changes to SIP (including both [RFC3261] and
   [RFC3608].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Background

3.1.  Models for Using TLS in SIP

   This section describes briefly the usage of TLS in SIP.

3.1.1.  Server-Provided Certificate

   In this model, only the TLS server provides a certificate during the
   TLS handshake.  This is applicable only between a user agent (UA) and
   a proxy, where the UA is the TLS client and the proxy is the TLS
   server, and hence the UA uses TLS to authenticate the proxy but the
   proxy does not use TLS to authenticate the UA.  If the proxy needs to
   authenticate the UA, this can be achieved by SIP HTTP digest
   authentication.  This directionality implies that the TLS connection
   always needs to be set up by the UA (e.g., during the registration
   phase).  Since SIP allows for requests in both directions (e.g., an
   incoming call), the UA is expected to keep the TLS connection alive,
   and that connection is expected to be reused for both incoming and
   outgoing requests.

   This solution of having the UA always initiate and keep alive the
   connection also solves the Network Address Translation (NAT) and
   firewall problem as it ensures that responses and further requests
   will always be deliverable on the existing connection.

   [RFC5626] provides the mechanism for initiating and maintaining
   outbound connections in a standard interoperable way.

Top      ToC       Page 4 
3.1.2.  Mutual Authentication

   In this model, both the TLS client and the TLS server provide a
   certificate in the TLS handshake phase.  When used between a UA and a
   proxy (or between two UAs), this implies that a UA is in possession
   of a certificate.  When sending a SIP request when there is not
   already a suitable TLS connection in place, a user agent client (UAC)
   takes on the role of TLS client in establishing a new TLS connection.
   When establishing a TLS connection for receipt of a SIP request, a
   user agent server (UAS) takes on the role of TLS server.  Because in
   SIP a UA or a proxy acts both as UAC and UAS depending on if it is
   sending or receiving requests, the symmetrical nature of mutual TLS
   is very convenient.  This allows for TLS connections to be set up or
   torn down at will and does not rely on keeping the TLS connection
   alive for further requests.

   However, there are some significant limitations.

   The first obvious limitation is not with mutual authentication per
   se, but with the model where the underlying TCP connection can be
   established by either side, interchangeably, which is not possible in
   many environments.  For examples, NATs and firewalls will often allow
   TCP connections to be established in one direction only.  This
   includes most residential SIP deployments, for example.  Mutual
   authentication can be used in those environments, but only if the
   connection is always started by the same side, for example, by using
   [RFC5626] as described in Section 3.1.1.  Having to rely on [RFC5626]
   in this case negates many of the advantages of mutual authentication.

   The second significant limitation is that mutual authentication
   requires both sides to exchange a certificate.  This has proven to be
   impractical in many environments, in particular for SIP UAs, because
   of the difficulties of setting up a certificate infrastructure for a
   wide population of users.

   For these reasons, mutual authentication is mostly used in server-to-
   server communications (e.g., between SIP proxies, or between proxies
   and gateways or media servers), and in environments where using
   certificates on both sides is possible (e.g., high-security devices
   used within an enterprise).

3.1.3.  Using TLS with SIP Instead of SIPS

   Because a SIPS URI implies that requests sent to the resource
   identified by it be sent over each SIP hop over TLS, SIPS URIs are
   not suitable for "best-effort TLS": they are only suitable for "TLS-
   only" requests.  This is recognized in Section 26.2.2 of [RFC3261].

Top      ToC       Page 5 
      Users that distribute a SIPS URI as an address-of-record may elect
      to operate devices that refuse requests over insecure transports.

   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

   Using SIP over TLS is very simple.  A UA opens a TLS connection and
   uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   When TLS is used, the Via header field indicates TLS.

   [RFC3261], Section 26.3.2.1, states:

      When a UA comes online and registers with its local administrative
      domain, it SHOULD establish a TLS connection with its registrar
      (...).  Once the registration has been accepted by the registrar,
      the UA SHOULD leave this TLS connection open provided that the
      registrar also acts as the proxy server to which requests are sent
      for users in this administrative domain.  The existing TLS
      connection will be reused to deliver incoming requests to the UA
      that had just completed registration.

   [RFC5626] describes how to establish and maintain a TLS connection in
   environments where it can only be initiated by the UA.

   Similarly, proxies can forward requests using TLS if they can open a
   TLS connection, even if the route set used SIP URIs instead of SIPS
   URIs.  The proxies can insert Record-Route header fields using SIP
   URIs even if it uses TLS transport.  [RFC3261], Section 26.3.2.2,
   explains how interdomain requests can use TLS.

   Some user agents, redirect servers, and proxies might have local
   policies that enforce TLS on all connections, independently of
   whether or not SIPS is used.

3.1.4.  Usage of the transport=tls URI Parameter and the TLS Via
        Parameter

   [RFC3261], Section 26.2.2 deprecated the "transport=tls" URI
   transport parameter in SIPS or SIP URIs:

      Note that in the SIPS URI scheme, transport is independent of TLS,
      and thus "sips:alice@atlanta.com;transport=TCP" and
      "sips:alice@atlanta.com;transport=sctp" are both valid (although
      note that UDP is not a valid transport for SIPS).  The use of
      "transport=tls" has consequently been deprecated, partly because
      it was specific to a single hop of the request.  This is a change
      since RFC 2543.

Top      ToC       Page 6 
   The "tls" parameter has not been eliminated from the ABNF in
   [RFC3261], Section 25, since the parameter needs to remain in the
   ABNF for backward compatibility in order for parsers to be able to
   process the parameter correctly.  The transport=tls parameter has
   never been defined in an RFC, but only in some of the Internet drafts
   between [RFC2543] and [RFC3261].

   This specification does not make use of the transport=tls parameter.

   The reinstatement of the transport=tls parameter, or an alternative
   mechanism for indicating the use of the TLS on a single hop in a URI,
   is outside the scope of this specification.

   For Via header fields, the following transport protocols are defined
   in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-
   SCTP".

3.2.  Detection of Hop-by-Hop Security

   The presence of a SIPS Request-URI does not necessarily indicate that
   the request was sent securely on each hop.  So how does a UAS know if
   SIPS was used for the entire request path to secure the request end-
   to-end?  Effectively, the UAS cannot know for sure.  However,
   [RFC3261], Section 26.4.4, recommends how a UAS can make some checks
   to validate the security.  Additionally, the History-Info header
   field [RFC4244] could be inspected for detecting retargeting from SIP
   and SIPS.  Retargeting from SIP to SIPS by a proxy is an issue
   because it can leave the receiver of the request with the impression
   that the request was delivered securely on each hop, while in fact,
   it was not.

   To emphasize, all the checking can be circumvented by any proxies or
   back-to-back user agents (B2BUAs) on the path that do not follow the
   rules and recommendations of this specification and of [RFC3261].

   Proxies can have their own policies regarding routing of requests to
   SIP or SIPS URIs.  For example, some proxies in some environments can
   be configured to only route SIPS URIs.  Some proxies can be
   configured to detect non-compliances and reject unsecure requests.
   For example, proxies could inspect Request-URIs, Path, Record-Route,
   To, From, Contact header fields, and Via header fields to enforce
   SIPS.

   [RFC3261], Section 26.4.4, explains that S/MIME can also be used by
   the originating UAC to ensure that the original form of the To header
   field is carried end-to-end.  While not specifically mentioned in
   [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893]
   would be used to "tunnel" important header fields (such as To and

Top      ToC       Page 7 
   From) in an encrypted and signed S/MIME body, replicating the
   information in the SIP message, and allowing the UAS to validate the
   content of those important header fields.  While this approach is
   certainly legal, a preferable approach is to use the SIP Identity
   mechanism defined in [RFC4474].  SIP Identity creates a signed
   identity digest, which includes, among other things, the Address of
   Record (AOR) of the sender (from the From header field) and the AOR
   of the original target (from the To header field).

3.3.  The Problems with the Meaning of SIPS in RFC 3261

   [RFC3261], Section 19.1, describes a SIPS URI as follows:

      A SIPS URI specifies that the resource be contacted securely.
      This means, in particular, that TLS is to be used between the UAC
      and the domain that owns the URI.  From there, secure
      communications are used to reach the user, where the specific
      security mechanism depends on the policy of the domain.

   Section 26.2.2 re-iterates it, with regards to Request-URIs:

      When used as the Request-URI of a request, the SIPS scheme
      signifies that each hop over which the request is forwarded, until
      the request reaches the SIP entity responsible for the domain
      portion of the Request-URI, must be secured with TLS; once it
      reaches the domain in question it is handled in accordance with
      local security and routing policy, quite possibly using TLS for
      any last hop to a UAS.  When used by the originator of a request
      (as would be the case if they employed a SIPS URI as the address-
      of-record of the target), SIPS dictates that the entire request
      path to the target domain be so secured.

   Let's take the classic SIP trapezoid to explain the meaning of a
   sips:b@B URI.  Instead of using real domain names like example.com
   and example.net, logical names like "A" and "B" are used, for
   clarity.

Top      ToC       Page 8 
        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | Proxy |-----TLS---- | Proxy |               .
        .              |   A   | .         . |  B    |               .
        .              |       | .         . |       |               .
        .            / +-------+ .         . +-------+ \             .
        .           /            .         .            \            .
        .          /             .         .             \           .
        .        TLS             .         .        Policy-based     .
        .        /               .         .               \         .
        .       /                .         .                \        .
        .      /                 .         .                 \       .
        .   +-------+            .         .              +-------+  .
        .   |       |            .         .              |       |  .
        .   | UAC a |            .         .              | UAS b |  .
        .   |       |            .         .              |       |  .
        .   +-------+            .         .              +-------+  .
        .             Domain A   .         .   Domain B              .
        ..........................         ...........................

                   SIP trapezoid with last-hop exception

   According to [RFC3261], if a@A is sending a request to sips:b@B, the
   following applies:

   o  TLS is required between UA a@A and Proxy A

   o  TLS is required between Proxy A and Proxy B

   o  TLS is required between Proxy B and UA b@B, depending on local
      policy.

   One can then wonder why TLS is mandatory between UA a@A and Proxy A
   but not between Proxy B and UA b@B.  The main reason is that
   [RFC3261] was written before [RFC5626].  At that time, it was
   recognized that in many practical deployments, Proxy B might not be
   able to establish a TLS connection with UA b because only Proxy B
   would have a certificate to provide and UA b would not.  Since UA b
   would be the TLS server, it would then not be able to accept the
   incoming TLS connection.  The consequence is that an [RFC3261]-
   compliant UAS b, while it might not need to support TLS for incoming
   requests, will nevertheless have to support TLS for outgoing requests
   as it takes the UAC role.  Contrary to what many believed
   erroneously, the last-hop exception was not created to allow for
   using a SIPS URI to address a UAS that does not support TLS: the
   last-hop exception was an attempt to allow for incoming requests to

Top      ToC       Page 9 
   not be transported over TLS when a SIPS URI is used, and it does not
   apply to outgoing requests.  The rationale for this was somewhat
   flawed, and since then, [RFC5626] has provided a more satisfactory
   solution to this problem.  [RFC5626] also solves the problem that if
   UA b is behind a NAT or firewall, Proxy B would not even be able to
   establish a TCP session in the first place.

   Furthermore, consider the problem of using SIPS inside a dialog.  If
   a@A sends a request to b@B using a SIPS Request-URI, then, according
   to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain
   a SIPS URI as well".  This means that b@B, upon sending a new Request
   within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS
   URI.  If there is no Record-Route entry, or if the last Record-Route
   entry consists of a SIPS URI, this implies that b@B is expected to
   understand SIPS in the first place, and is required to also support
   TLS.  If the last Record-Route entry however is a sip URI, then b
   would be able to send requests without using TLS (but b would still
   have to be able to handle SIPS schemes when parsing the message).  In
   either case, the Request-URI in the request from b@B to B would be a
   SIPS URI.

4.  Overview of Operations

   Because of all the problems described in Section 3.3, this
   specification deprecates the last-hop exception when forwarding a
   request to the last hop (see Section 5.3).  This will ensure that TLS
   is used on all hops all the way up to the remote target.

Top      ToC       Page 10 
        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | Proxy |-----TLS---- | Proxy |               .
        .              |   A   | .         . |  B    |               .
        .              |       | .         . |       |               .
        .            / +-------+ .         . +-------+ \             .
        .           /            .         .            \            .
        .          /             .         .             \           .
        .        TLS             .         .             TLS         .
        .        /               .         .               \         .
        .       /                .         .                \        .
        .      /                 .         .                 \       .
        .   +-------+            .         .              +-------+  .
        .   |       |            .         .              |       |  .
        .   | UAC a |            .         .              | UAS b |  .
        .   |       |            .         .              |       |  .
        .   +-------+            .         .              +-------+  .
        .             Domain A   .         .   Domain B              .
        ..........................         ...........................

                 SIP trapezoid without last-hop exception

   The SIPS scheme implies transitive trust.  Obviously, there is
   nothing that prevents proxies from cheating (see [RFC3261], Section
   26.4.4).  While SIPS is useful to request that a resource be
   contacted securely, it is not useful as an indication that a resource
   was in fact contacted securely.  Therefore, it is not appropriate to
   infer that because an incoming request had a Request-URI (or even a
   To header field) containing a SIPS URI, that it necessarily
   guarantees that the request was in fact transmitted securely on each
   hop.  Some have been tempted to believe that the SIPS scheme was
   equivalent to an HTTPS scheme in the sense that one could provide a
   visual indication to a user (e.g., a padlock icon) to the effect that
   the session is secured.  This is obviously not the case, and
   therefore the meaning of a SIPS URI is not to be oversold.  There is
   currently no mechanism to provide an indication of end-to-end
   security for SIP.  Other mechanisms can provide a more concrete
   indication of some level of security.  For example, SIP Identity
   [RFC4474] provides an authenticated identity mechanism and a domain-
   to-domain integrity protection mechanism.

   Some have asked why is SIPS useful in a global open environment such
   as the Internet, if (when used in a Request-URI) it is not an
   absolute guarantee that the request will in fact be delivered over
   TLS on each hop?  Why is SIPS any different from just using TLS
   transport with SIP?  The difference is that using a SIPS URI in a

Top      ToC       Page 11 
   Request-URI means that if you are instructing the network to use TLS
   over each hop and if it is not possible to reject the request, you
   would rather have the request fail than have the request delivered
   without TLS.  Just using TLS with a SIP Request-URI instead of a SIPS
   Request-URI implies a "best-effort" service: the request can but need
   not be delivered over TLS on each hop.

   Another common question is why not have a Proxy-Require and Require
   option tag forcing the use of TLS instead?  The answer is that it
   would only be functionally equivalent to using SIPS in a Request-URI.
   SIPS URIs however can be used in many other header fields: in Contact
   for registration, Contact in dialog-creating requests, Route, Record-
   Route, Path, From, To, Refer-To, Referred-By, etc.  SIPS URIs can
   also be used in human-usable format (e.g., business cards, user
   interface).  SIPS URIs can even be used in other protocols or
   document formats that allow for including SIPS URIs (e.g., HTML).

   This document specifies that SIPS means that the SIP resource
   designated by the target SIPS URI is to be contacted securely, using
   TLS on each hop between the UAC and the remote UAS (as opposed to
   only to the proxy responsible for the target domain of the Request-
   URI).  It is outside of the scope of this document to specify what
   happens when a SIPS URI identifies a UAS resource that "maps" outside
   the SIP network, for example, to other networks such as the Public
   Switched Telephone Network (PSTN).

4.1.  Routing

   SIP and SIPS URIs that are identical except for the scheme itself
   (e.g., sip:alice@example.com and sips:alice@example.com) refer to the
   same resource.  This requirement is implicit in [RFC3261], Section
   19.1, which states that "any resource described by a SIP URI can be
   'upgraded' to a SIPS URI by just changing the scheme, if it is
   desired to communicate with that resource securely".  This does not
   mean that the SIPS URI will necessarily be reachable, in particular,
   if the proxy cannot establish a secure connection to a client or
   another proxy.  This does not suggest either that proxies would
   arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request
   (see Section 5.3).  Rather, it means that when a resource is
   addressable with SIP, it will also be addressable with SIPS.

   For example, consider the case of a UA that has registered with a
   SIPS Contact header field.  If a UAC later addresses a request using
   a SIP Request-URI, the proxy will forward the request addressed to a
   SIP Request-URI to the UAS, as illustrated by message F13 in Sections
   6.3 and in 6.4.  The proxy forwards the request to the UA using a SIP
   Request-URI and not the SIPS Request-URI used in registration.  The
   proxy does this by replacing the SIPS scheme that was used in the

Top      ToC       Page 12 
   registered Contact header field binding with a SIP scheme while
   leaving the rest of the URI as is, and then by using this new URI as
   the Request-URI.  If the proxy did not do this, and instead used a
   SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would
   have to include a SIPS Contact header field.  That SIPS Contact
   header field would then force the other UA to use a SIPS Contact
   header field in any mid-dialog request, including the ACK (which
   would not be possible if that UA did not support SIPS).

   This specification mandates that when a proxy is forwarding a
   request, a resource described by a SIPS Request-URI cannot be
   "downgraded" to a SIP URI by changing the scheme, or by sending the
   associated request over a nonsecure link.  If a request needs to be
   rejected because otherwise it would be a "downgrade", the request
   would be rejected with a 480 (Temporarily Unavailable) response
   (potentially with a Warning header with warn-code 380 "SIPS Not
   Allowed").  Similarly, this specification mandates that when a proxy
   is forwarding a request, a resource described by a SIP Request-URI
   cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise
   it would be an "upgrade" only for that hop onwards rather than on all
   hops, and would therefore mislead the UAS).  If a request needs to be
   rejected because otherwise it would be a misleading "upgrade", the
   request would be rejected with a 480 (Temporarily Unavailable)
   response (potentially with a Warning header field with warn-code 381
   "SIPS Required").  See Section 5.3 for more details.

   For example, the sip:bob@example.com and sips:bob@example.com AORs
   refer to the same user "Bob" in the domain "example.com": the first
   URI is the SIP version, and the second one is the SIPS version.  From
   the point of view of routing, requests to either sip:bob@example.com
   or sips:bob@example.com are treated the same way.  When Bob
   registers, it therefore does not really matter if he is using a SIP
   or a SIPS AOR, since they both refer to the same user.  At first
   glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by
   stating that a SIP and a SIPS URI are never equivalent.
   Specifically, it says that they are never equivalent for the purpose
   of comparing bindings in Contact header field URIs in REGISTER
   requests.  The key point is that this statement applies to the
   Contact header field bindings in a registration: it is the
   association of the Contact header field with the AOR that will
   determine whether or not the user is reachable with a SIPS URI.

   Consider this example: if Bob (AOR bob@example.com) registers with a
   SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the
   registrar and the location service then know that Bob is reachable at
   sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.

Top      ToC       Page 13 
   If a request is sent to AOR sips:bob@example.com, Bob's proxy will
   route it to Bob at Request-URI sips:bob@bobphone.example.com.  If a
   request is sent to AOR sip:bob@example.com, Bob's proxy will route it
   to Bob at Request-URI sip:bob@bobphone.example.com.

   If Bob wants to ensure that every request delivered to him always be
   transported over TLS, Bob can use [RFC5626] when registering.

   However, if Bob had registered with a SIP Contact header field
   instead of a SIPS Contact header field (e.g.,
   sip:bob@bobphone.example.com), then a request to AOR
   sips:bob@example.com would not be routed to Bob, since there is no
   SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP
   are not allowed.

   See Section 6 for illustrative call flows.



(page 13 continued on part 2)

Next RFC Part