doc: Add RFC documents

1 files changed, 3139 insertions, 0 deletions

diff --git a/doc/rfc/rfc5630.txt b/doc/rfc/rfc5630.txt
new file mode 100644
index 0000000..2101836
--- /dev/null
+++ b/doc/rfc/rfc5630.txt
@@ -0,0 +1,3139 @@
+
+
+
+
+
+
+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.
+
+
+
+Audet                       Standards Track                     [Page 1]
+
+RFC 5630                          SIPS                      October 2009
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                     [Page 2]
+
+RFC 5630                          SIPS                      October 2009
+
+
+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.
+
+
+
+
+
+
+Audet                       Standards Track                     [Page 3]
+
+RFC 5630                          SIPS                      October 2009
+
+
+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].
+
+
+
+
+Audet                       Standards Track                     [Page 4]
+
+RFC 5630                          SIPS                      October 2009
+
+
+      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.
+
+
+
+Audet                       Standards Track                     [Page 5]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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
+
+
+
+Audet                       Standards Track                     [Page 6]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                     [Page 7]
+
+RFC 5630                          SIPS                      October 2009
+
+
+        ..........................         ...........................
+        .                        .         .                         .
+        .              +-------+ .         . +-------+               .
+        .              |       | .         . |       |               .
+        .              | 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
+
+
+
+Audet                       Standards Track                     [Page 8]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                     [Page 9]
+
+RFC 5630                          SIPS                      October 2009
+
+
+        ..........................         ...........................
+        .                        .         .                         .
+        .              +-------+ .         . +-------+               .
+        .              |       | .         . |       |               .
+        .              | 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
+
+
+
+Audet                       Standards Track                    [Page 10]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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
+
+
+
+Audet                       Standards Track                    [Page 11]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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.
+
+
+
+
+
+Audet                       Standards Track                    [Page 12]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   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.
+
+5.  Normative Requirements
+
+   This section describes all the normative requirements defined by this
+   specification.
+
+5.1.  General User Agent Behavior
+
+5.1.1.  UAC Behavior
+
+   When presented with a SIPS URI, a UAC MUST NOT change it to a SIP
+   URI.  For example, if a directory entry includes a SIPS AOR, the UAC
+   is not expected to send requests to that AOR using a SIP Request-URI.
+   Similarly, if a user reads a business card with a SIPS URI, it is not
+   possible to infer a SIP URI.  If a 3XX response includes a SIPS
+   Contact header field, the UAC does not replace it with a SIP Request-
+   URI (e.g., by replacing the SIPS scheme with a SIP scheme) when
+   sending a request as a result of the redirection.
+
+   As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the
+   Request-URI or top Route header field value contains a SIPS URI, the
+   Contact header field MUST contain a SIPS URI as well".
+
+   Upon receiving a 416 response or a 480 (Temporarily Unavailable)
+   response with a Warning header with warn-code 380 "SIPS Not Allowed",
+   a UAC MUST NOT re-attempt the request by automatically replacing the
+   SIPS scheme with a SIP scheme as described in [RFC3261], Section
+   8.1.3.5, as it would be a security vulnerability.  If the UAC does
+   re-attempt the call with a SIP URI, the UAC SHOULD get a confirmation
+   from the user to authorize re-initiating the session with a SIP
+   Request-URI instead of a SIPS Request-URI.
+
+
+
+
+Audet                       Standards Track                    [Page 13]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   When the route set is not empty (e.g., when a service route [RFC3608]
+   is returned by the registrar), it is the responsibility of the UAC to
+   use a Route header field consisting of all SIPS URIs when using a
+   SIPS Request-URI.  Specifically, if the route set included any SIP
+   URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing
+   the scheme from "sip" to "sips" before sending the request.  This
+   allows for configuring or discovering one service route with all SIP
+   URIs and allowing sending requests to both SIP and SIPS URIs.
+
+   When the UAC is using a SIP Request-URI, if the route set is not
+   empty and the topmost Route header field entry is a SIPS URI with the
+   lr parameter, the UAC MUST send the request over TLS (using a SIP
+   Request-URI).  If the route is not empty and the Route header field
+   entry is a SIPS URI without the lr parameter, the UAC MUST send the
+   request over TLS using a SIPS Request-URI corresponding to the
+   topmost entry in the route set.
+
+   To emphasize what is already defined in [RFC3261], UAs MUST NOT use
+   the "transport=tls" parameter.
+
+5.1.1.1.  Registration
+
+   The UAC registers Contacts header fields to either a SIPS or a SIP
+   AOR.
+
+   If a UA wishes to be reachable with a SIPS URI, the UA MUST register
+   with a SIPS Contact header field.  Requests addressed to that UA's
+   AOR using either a SIP or SIPS Request-URI will be routed to that UA.
+   This includes UAs that support both SIP and SIPS.  This specification
+   does not provide any SIP-based mechanism for a UA to provision its
+   proxy to only forward requests using a SIPS Request-URI.  A non-SIP
+   mechanism such as a web interface could be used to provision such a
+   preference.  A SIP mechanism for provisioning such a preference is
+   outside the scope of this specification.
+
+   If a UA does not wish to be reached with a SIPS URI, it MUST register
+   with a SIP Contact header field.
+
+   Because registering with a SIPS Contact header field implies a
+   binding of both a SIPS Contact and a corresponding SIP Contact to the
+   AOR, a UA MUST NOT include both the SIPS and the SIP versions of the
+   same Contact header field in a REGISTER request; the UA MUST only use
+   the SIPS version in this case.  Similarly, a UA SHOULD NOT register
+   both a SIP Contact header field and a SIPS Contact header field in
+   separate registrations as the SIP Contact header field would be
+   superfluous.  If it does, the second registration replaces the first
+   one (e.g., a UA could register first with a SIP Contact header field,
+   meaning it does not support SIPS, and later register with a SIPS
+
+
+
+Audet                       Standards Track                    [Page 14]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   Contact header field, meaning it now supports SIPS).  Similarly, if a
+   UA registers first with a SIPS Contact header field and later
+   registers with a SIP Contact header field, that SIP Contact header
+   field replaces the SIPS Contact header field.
+
+   [RFC5626] can be used by a UA if it wants to ensure that no requests
+   are delivered to it without using the TLS connection it used when
+   registering.
+
+   If all the Contact header fields in a REGISTER request are SIPS, the
+   UAC MUST use SIPS AORs in the From and To header fields in the
+   REGISTER request.  If at least one of the Contact header fields is
+   not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP
+   AORs in the From and To header fields in the REGISTER request.
+
+   To emphasize what is already defined in [RFC3261], UACs MUST NOT use
+   the "transport=tls" parameter.
+
+5.1.1.2.  SIPS in a Dialog
+
+   If the Request-URI in a request that initiates a dialog is a SIP URI,
+   then the UAC needs to be careful about what to use in the Contact
+   header field (in case Record-Route is not used for this hop).  If the
+   Contact header field was a SIPS URI, it would mean that the UAS would
+   only accept mid-dialog requests that are sent over secure transport
+   on each hop.  Since the Request-URI in this case is a SIP URI, it is
+   quite possible that the UA sending a request to that URI might not be
+   able to send requests to SIPS URIs.  If the top Route header field
+   does not contain a SIPS URI, the UAC MUST use a SIP URI in the
+   Contact header field, even if the request is sent over a secure
+   transport (e.g., the first hop could be re-using a TLS connection to
+   the proxy as would be the case with [RFC5626]).
+
+   When a target refresh occurs within a dialog (e.g., re-INVITE
+   request, UPDATE request), the UAC MUST include a Contact header field
+   with a SIPS URI if the original request used a SIPS Request-URI.
+
+5.1.1.3.  Derived Dialogs and Transactions
+
+   Sessions, dialogs, and transactions can be "derived" from existing
+   ones.  A good example of a derived dialog is one that was established
+   as a result of using the REFER method [RFC3515].
+
+   As a general principle, derived dialogs and transactions cannot
+   result in an effective downgrading of SIPS to SIP, without the
+   explicit authorization of the entities involved.
+
+
+
+
+
+Audet                       Standards Track                    [Page 15]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   For example, when a REFER request is used to perform a call transfer,
+   it results in an existing dialog being terminated and another one
+   being created based on the Refer-To URI.  If that initial dialog was
+   established using SIPS, then the UAC MUST NOT establish a new one
+   using SIP, unless there is an explicit authorization given by the
+   recipient of the REFER request.  This could be a warning provided to
+   the user.  Having such a warning could be useful, for example, for a
+   secure directory service application, to warn a user that a request
+   may be routed to a UA that does not support SIPS.
+
+   A REFER request can also be used for referring to resources that do
+   not result in dialogs being created.  In fact, a REFER request can be
+   used to point to resources that are of a different type than the
+   original one (i.e., not SIP or SIPS).  Please see [RFC3515], Section
+   5.2, for security considerations related to this.
+
+   Other examples of derived dialogs and transactions include the use of
+   Third-Party Call Control [RFC3725], the Replaces header field
+   [RFC3891], and the Join header field [RFC3911].  Again, the general
+   principle is that these mechanisms SHOULD NOT result in an effective
+   downgrading of SIPS to SIP, without the proper authorization.
+
+5.1.1.4.  GRUU
+
+   When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned
+   to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned.
+   When a GRUU is obtained through registration, if the Contact header
+   field in the REGISTER request contains a SIP URI, the SIP version of
+   the GRUU is returned.  If the Contact header field in the REGISTER
+   request contains a SIPS URI, the SIPS version of the GRUU is
+   returned.
+
+   If the wrong scheme is received in the GRUU (which would be an error
+   in the registrar), the UAC SHOULD treat it as if the proper scheme
+   was used (i.e., it SHOULD replace the scheme with the proper scheme
+   before using the GRUU).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 16]
+
+RFC 5630                          SIPS                      October 2009
+
+
+5.1.2.  UAS Behavior
+
+   When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
+   URI.
+
+   As mandated by [RFC3261], Section 12.1.1:
+
+      If the request that initiated the dialog contained a SIPS URI in
+      the Request-URI or in the top Record-Route header field value, if
+      there was any, or the Contact header field if there was no Record-
+      Route header field, the Contact header field in the response MUST
+      be a SIPS URI.
+
+   If a UAS does not wish to be reached with a SIPS URI but only with a
+   SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable)
+   response.  The UAS SHOULD include a Warning header with warn-code 380
+   "SIPS Not Allowed".  [RFC3261], Section 8.2.2.1, states that UASs
+   that do not support the SIPS URI scheme at all "SHOULD reject the
+   request with a 416 (Unsupported URI scheme) response".
+
+   If a UAS does not wish to be contacted with a SIP URI but instead by
+   a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480
+   (Temporarily Unavailable) response.  The UAS SHOULD include a Warning
+   header with warn-code 381 "SIPS Required".
+
+   It is a matter of local policy for a UAS to accept incoming requests
+   addressed to a URI scheme that does not correspond to what it used
+   for registration.  For example, a UA with a policy of "always SIPS"
+   would address the registrar using a SIPS Request-URI over TLS, would
+   register with a SIPS Contact header field, and the UAS would reject
+   requests using the SIP scheme with a 480 (Temporarily Unavailable)
+   response with a Warning header with warn-code 381 "SIPS Required".  A
+   UA with a policy of "best-effort SIPS" would address the registrar
+   using a SIPS Request-URI over TLS, would register with a SIPS Contact
+   header field, and the UAS would accept requests addressed to either
+   SIP or SIPS Request-URIs.  A UA with a policy of "No SIPS" would
+   address the registrar using a SIP Request-URI, could use TLS or not,
+   would register with a SIP AOR and a SIP Contact header field, and the
+   UAS would accept requests addressed to a SIP Request-URI.
+
+   If a UAS needs to reject a request because the URIs are used
+   inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact
+   header field is a SIP URI), the UAS MUST reject the request with a
+   400 (Bad Request) response.
+
+   When a target refresh occurs within a dialog (e.g., re-INVITE
+   request, UPDATE request), the UAS MUST include a Contact header field
+   with a SIPS URI if the original request used a SIPS Request-URI.
+
+
+
+Audet                       Standards Track                    [Page 17]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   To emphasize what is already defined in [RFC3261], UASs MUST NOT use
+   the "transport=tls" parameter.
+
+5.2.  Registrar Behavior
+
+   The UAC registers Contacts header fields to either a SIPS or a SIP
+   AOR.  From a routing perspective, it does not matter which one is
+   used for registration as they identify the same resource.  The
+   registrar MUST consider AORs that are identical except for one having
+   the SIP scheme and the other having the SIPS scheme to be equivalent.
+
+   A registrar MUST accept a binding to a SIPS Contact header field only
+   if all the appropriate URIs are of the SIPS scheme; otherwise, there
+   could be an inadvertent binding of a secure resource (SIPS) to an
+   unsecured one (SIP).  This includes the Request-URI and the Contacts
+   and all the Path header fields, but does not include the From and To
+   header fields.  If the URIs are not of the proper SIPS scheme, the
+   registrar MUST reject the REGISTER with a 400 (Bad Request).
+
+   A registrar can return a service route [RFC3608] and impose some
+   constraints on whether or not TLS will be mandatory on specific hops.
+   For example, if the topmost entry in the Path header field returned
+   by the registrar is a SIPS URI, the registrar is telling the UAC that
+   TLS is to be used for the first hop, even if the Request-URI is SIP.
+
+   If a UA registered with a SIPS Contact header field, the registrar
+   returning a service route [RFC3608] MUST return a service route
+   consisting of SIP URIs if the intent of the registrar is to allow
+   both SIP and SIPS to be used in requests sent by that client.  If a
+   UA registers with a SIPS Contact header field, the registrar
+   returning a service route MUST return a service route consisting of
+   SIPS URIs if the intent of the registrar is to allow only SIPS URIs
+   to be used in requests sent by that UA.
+
+5.2.1.  GRUU
+
+   When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through
+   registration, the registrar MUST assign both a SIP GRUU and a SIPS
+   GRUU.  If the Contact header field in the REGISTER request contains a
+   SIP URI, the registrar MUST return the SIP version of the GRUU.  If
+   the Contact header field in the REGISTER request contains a SIPS URI,
+   the registrar MUST return the SIPS version of the GRUU.
+
+5.3.  Proxy Behavior
+
+   Proxies MUST NOT use the last-hop exception of [RFC3261] when
+   forwarding or retargeting a request to the last hop.  Specifically,
+   when a proxy receives a request with a SIPS Request-URI, the proxy
+
+
+
+Audet                       Standards Track                    [Page 18]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   MUST only forward or retarget the request to a SIPS Request-URI.  If
+   the target UAS had registered previously using a SIP Contact header
+   field instead of a SIPS Contact header field, the proxy MUST NOT
+   forward the request to the URI indicated in the Contact header field.
+   If the proxy needs to reject the request for that reason, the proxy
+   MUST reject it with a 480 (Temporarily Unavailable) response.  In
+   this case, the proxy SHOULD include a Warning header with warn-code
+   380 "SIPS Not Allowed".
+
+   Proxies SHOULD transport requests using a SIP URI over TLS when it is
+   possible to set up a TLS connection, or reuse an existing one.
+   [RFC5626], for example, allows for re-using an existing TLS
+   connection.  Some proxies could have policies that prohibit sending
+   any request over anything but TLS.
+
+   When a proxy receives a request with a SIP Request-URI, the proxy
+   MUST NOT forward the request to a SIPS Request-URI.  If the target
+   UAS had registered previously using a SIPS Contact header field, and
+   the proxy decides to forward the request, the proxy MUST replace that
+   SIPS scheme with a SIP scheme while leaving the rest of the URI as
+   is, and use the resulting URI as the Request-URI of the forwarded
+   request.  The proxy MUST use TLS to forward the request to the UAS.
+   Some proxies could have a policy of not forwarding at all requests
+   using a non-SIPS Request-URI if the UAS had registered using a SIPS
+   Contact header field.  If the proxy elects to reject the request
+   because it has such a policy or because it is not capable of
+   establishing a TLS connection, the proxy MAY reject it with a 480
+   (Temporarily Unavailable) response with a Warning header with warn-
+   code 381 "SIPS Required".
+
+   If a proxy needs to reject a request because the URIs are used
+   inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact
+   header field is a SIP URI), the proxy SHOULD use response code 400
+   (Bad Request).
+
+   It is RECOMMENDED that the proxy use the outbound proxy procedures
+   defined in [RFC5626] for supporting UACs that cannot provide a
+   certificate for establishing a TLS connection (i.e., when server-side
+   authentication is used).
+
+   When a proxy sends a request using a SIPS Request-URI and receives a
+   3XX response with a SIP Contact header field, or a 416 response, or a
+   480 (Temporarily Unavailable) response with a Warning header with
+   warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse
+   on the response.  In this case, the proxy SHOULD forward the best
+   response instead of recursing, in order to allow for the UAC to take
+   the appropriate action.
+
+
+
+
+Audet                       Standards Track                    [Page 19]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   When a proxy sends a request using a SIP Request-URI and receives a
+   3XX response with a SIPS Contact header field, or a 480 (Temporarily
+   Unavailable) response with a Warning header with warn-code 381 "SIPS
+   Required", the proxy MUST NOT recurse on the response.  In this case,
+   the proxy SHOULD forward the best response instead of recursing, in
+   order to allow for the UAC to take the appropriate action.
+
+   To emphasize what is already defined in [RFC3261], proxies MUST NOT
+   use the "transport=tls" parameter.
+
+5.4.  Redirect Server Behavior
+
+   Using a redirect server with TLS instead of using a proxy has some
+   limitations that have to be taken into account.  Since there is no
+   pre-established connection between the proxy and the UAS (such as
+   with [RFC5626]), it is only appropriate for scenarios where inbound
+   connections are allowed.  For example, it could be used in a server-
+   to-server environment (redirect server or proxy server) where TLS
+   mutual authentication is used, and where there are no NAT traversal
+   issues.  A redirect server would not be able to redirect to an entity
+   that does not have a certificate.  A redirect server might not be
+   usable if there is a NAT between the server and the UAS.
+
+   When a redirect server receives a request with a SIP Request-URI, the
+   redirect server MAY redirect with a 3XX response to either a SIP or a
+   SIPS Contact header field.  If the target UAS had registered
+   previously using a SIPS Contact header field, the redirect server
+   SHOULD return a SIPS Contact header field if it is in an environment
+   where TLS is usable (as described in the previous paragraph).  If the
+   target UAS had registered previously using a SIP Contact header
+   field, the redirect server MUST return a SIP Contact header field in
+   a 3XX response if it redirects the request.
+
+   When a redirect server receives a request with a SIPS Request-URI,
+   the redirect server MAY redirect with a 3XX response to a SIP or a
+   SIPS Contact header field.  If the target UAS had registered
+   previously using a SIPS Contact header field, the redirect server
+   SHOULD return a SIPS Contact header field if it is in an environment
+   where TLS is usable.  If the target UAS had registered previously
+   using a SIP Contact header field, the redirect server MUST return a
+   SIP Contact header field in a 3XX response if it chooses to redirect;
+   otherwise, the UAS MAY reject the request with a 480 (Temporarily
+   Unavailable) response with a Warning header with warn-code 380 "SIPS
+   Not Allowed".  If a redirect server redirects to a UAS that it has no
+   knowledge of (e.g., an AOR in a different domain), the Contact header
+   field could be of any scheme.
+
+
+
+
+
+Audet                       Standards Track                    [Page 20]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   If a redirect server needs to reject a request because the URIs are
+   used inconsistently (e.g., the Request-URI is a SIPS URI, but the
+   Contact header field is a SIP URI), the redirect server SHOULD use
+   response code 400 (Bad Request).
+
+   To emphasize what is already defined in [RFC3261], redirect servers
+   MUST NOT use the "transport=tls" parameter.
+
+6.  Call Flows
+
+   The following diagram illustrates the topology used for the examples
+   in this section:
+
+                         example.com       .      example.net
+                                           .
+                       |-------------|     .    |------------|
+                       | Registrar/  |__________|  Proxy  A  |
+                       | Auth. Proxy |     .    |  (proxya)  |
+                       |    (pb)     |     .    |------------|
+                       |-------------|     .          |
+                             |             .          |
+                             |             .          |
+                       |-----------|       .          |
+                       |   Edge    |       .          |
+                       |  Proxy B  |       .          |
+                       |   (eb)    |       .          |
+                       |-----------|       .          |
+                        /        |         .          |
+                       /         |         .          |
+                      /          |         .          |
+               ______            |         .          |
+              |      |         _____       .        _____
+              |______|        O / \ O      .       O / \ O
+             /_______/         /___\       .        /___\
+                                           .
+             bob@bobpc      bob@bobphone   .         alice
+
+
+                                 Topology
+
+   In the following examples, Bob has two clients; one is a SIP PC
+   client running on his computer, and the other one is a SIP phone.
+   The PC client does not support SIPS, and consequently only registers
+   with a SIP Contact header field.  The SIP phone however does support
+   SIPS and TLS, and consequently registers with a SIPS Contact header
+   field.  Both of Bob's devices are going through Edge Proxy B, and
+   consequently, they include a Route header field indicating
+
+
+
+
+Audet                       Standards Track                    [Page 21]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   eb.example.com.  Edge Proxy B removes the Route header field
+   corresponding to itself, and adds itself in a Path header field.  The
+   registration process call flow is illustrated in Section 6.1.
+
+   After registration, there are two Contact bindings associated with
+   Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and
+   sip:bob@bobpc.example.com.
+
+   Alice then calls Bob through her own Proxy A.  Proxy A locates Bob's
+   domain example.com.  In this example, that domain is owned by Bob's
+   Registrar/Authoritative Proxy B.  Proxy A removes the Route header
+   field corresponding to itself, and inserts itself in the Record-Route
+   and forwards the request to Registrar/Authoritative Proxy B.
+
+   The following subsections illustrate registration and three examples.
+   In the first example (Section 6.2), Alice calls Bob's SIPS AOR.  In
+   the second example (Section 6.3), Alice calls Bob's SIP AOR using TCP
+   transport.  In the third example (Section 6.4), Alice calls Bob's SIP
+   AOR using TLS transport.
+
+6.1.  Bob Registers His Contacts
+
+   This flow illustrates the registration process by which Bob's device
+   registers.  His PC client (Bob@bobpc) registers with a SIP scheme,
+   and his SIP phone (Bob@phone) registers with a SIPS scheme.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 22]
+
+RFC 5630                          SIPS                      October 2009
+
+
+                                    (eb)           (pb)
+                                    Edge        Registrar/
+                Bob@bobpc          Proxy B     Auth. Proxy B
+                 |                   |               |
+                 |    REGISTER F1    |               |
+                 |------------------>|  REGISTER F2  |
+                 |                   |-------------->|
+                 |                   |    200 F3     |
+                 |      200 F4       |<--------------|
+                 |<------------------|               |
+                 |                   |               |
+                 |   Bob@bobphone    |               |
+                 |      |            |               |
+                 |      |REGISTER F5 |               |
+                 |      |----------->|  REGISTER F6  |
+                 |      |            |-------------->|
+                 |      |            |    200 F7     |
+                 |      |   200 F8   |<--------------|
+                 |      |<-----------|               |
+                 |      |            |               |
+
+
+                        Bob Registers His Contacts
+
+   Message details
+
+   F1 REGISTER Bob's PC Client -> Edge Proxy B
+
+   REGISTER sip:pb.example.com SIP/2.0
+   Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
+   Max-Forwards: 70
+   To: Bob <sip:bob@example.com>
+   From: Bob <sip:bob@example.com>;tag=456248
+   Call-ID: 843817637684230@998sdasdh09
+   CSeq: 1826 REGISTER
+   Supported: path, outbound
+   Route: <sip:eb.example.com;lr>
+   Contact: <sip:bob@bobpc.example.com>
+      ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
+      ;reg-id=1
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 23]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   REGISTER sip:pb.example.com SIP/2.0
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
+   Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
+   Max-Forwards: 69
+   To: Bob <sip:bob@example.com>
+   From: Bob <sip:bob@example.com>;tag=456248
+   Call-ID: 843817637684230@998sdasdh09
+   CSeq: 1826 REGISTER
+   Supported: path, outbound
+   Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
+   Contact: <sip:bob@bobpc.example.com>
+      ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
+      ;reg-id=1
+   Content-Length: 0
+
+
+   F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
+   Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
+   To: Bob <sip:bob@example.com>;tag=2493K59K9
+   From: Bob <sip:bob@example.com>;tag=456248
+   Call-ID: 843817637684230@998sdasdh09
+   CSeq: 1826 REGISTER
+   Require: outbound
+   Supported: path, outbound
+   Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
+   Contact: <sip:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
+      ;reg-id=1
+      ;expires=3600
+   Date: Mon, 12 Jun 2006 16:43:12 GMT
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 24]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
+   To: Bob <sip:bob@example.com>;tag=2493K59K9
+   From: Bob <sip:bob@example.com>;tag=456248
+   Call-ID: 843817637684230@998sdasdh09
+   CSeq: 1826 REGISTER
+   Require: outbound
+   Supported: path, outbound
+   Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
+   Contact: <sip:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
+      ;reg-id=1
+      ;expires=3600
+   Date: Thu, 09 Aug 2007 16:43:12 GMT
+   Content-Length: 0
+
+
+   F5 REGISTER Bob's Phone -> Edge Proxy B
+
+   REGISTER sips:pb.example.com SIP/2.0
+   Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
+   Max-Forwards: 70
+   To: Bob <sips:bob@example.com>
+   From: Bob <sips:bob@example.com>;tag=90210
+   Call-ID: faif9a@qwefnwdclk
+   CSeq: 12 REGISTER
+   Supported: path, outbound
+   Route: <sips:eb.example.com;lr>
+   Contact: <sips:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
+      ;reg-id=1
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 25]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   REGISTER sips:pb.example.com SIP/2.0
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
+   Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
+   Max-Forwards: 69
+   To: Bob <sips:bob@example.com>
+   From: Bob <sips:bob@example.com>;tag=90210
+   Call-ID: faif9a@qwefnwdclk
+   CSeq: 12 REGISTER
+   Supported: path, outbound
+   Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Contact: <sips:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
+      ;reg-id=1
+   Content-Length: 0
+
+
+   F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
+   Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
+   To: Bob <sips:bob@example.com>;tag=5150
+   From: Bob <sips:bob@example.com>;tag=90210
+   Call-ID: faif9a@qwefnwdclk
+   CSeq: 12 REGISTER
+   Require: outbound
+   Supported: path, outbound
+   Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Contact: <sips:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
+      ;reg-id=1
+      ;expires=3600
+   Date: Thu, 09 Aug 2007 16:43:50 GMT
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 26]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
+   To: Bob <sips:bob@example.com>;tag=5150
+   From: Bob <sips:bob@example.com>;tag=90210
+   Call-ID: faif9a@qwefnwdclk
+   CSeq: 12 REGISTER
+   Require: outbound
+   Supported: path, outbound
+   Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Contact: <sips:bob@bobphone.example.com>
+      ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
+      ;reg-id=1
+      ;expires=3600
+   Date: Thu, 09 Aug 2007 16:43:50 GMT
+   Content-Length: 0
+
+6.2.  Alice Calls Bob's SIPS AOR
+
+   Bob's registration has already occurred as per Section 6.1.
+
+   In this first example, Alice calls Bob's SIPS AOR
+   (sips:bob@example.com).  Registrar/Authoritative Proxy B consults the
+   binding in the registration database, and finds the two Contact
+   header field bindings.  Alice had addressed Bob with a SIPS Request-
+   URI (sips:bob@example.com), so Registrar/Authoritative Proxy B
+   determines that the call needs to be routed only to bobphone (which
+   registered using a SIPS Contact header field), and therefore the
+   request is only sent to sips:bob@bobphone.example.com, through Edge
+   Proxy B.  Both Registrar/Authoritative Proxy B and Edge Proxy B
+   insert themselves in the Record-Route.  Bob answers at
+   sips:bob@bobphone.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 27]
+
+RFC 5630                          SIPS                      October 2009
+
+
+                           (eb)         (pb)
+                           Edge      Registrar/
+       Bob@bobpc          Proxy B   Auth. Proxy B   Proxy A     Alice
+        |                   |            |            |            |
+        |                   |            |            | INVITE F9  |
+        |   Bob@bobphone    |            | INVITE F11 |<-----------|
+        |      |            | INVITE F13 |<-----------|   100 F10  |
+        |      | INVITE F15 |<-----------|   100 F12  |----------->|
+        |      |<-----------|   100 F14  |----------->|            |
+        |      |   180 F16  |----------->|            |            |
+        |      |----------->|   180 F17  |            |            |
+        |      |   200 F20  |----------->|   180 F18  |            |
+        |      |----------->|   200 F21  |----------->|   180 F19  |
+        |      |            |----------->|   200 F22  |----------->|
+        |      |            |            |----------->|   200 F23  |
+        |      |            |            |            |----------->|
+        |      |            |            |            |   ACK F24  |
+        |      |            |            |   ACK F25  |<-----------|
+        |      |            |   ACK F26  |<-----------|            |
+        |      |   ACK F27  |<-----------|            |            |
+        |      |<-----------|            |            |            |
+        |      |            |            |            |            |
+
+                        Alice Calls Bob's SIPS AOR
+
+   Message details
+
+   F9 INVITE Alice -> Proxy A
+
+   INVITE sips:bob@example.com SIP/2.0
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   Max-Forwards: 70
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Route: <sips:proxya.example.net;lr>
+   Contact: <sips:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 28]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F10 100 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+   F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
+
+   INVITE sips:bob@example.com SIP/2.0
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   Max-Forwards: 69
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route: <sips:proxya.example.net;lr>
+   Contact: <sips:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 29]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   INVITE sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   Max-Forwards: 68
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
+   Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 30]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F15 INVITE Edge Proxy B -> Bob's phone
+
+   INVITE sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   Max-Forwards: 67
+   To: Bob <sips:bob@example.com>
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F16 180 (INVITE) Bob's Phone -> Edge Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 31]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F18 180 Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F19 180 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+Audet                       Standards Track                    [Page 32]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F20 200 (INVITE) Bob's Phone -> Edge Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 33]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F22 200 Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F23 200 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
+   Contact: <sips:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F24 ACK Alice -> Proxy A
+
+   ACK sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
+   Max-Forwards: 70
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 34]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F25 ACK Proxy A -> Registrar/Authoritative Proxy B
+
+   ACK sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
+   Max-Forwards: 69
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sips:pb.example.com;lr>,
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
+   Content-Length: 0
+
+
+   F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   ACK sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
+   Max-Forwards: 69
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sips:pb.example.com;lr>,
+    <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
+   Content-Length: 0
+
+
+   F27 ACK Proxy B -> Bob's Phone
+
+   ACK sips:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
+   Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
+   Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
+   Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
+   Max-Forwards: 68
+   To: Bob <sips:bob@example.com>;tag=5551212
+   From: Alice <sips:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Content-Length: 0
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 35]
+
+RFC 5630                          SIPS                      October 2009
+
+
+6.3.  Alice Calls Bob's SIP AOR Using TCP
+
+   Bob's registration has already occurred as per Section 6.1.
+
+   In the second example, Alice calls Bob's SIP AOR instead
+   (sip:bob@example.com), and she uses TCP as a transport.  Registrar/
+   Authoritative Proxy B consults the binding in the registration
+   database, and finds the two Contact header field bindings.  Alice had
+   addressed Bob with a SIP Request-URI (sip:bob@example.com), so
+   Registrar/Authoritative Proxy B determines that the call needs to be
+   routed both to bobpc (which registered with a SIP Contact header
+   field) and bobphone (which registered with a SIPS Contact header
+   field), and therefore the request is forked to
+   sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through
+   Edge Proxy B.  Note that Registrar/Authoritative Proxy B preserved
+   the SIP scheme of the Request-URI instead of replacing it with the
+   SIPS scheme of the Contact header field that was used for
+   registration.  Both Registrar/Authoritative Proxy B and Edge Proxy B
+   insert themselves in the Record-Route.  Bob's phone's policy is to
+   accept calls to SIP and SIPS (i.e., "best effort"), so both his PC
+   client and his SIP phone ring simultaneously.  Bob answers on his SIP
+   phone, and the forked call leg to the PC client is canceled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 36]
+
+RFC 5630                          SIPS                      October 2009
+
+
+                           (eb)         (pb)
+                           Edge      Registrar/
+       Bob@bobpc          Proxy B   Auth. Proxy B   Proxy A     Alice
+        |                   |            |            |            |
+        |                   |            |            | INVITE F9  |
+        |                   |            | INVITE F11 |<-----------|
+        |                   | INVITE F13'|<-----------|   100 F10  |
+        |    INVITE F15'    |<-----------|   100 F12  |----------->|
+        |<------------------|   100 F14' |----------->|            |
+        |     180 F16'      |----------->|            |            |
+        |------------------>|   180 F17' |            |            |
+        |                   |----------->|  180 F18'  |            |
+        |   Bob@bobphone    |            |----------->|   180 F19' |
+        |      |            | INVITE F13 |            |----------->|
+        |      | INVITE F15 |<-----------|            |            |
+        |      |<-----------|   100 F14  |            |            |
+        |      |   180 F16  |----------->|            |            |
+        |      |----------->|   180 F17  |            |            |
+        |      |   200 F20  |----------->|   180 F18  |            |
+        |      |----------->|   200 F21  |----------->|   180 F19  |
+        |      |            |----------->|   200 F22  |----------->|
+        |      |            |            |----------->|   200 F23  |
+        |      |            |            |            |----------->|
+        |      |            |            |            |   ACK F24  |
+        |      |            |            |   ACK F25  |<-----------|
+        |      |            |   ACK F26  |<-----------|            |
+        |      |   ACK F27  |<-----------|            |            |
+        |      |<-----------|            |            |            |
+        |                   | CANCEL F26'|            |            |
+        |    CANCEL F27'    |<-----------|            |            |
+        |<------------------|            |            |            |
+        |     200 F28'      |            |            |            |
+        |------------------>|   200 F29' |            |            |
+        |     487 F30'      |----------->|            |            |
+        |------------------>|   487 F31' |            |            |
+        |                   |----------->|            |            |
+
+
+                         Alice Calls Bob's SIP AOR
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 37]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   Message details
+
+   F9 INVITE Alice -> Proxy A
+
+   INVITE sip:bob@example.com SIP/2.0
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 70
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Route: <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F10 100 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+   F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
+
+   INVITE sip:bob@example.com SIP/2.0
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 69
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route: <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 38]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+   F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   INVITE sip:bob@bobpc.example.com SIP/2.0
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 68
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
+   Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 39]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F15' INVITE Edge Proxy B -> Bob's PC Client
+
+   INVITE sip:bob@bobpc.example.com SIP/2.0
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 67
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=963258
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobpc.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 40]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=963258
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobpc.example.com>
+   Content-Length: 0
+
+
+   F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=963258
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobpc.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 41]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F19' 180 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=963258
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobpc.example.com>
+   Content-Length: 0
+
+
+   F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   INVITE sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 68
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 100 Trying
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 42]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F15 INVITE Edge Proxy B -> Bob's Phone
+
+   INVITE sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 68
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:alice@alice-1.example.net>
+   Content-Type: application/sdp
+   Content-Length: {as per SDP}
+   {SDP not shown}
+
+
+   F16 180 (INVITE) Bob's Phone -> Edge Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 43]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 44]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F19 180 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 180 Ringing
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F20 200 (INVITE) Bob's Phone -> Edge Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 45]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 46]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F23 200 (INVITE) Proxy A -> Alice
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Record-Route:
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
+    <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
+   Contact: <sip:bob@bobphone.example.com>
+   Content-Length: 0
+
+
+   F24 ACK Alice -> Proxy A
+
+   ACK sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 70
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
+    <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
+   Content-Length: 0
+
+
+   F25 ACK Proxy A -> Registrar/Authoritative Proxy B
+
+   ACK sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 69
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sip:pb.example.com;lr>,
+          <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+    Content-Length: 0
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 47]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   ACK sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 69
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Content-Length: 0
+
+
+   F27 ACK Proxy B -> Bob's Phone
+
+   ACK sip:bob@bobphone.example.com SIP/2.0
+   Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   Max-Forwards: 68
+   To: Bob <sip:bob@example.com>;tag=5551212
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 ACK
+   Content-Length: 0
+
+
+   F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
+
+   CANCEL sip:bob@bobpc.example.com SIP/2.0
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Max-Forwards: 70
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 CANCEL
+   Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 48]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F27' CANCEL Edge Proxy B -> Bob's PC Client
+
+   CANCEL sip:bob@bobpc.example.com SIP/2.0
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Max-Forwards: 69
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 CANCEL
+   Content-Length: 0
+
+
+   F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 CANCEL
+   Content-Length: 0
+
+
+   F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 CANCEL
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 49]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
+
+   SIP/2.0 487 Request Terminated
+   Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+
+   F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
+
+   SIP/2.0 487 Request Terminated
+   Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
+   Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
+   Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
+   To: Bob <sip:bob@example.com>
+   From: Alice <sip:alice@example.net>;tag=8675309
+   Call-ID: lzksjf8723k@sodk6587
+   CSeq: 1 INVITE
+   Content-Length: 0
+
+6.4.  Alice Calls Bob's SIP AOR Using TLS
+
+   Bob's registration has already occurred as per Section 6.1.
+
+   The third example is identical to the second one, except that Alice
+   uses TLS as the transport for her connection to her proxy.  Such an
+   arrangement would be common if Alice's UA supported TLS and wanted to
+   use a single connection to the proxy (as would be the case when using
+   [RFC5626]).  In the example below, Proxy A is also using TLS as a
+   transport to communicate with Outbound Proxy B, but it is not
+   necessarily the case.
+
+   When using a SIP URI in the Request-URI but TLS as a transport for
+   sending the request, the Via field indicates TLS.  The Route header
+   field (if present) typically would use a SIP URI (but it could also
+   be a SIPS URI).  The Contact header fields and To and From, however
+   would also normally indicate a SIP URI.
+
+   The call flow would be exactly as per the second example
+   (Section 6.3).  The only difference would be that all the Via header
+   fields would use TLS Via parameters.  The URIs would remain SIP URIs
+   and not SIPS URIs.
+
+
+
+Audet                       Standards Track                    [Page 50]
+
+RFC 5630                          SIPS                      October 2009
+
+
+7.  Further Considerations
+
+   SIP [RFC3261] itself introduces some complications with using SIPS,
+   for example, when Record-Route is not used.  When a SIPS URI is used
+   in a Contact header field in a dialog-initiating request and Record-
+   Route is not used, that SIPS URI might not be usable by the other
+   end.  If the other end does not support SIPS and/or TLS, it will not
+   be able to use it.  The last-hop exception is an example of when this
+   can occur.  In this case, using Record-Route so that the requests are
+   sent through proxies can help in making it work.  Another example is
+   that even in a case where the Contact header field is a SIPS URI, no
+   Record-Route is used, and the far end supports SIPS and TLS, it might
+   still not be possible for the far end to establish a TLS connection
+   with the SIP originating end if the certificate cannot be validated
+   by the far end.  This could typically be the case if the originating
+   end was using server-side authentication as described below, or if
+   the originating end is not using a certificate that can be validated.
+
+   TLS itself has a significant impact on how SIPS can be used.  Server-
+   side authentication (where the server side provides its certificate
+   but the client side does not) is typically used between a SIP end-
+   user device acting as the TLS client side (e.g., a phone or a
+   personal computer) and its SIP server (proxy or registrar) acting as
+   the TLS server side.  TLS mutual authentication (where both the
+   client side and the server side provide their respective
+   certificates) is typically used between SIP servers (proxies,
+   registrars), or statically configured devices such as PSTN gateways
+   or media servers.  In the mutual authentication model, for two
+   entities to be able to establish a TLS connection, it is required
+   that both sides be able to validate each other's certificates, either
+   by static configuration or by being able to recurse to a valid root
+   certificate.  With server-side authentication, only the client side
+   is capable of validating the server side's certificate, as the client
+   side does not provide a certificate.  The consequences of all this
+   are that whenever a SIPS URI is used to establish a TLS connection,
+   it is expected to be possible for the entity establishing the
+   connection (the client) to validate the certificate from the server
+   side.  For server-side authentication, [RFC5626] is the recommended
+   approach.  For mutual authentication, one needs to ensure that the
+   architecture of the network is such that connections are made between
+   entities that have access to each other's certificates.  Record-Route
+   [RFC3261] and Path [RFC3327] are very useful in ensuring that
+   previously established TLS connections can be reused.  Other
+   mechanisms might also be used in certain circumstances: for example,
+   using root certificates that are widely recognized allows for more
+   easily created TLS connections.
+
+
+
+
+
+Audet                       Standards Track                    [Page 51]
+
+RFC 5630                          SIPS                      October 2009
+
+
+8.  Security Considerations
+
+   Most of this document can be considered to be security considerations
+   since it applies to the usage of the SIPS URI.
+
+   The "last-hop exception" of [RFC3261] introduced significant
+   potential vulnerabilities in SIP, and it has therefore been
+   deprecated by this specification.
+
+   Section 26.4.4 of [RFC3261] describes the security considerations for
+   the SIPS URI scheme.  These security considerations also applies
+   here, as modified by Appendix A.
+
+9.  IANA Considerations
+
+   This specification registers two new warning codes, namely, 380 "SIPS
+   Not Allowed" and 381 "SIPS Required".  The warning codes are defined
+   as follows, and have been included in the Warning Codes (warn-codes)
+   sub-registry of the SIP Parameters registry available from
+   http://www.iana.org.
+
+   380  SIPS Not Allowed: The UAS or proxy cannot process the request
+        because the SIPS scheme is not allowed (e.g., because there are
+        currently no registered SIPS contacts).
+
+   381  SIPS Required: The UAS or proxy cannot process the request
+        because the SIPS scheme is required.
+
+   Reference: RFC 5630
+
+   The note in the Warning Codes sub-registry is as follows:
+
+      Warning codes provide information supplemental to the status code
+      in SIP response messages.
+
+10.  Acknowledgments
+
+   The author would like to thank Jon Peterson, Cullen Jennings,
+   Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert
+   Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage,
+   Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham
+   Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell
+   for their careful review and input.  Many thanks to Rohan Mahy for
+   helping me with the subtleties of [RFC5626].
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 52]
+
+RFC 5630                          SIPS                      October 2009
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5626]  Jennings, C., "Managing Client-Initiated Connections in
+              the Session Initiation Protocol (SIP)", RFC 5626, October
+              2009.
+
+11.2.  Informative References
+
+   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
+              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+              March 1999.
+
+   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+              (SIP) Extension Header Field for Registering Non-Adjacent
+              Contacts", RFC 3327, December 2002.
+
+   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+              Method", RFC 3515, April 2003.
+
+   [RFC3608]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+              (SIP) Extension Header Field for Service Route Discovery
+              During Registration", RFC 3608, October 2003.
+
+   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
+              Camarillo, "Best Current Practices for Third Party Call
+              Control (3pcc) in the Session Initiation Protocol (SIP)",
+              BCP 85, RFC 3725, April 2004.
+
+   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
+              Protocol (SIP) "Replaces" Header", RFC 3891,
+              September 2004.
+
+   [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
+              Authenticated Identity Body (AIB) Format", RFC 3893,
+              September 2004.
+
+
+
+Audet                       Standards Track                    [Page 53]
+
+RFC 5630                          SIPS                      October 2009
+
+
+   [RFC3911]  Mahy, R. and D. Petrie, "The Session Initiation Protocol
+              (SIP) "Join" Header", RFC 3911, October 2004.
+
+   [RFC4168]  Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
+              Stream Control Transmission Protocol (SCTP) as a Transport
+              for the Session Initiation Protocol (SIP)", RFC 4168,
+              October 2005.
+
+   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
+              Protocol (SIP) for Request History Information", RFC 4244,
+              November 2005.
+
+   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
+              Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
+              Agent URIs (GRUU) in the Session Initiation Protocol
+              (SIP)", RFC 5627, October 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 54]
+
+RFC 5630                          SIPS                      October 2009
+
+
+Appendix A.  Bug Fixes for RFC 3261
+
+   In order to support the material in this document, this section makes
+   corrections to RFC 3261.
+
+   The last sentence of the fifth paragraph of Section 8.1.3.5 is
+   replaced by:
+
+      The client SHOULD retry the request, this time, using a SIP URI
+      unless the original Request-URI used a SIPS scheme, in which case
+      the client MUST NOT retry the request automatically.
+
+   The fifth paragraph of Section 10.2.1 is replaced by:
+
+      If the Address of Record in the To header field of a REGISTER
+      request is a SIPS URI, then the UAC MUST also include only SIPS
+      URIs in any Contact header field value in the requests.
+
+   In Section 16.7 on p. 112 describing Record-Route, the second
+   paragraph is deleted.
+
+   The last paragraph of Section 19.1 is reworded as follows:
+
+      A SIPS URI specifies that the resource be contacted securely.
+      This means, in particular, that TLS is to be used on each hop
+      between the UAC and the resource identified by the target SIPS
+      URI.  Any resources described by a SIP URI (...)
+
+   In the third paragraph of Section 20.43, the words "the session
+   description" in the first sentence are replaced with "SIP".  Later in
+   the paragraph, "390" is replaced with "380", and "miscellaneous
+   warnings" is replaced with "miscellaneous SIP-related warnings".
+
+   The second paragraph of Section 26.2.2 is reworded as follows:
+
+      (...)  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 resource identified by the Request-URI, is
+      secured with TLS.  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.
+
+   The first paragraph of Section 26.4.4 is replaced by the following:
+
+      Actually using TLS on every segment of a request path entails that
+      the terminating UAS is reachable over TLS (by registering with a
+      SIPS URI as a contact address).  The SIPS scheme implies
+
+
+
+Audet                       Standards Track                    [Page 55]
+
+RFC 5630                          SIPS                      October 2009
+
+
+      transitive trust.  Obviously, there is nothing that prevents
+      proxies from cheating.  Thus, SIPS cannot guarantee that TLS usage
+      will be truly respected end-to-end on each segment of a request
+      path.  Note that since many UAs will not accept incoming TLS
+      connections, even those UAs that do support TLS will be required
+      to maintain persistent TLS connections as described in the TLS
+      limitations section above in order to receive requests over TLS as
+      a UAS.
+
+   The first sentence of the third paragraph of Section 26.4.4 is
+   replaced by the following:
+
+      Ensuring that TLS will be used for all of the request segments up
+      to the target UAS is somewhat complex.
+
+   The fourth paragraph of Section 26.4.4 is deleted.
+
+   The last sentence of the fifth paragraph of Section 26.4.4 is
+   reworded as follows:
+
+      S/MIME or, preferably, [RFC4474] may also be used by the
+      originating UAC to help ensure that the original form of the To
+      header field is carried end-to-end.
+
+   In the third paragraph of Section 27.2, the phrase "when the failure
+   of the transaction results from a Session Description Protocol (SDP)
+   (RFC 2327 [1]) problem" is deleted.
+
+   In the fifth paragraph of Section 27.2, "390" is replaced with "380",
+   and "miscellaneous warnings" is replaced with "miscellaneous SIP-
+   related warnings".
+
+Author's Address
+
+   Francois Audet
+   Skype Labs
+
+   EMail: francois.audet@skypelabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Audet                       Standards Track                    [Page 56]
+