[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-audet-sip-sips-guidelines) 00 01 02 03 04 05 06 07 08 09 RFC 5630

SIP                                                             F. Audet
Internet-Draft                                           Nortel Networks
Intended status: Standards Track                           June 25, 2007
Expires: December 27, 2007


The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
                         draft-ietf-sip-sips-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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.  This document also provides
   a discussion of possible future steps in specification.







Audet                   Expires December 27, 2007               [Page 1]


Internet-Draft                    SIPS                         June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Models for using TLS in SIP  . . . . . . . . . . . . . . .  3
       3.1.1.  Server-Provided Certificate  . . . . . . . . . . . . .  3
       3.1.2.  Mutual TLS . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.3.  Using TLS with SIP instead of SIPS . . . . . . . . . .  4
     3.2.  Meaning of SIPS  . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  Scope of SIPS  . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1.  Detection of Hop-by-Hop Security . . . . . . . . . . . 11
       3.3.2.  Double Record Routing  . . . . . . . . . . . . . . . . 12
     3.4.  Usage of the transport=tls URI Parameter and the TLS
           Via Parameter  . . . . . . . . . . . . . . . . . . . . . . 13
   4.  Normative Requirements . . . . . . . . . . . . . . . . . . . . 15
     4.1.  General User Agent Behavior  . . . . . . . . . . . . . . . 15
       4.1.1.  Service Routes . . . . . . . . . . . . . . . . . . . . 16
       4.1.2.  Registration . . . . . . . . . . . . . . . . . . . . . 16
       4.1.3.  SIPS in a Dialog . . . . . . . . . . . . . . . . . . . 17
       4.1.4.  Derived Dialogs and Transactions . . . . . . . . . . . 18
       4.1.5.  GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 19
     4.2.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 19
     4.3.  Redirect Server Behavior . . . . . . . . . . . . . . . . . 20
   5.  Response codes . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  418 SIPS Not Allowed . . . . . . . . . . . . . . . . . . . 21
     5.2.  419 SIPS Required  . . . . . . . . . . . . . . . . . . . . 21
   6.  Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Bob Registers his Contacts . . . . . . . . . . . . . . . . 23
     6.2.  Alice Calls Bob's SIPS AOR . . . . . . . . . . . . . . . . 27
     6.3.  Alice Calls Bob's SIP AOR using TCP  . . . . . . . . . . . 32
     6.4.  Alice Calls Bob's SIP AOR using TLS  . . . . . . . . . . . 42
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 49
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 50
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 50
   10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 50
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 51
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
     12.2. Informational References . . . . . . . . . . . . . . . . . 51
   Appendix A.  Future Steps in Specification . . . . . . . . . . . . 52
     A.1.  Indication of Validity of SIPS . . . . . . . . . . . . . . 53
     A.2.  True End-to-End Encryption of SIP  . . . . . . . . . . . . 53
     A.3.  Use of the transport parameter for TLS on a single hop . . 53
   Appendix B.  Bug Fixes for RFC 3261  . . . . . . . . . . . . . . . 53
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54
   Intellectual Property and Copyright Statements . . . . . . . . . . 56



Audet                   Expires December 27, 2007               [Page 2]


Internet-Draft                    SIPS                         June 2007


1.  Introduction

   The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] is
   underspecified in SIP [RFC3261] and has 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.  This document also provides
   a discussion of possible future steps in specification.


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.  Overview

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.  Often, a proxy (which may or may not be the one
   terminating the TLS connection) authenticates the client by using the
   SIP HTTP digest.  In this model, the UA is the TLS client side, and
   the Proxy is the TLS server side.  This directionality implies that
   the TLS connection always needs to be setup by the UA (e.g., during
   the registration phase).  Since SIP allows for requests in both
   directions (e..g, an incoming call), the UA must keep the TLS
   connection alive and that connection must be re-used for both
   incoming and outgoing requests.

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

   [I-D.ietf-sip-outbound] provides the mechanism for initiating and
   maintaining outbound connections in a standard interoperable way.






Audet                   Expires December 27, 2007               [Page 3]


Internet-Draft                    SIPS                         June 2007


3.1.2.  Mutual TLS

   In this model, both the TLS client and the TLS server provide a
   certificate in the TLS handshake phase.  When no TLS connection is in
   place, the UAC would therefore take on the role of the TLS Client and
   the UAS would therefore take on the role of the TLS server.  Since in
   SIP, a UA or a Proxy act both as UAC and UAS depending on if they are
   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 TLS 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 TLS can be used
   in those environments, but only if the connection is always stated by
   the same side, for example, by using [I-D.ietf-sip-outbound] as
   described in Section 3.1.1.  Having to rely on
   [I-D.ietf-sip-outbound] in this case negates many of the advantages
   of mutual TLS.

   The second significant limitation is that mutual TLS 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 this reasons, mutual TLS 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 [RFC3261]/26.2.2:

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




Audet                   Expires December 27, 2007               [Page 4]


Internet-Draft                    SIPS                         June 2007


   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 headers in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   Note that when TLS is used, the Via header indicates TLS.

   [RFC3261]/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.

   [I-D.ietf-sip-outbound] describes how to establish and maintain a TLS
   connection in environments where it can only be initiated by the UA.

   Similarly, proxies may 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 may insert Record-Route headers using SIP URIs
   even if it uses TLS transport.  [RFC3261]/26.3.2.2 explains how
   interdomain requests can use TLS.

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

3.2.  Meaning of SIPS

   [RFC3261]/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



Audet                   Expires December 27, 2007               [Page 5]


Internet-Draft                    SIPS                         June 2007


      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.

        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | 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 must be used between UA a@A and Proxy A
   o  TLS must be used between Proxy A and Proxy B
   o  TLS may be used between Proxy B and UA b@B, depending on local
      policy.

   One may 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 [I-D.ietf-sip-outbound].  At that time, it was
   recognized that in many practical deployments, Proxy B may not be
   able to establish a TLS connection with UA b because only Proxy B



Audet                   Expires December 27, 2007               [Page 6]


Internet-Draft                    SIPS                         June 2007


   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 may 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
   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, [I-D.ietf-sip-outbound] has provided a more
   satisfactory solution to this problem.  [I-D.ietf-sip-outbound] 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]/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
   consist of a SIPS URI, this implies that b@B must understand SIPS in
   the first place, and must 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.

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


















Audet                   Expires December 27, 2007               [Page 7]


Internet-Draft                    SIPS                         June 2007


        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | 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]/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) 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 one must therefore be
   careful not to oversell the meaning of a SIPS URI.  There is
   currently no mechanism to provide an indication of end-to-end
   security for SIP.  Other mechanisms may 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 than just using TLS
   transport with SIP?  The difference is that using a SIPS URI in a



Audet                   Expires December 27, 2007               [Page 8]


Internet-Draft                    SIPS                         June 2007


   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:
   i.e., that 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 may or may 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.  This
   specification clarifies the significance of using SIPS URIs in these
   cases.  SIPS URIs can also be used in human-usable format (e.g.,
   business cards, user interface, etc.).  SIPS URIs can even be used in
   other protocols that allow for including SIPS URIs (e.g., HTML).

3.2.1.  Scope of SIPS

   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
   of the SIP network, for example, to other networks such as the PSTN.

3.3.  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]/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 should arbitrarily
   "upgrade" SIP URIs to SIPS URIs when forwarding a request (see
   Section 4.2).  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
   Section 6.3 and in Section 6.4.  The proxy forwards the request to



Audet                   Expires December 27, 2007               [Page 9]


Internet-Draft                    SIPS                         June 2007


   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 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 can not be
   "downgraded" to a SIP URI by changing the scheme, or by sending the
   associated request over a non-secure link.  See Section 4.2.

   For example, the sip:bob@example.com and sips:bob@example.com AORs
   must 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 and 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 [RFC3261]/19.1.4 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 if the user is reachable or not 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.
   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.  The proxy should
   attempt to transport the request over TLS if a TLS connection can be
   established even if a SIP URI is used.  Indeed, some proxies may even
   have local policies of always using TLS.  Furthermore, if Bob wants
   to ensure that every request delivered to him always be transported
   over TLS, Bob can use [I-D.ietf-sip-outbound] when registering.

   However, if Bob had registered with a SIP Contact header field
   instead of a SIPS Contact header field (e.g.,



Audet                   Expires December 27, 2007              [Page 10]


Internet-Draft                    SIPS                         June 2007


   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.

   Since upgrading from SIP to SIPS is allowed in other circumstances
   (e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business
   card), it is quite possible that a request will be rejected with
   response code 416 (Unsupported URI Scheme), because the UAS only
   supports the SIP scheme.  When 416 (Unsupported URI Scheme) is
   received, the request may be re-attempted with a SIP URI, but the
   user should be informed.  While guessing a SIPS AOR from a known SIP
   AOR and using it to initiate a request is a valid thing to do, doing
   the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it)
   is not a valid thing to do as it would be a security downgrade.

   Although "downgrading" from SIPS to SIP is disallowed, it is possible
   that a redirect server or UAS sends a 3XX response to a request to a
   SIPS URI with a Contact header field containing a SIP URI.
   [RFC3261]/8.1.3.4 states that if the UAC decides to recurse to the
   SIP URI, it "SHOULD inform the user".  When a proxy is handling the
   3XX, it obviously cannot indicate to the user that a redirection has
   occurred from SIPS to SIP: therefore, proxies would not be able
   recurse on the Contact header field, and instead would either forward
   the 3XX to the UAC or reject the request.

3.3.1.  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 can not know for sure.  However,
   [RFC3261]/26.4.4 recommends how a UAS may make some checks to
   validate the security.  Additionally, the History-Info header
   [RFC4244] could be inspected for detecting retargeting between SIP
   and SIPS.

   It should be restated that all the checking may be circumvented by
   any proxies or B2BUAs on the path that does not follow the rules and
   recommendations of this specification and of [RFC3261].

   Proxies may have their own policies regarding routing of requests to
   SIP or SIPS URIs.  For example, some proxies in some environment may
   be configured to only route SIPS URIs.  Some proxies may be
   configured to detect non-compliances and reject un-secure requests.
   For example, proxies could inspect Request-URIs, Path, Record-Route,



Audet                   Expires December 27, 2007              [Page 11]


Internet-Draft                    SIPS                         June 2007


   To, From, Contact header fields and Via headers to enforce SIPS.

   [RFC3261]/26.4.4 explains that S/MIME may 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]/26.4.4, this is meant to imply that [RFC3893] would be used
   to "tunnel" important headers (such as To and 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 headers.  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, amongst other things, the AOR of the sender (from the From
   header) and the AOR of the original destination (from the To header).

3.3.2.  Double Record Routing

   While proxies conforming to this specification do not forward or
   retarget from SIP to SIPS and vice-versa, it is possible that proxies
   that conform to [RFC3261] but not to this specification may do so.
   The use case for a proxy to forward a request from SIPS to SIP was
   the "last hop exception" downgrade of [RFC3261].

   This section explains how such a proxy would be able to use "double
   record route" in order to forward or retarget a request from SIP to
   SIPS or from SIPS to SIP.  This section is included for completeness,
   to describe how to achieve backward compatibility.  If a proxy
   conforms to this specification, the procedures in this section are
   not used.

   When a proxy inserts a Record-Route entry, it must take care in using
   the proper scheme so that further in-dialog requests are sent to the
   proper URI.  [RFC3261] sections 16.6 and 16.7 describe how this can
   be done by having the proxy modifying the Record-Route in the
   response.  However, as described in [RFC3608], this is problematic.
   It is preferable to use the procedures of [RFC3608], and instead of
   following the procedure in [RFC3261], proxies that are inserting
   Record-Route or Path header field URIs would record not one but two
   route URIs when processing the request in the case where the scheme
   is changed.  The first value recorded indicates the scheme of the
   receiving interface, and the second indicates the scheme of the
   sending interface.  When processing the response, no modification of
   the recorded route is required.  This optimization provides for fully
   invertible routes that can be effectively used in construction of
   service routes.

   If the Request-URI or the topmost Route header on the receiving
   interface is SIPS and the Request-URI on the sending interface is



Audet                   Expires December 27, 2007              [Page 12]


Internet-Draft                    SIPS                         June 2007


   SIP, then the first value recorded uses a SIPS URI and the second
   value indicates a SIP URI.  It is illustrated as follows:

       UA a                        Proxy                         UA b

         -------REQUEST sips:-------->-------REQUEST sip:--------->
                                        Record-Route: <sip:p;lr>,
                                                      <sips:p;lr>

         <------Response sips:-------<-------Response sip:---------
          Record-Route: <sip:p;lr>      Record-Route: <sip:p;lr>,
                        <sips:p;lr>                   <sips:p;lr>

                      Record routing from SIPS to SIP

   If the Request-URI on the receiving interface is SIP and the Request-
   URI on the sending interface is SIPS, then the first value recorded
   uses a SIP URI and the second value indicates a SIPS URI.  It is
   illustrated as follows:

       UA a                        Proxy                         UA b

         -------REQUEST sip:--------->-------REQUEST sips:-------->
                                        Record-Route: <sips:p;lr>,
                                                      <sip:p;lr>

         <------Response sip:--------<-------Response sips:--------
          Record-Route: <sips:p;lr>      Record-Route: <sips:p;lr>,
                        <sip:p;lr>                     <sip:p;lr>

                      Record routing from SIP to SIPS

   Note that the same rules apply to the Path Header [RFC3327].

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

   [RFC3261]/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.

   The "tls" parameter has not been eliminated from the ABNF in



Audet                   Expires December 27, 2007              [Page 13]


Internet-Draft                    SIPS                         June 2007


   [RFC3261]/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.  It should also be noted that 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.
   However, many implementations today do use the transport=tls
   parameter, and therefore it is important to understand what it means.

   The transport=tls was meant to mean the same thing as the
   transport=tcp parameter, but with the use of TLS over TCP.  There are
   no parameters defined at this point for TLS over SCTP, or any other
   transport.  Unlike the SIP URI scheme, it was also meant to be
   specific to a single hop.  It would therefore not be suitable when
   the desired behavior is to secure every hop using TLS.

   When [I-D.ietf-sip-outbound] is used, a transport parameter in a
   REGISTER message would normally be ignored since the existing
   connection is re-used instead.  If [I-D.ietf-sip-outbound] is not
   used, transport=tls would indicate that the UA prefers to be reached
   using TLS over TCP for delivery of incoming requests, on the last hop
   as per the procedures of [RFC3263].  There are a number of
   significant architectural difficulties in using TLS without using
   [I-D.ietf-sip-outbound].  First, allowing inbound connection
   establishment means that the UA would have to be able to provide a
   certificate, which is difficult in most environments, as user
   certificates are often not practical.  The other main difficulty is
   that it would apply in environments where inbound TCP connections are
   allowed, which would preclude the use of NATs or Firewalls.

   In a Contact header field in a dialog-creating request, it would only
   be useful in the cases where Record-Route is not used.  However, as
   described in this specification, this is extremely unlikely to work
   because of the difficulty in establishing the TLS connection between
   peers (i.e., they would need to have certificates).

   In a Request-URI or in the first value of a Route header, the
   transport=tls parameter would be a request for the proxy processing
   the URI to use TLS as the transport for the next hop, as described in
   [RFC3263].

   In a Contact header field in a redirection response (3XX), the
   transport=tls parameter would be an indication that the request
   should be re-attempted to the new target using TLS for the last hop
   to that domain.  The current mechanism (i.e., a 3XX to a SIPS URI),
   would only allow to redirect to a SIPS resource, and therefore, TLS
   on each hop.  This could potentially be useful between proxies using



Audet                   Expires December 27, 2007              [Page 14]


Internet-Draft                    SIPS                         June 2007


   a redirection server, for example.

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

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


4.  Normative Requirements

   This section describes all the normative requirements defined by this
   specification.  The justification for the [RFC2119] language is
   provided by the previous sections of this specification.

4.1.  General User Agent Behavior

   When presented with a SIPS URI, a UAC or UAS MUST NOT change it to a
   SIP URI.  For example, if a directory entry includes a SIPS AOR, the
   UAC must not send requests to that AOR using a SIP Request-URI.
   Similarly, if a user reads a business card with a SIPS URI, he should
   not infer a SIP URI.  If a 3XX response includes a SIPS Contact
   header field, the UAC MUST 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]/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".  Furthermore, as
   mandated by [RFC3261]/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, it SHOULD respond with a 418 (SIPS Not Allowed).  UAS that
   do not support the SIPS URI scheme altogether "SHOULD reject the
   request with a 416 (Unsupported URI scheme) response" as described in
   [RFC3261]/8.2.2.1.  Upon receiving a 416 or 418, a UAC MUST NOT re-
   attempt the request by automatically replacing the SIPS scheme with a
   SIP scheme as described in [RFC3261]/8.1.3.5 as it would be a
   security vulnerability.  If the UAC does re-attempt the call with a
   SIP URI, it 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                   Expires December 27, 2007              [Page 15]


Internet-Draft                    SIPS                         June 2007


   If a UAS does not wish to be contacted with a SIP URI but instead by
   a SIPS URI, it SHOULD reject a request to a SIP Request-URI with
   response code 419 (SIPS Required)

4.1.1.  Service Routes

   If a UA registers 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.  It is the responsibility of
   the UAC to use a Route header consisting of all SIPS URIs when using
   a SIPS Request-URI and Contact header field.  Specifically, if the
   service route included 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.  Note that this allows for configuring or
   discovering one service route with all SIP URIs and allowing sending
   requests to both SIP and SIPS URIs.

4.1.2.  Registration

   This section describes the registration procedures of SIPS versus SIP
   Contact header fields.

   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.

   If a UA wishes to be reachable with a SIPS URI, it 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.
   Note that 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 may 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



Audet                   Expires December 27, 2007              [Page 16]


Internet-Draft                    SIPS                         June 2007


   AOR, a UA MUST NOT include both the SIPS and the SIP version of the
   same Contact header field in a REGISTER: it 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.
   Note however that a UA could register first with a SIP Contact header
   field (meaning it does not support SIPS), and later register with a
   SIPS Contact header field (meaning it now supports SIPS).

   [I-D.ietf-sip-outbound] 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 are SIPS, a SIPS AOR
   MUST be used by the UAC in the REGISTER.  If at least one of the
   Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
   mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.
   However, the registrar MUST treat the SIP and SIPS schemes of the AOR
   the same way (i.e., it MUST not care if it is SIP or SIPS).  These
   are purely mechanical rules with no influence on routing.

   Furthermore, it is a matter of local policy for a UA 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 would
   reject requests using the SIP Scheme with 419 (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 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 would
   accept requests addressed to a SIP Request-URI.

   A registrar MUST only accept a binding to a SIPS Contact header field
   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, the Contacts and
   all the Path headers, but does not include the From and To headers.
   If the URIs are not of the proper SIPS scheme, the registrar MUST
   reject the REGISTER with a 419 (SIPS Required).

4.1.3.  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



Audet                   Expires December 27, 2007              [Page 17]


Internet-Draft                    SIPS                         June 2007


   Contact header field was a SIPS URI, it would mean that it 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 may not be
   able to send requests to SIPS URIs.  If the top Route header field
   does not contain a SIPS URI, the Contact header field MUST be a SIP
   URI, 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 [I-D.ietf-sip-outbound]).

   When a target refresh occurs within a dialog (e.g., re-INVITE,
   UPDATE), the UAC and UAS MUST include a Contact header field with a
   SIPS URI if the original request used a SIPS Request-URI.

4.1.4.  Derived Dialogs and Transactions

   Sessions, dialogs and transactions may 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 MUST NOT
   result in an effective downgrading of SIPS to SIP, without the
   explicit authorization of the entities involved.

   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 new one MUST NOT be established
   using SIP, unless there is an explicit authorization given by the
   recipient of the REFER.  This could be a warning provided to the
   user.  Having such a warning could be useful for example for a secure
   directory service application, resulting in being routed to a UA that
   does not support SIPS.  If the proper treatment is to reject the
   REFER, for example because warnings are impractical or impossible
   with very simple phones, it could be rejected with error response 419
   (SIPS Required).

   Note that a REFER may also be used for referring to resources that do
   not result in dialogs being created.  In fact, a REFER may 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]/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 [RFC3891],
   and the Join header [RFC3911].  Again, the general principle is that
   these mechanism SHOULD NOT result in an effective downgrading of SIPS
   to SIP, without the proper authorization.



Audet                   Expires December 27, 2007              [Page 18]


Internet-Draft                    SIPS                         June 2007


4.1.5.  GRUU

   When a GRUU [I-D.ietf-sip-gruu] 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 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).

4.2.  Proxy Behavior

   Proxies that conform to this specification 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 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, it MUST reject it with a 418 (SIPS Not Allowed).

   Proxies SHOULD transport requests using a SIP URI over TLS when it is
   possible to set up a TLS connection, or re-use an existing one.
   [I-D.ietf-sip-outbound] for example, allows for re-using an existing
   TLS connection.  Some proxies MAY have policies that prohibits
   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, it 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 MAY 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 fields.  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, it MAY reject it with a 419 (SIPS Required).

   It is RECOMMENDED to use an outbound proxy as per the procedures
   defined in [I-D.ietf-sip-outbound] for supporting UACs that can not
   provide a certificate for establishing a TLS connection (i.e., when



Audet                   Expires December 27, 2007              [Page 19]


Internet-Draft                    SIPS                         June 2007


   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 or 418
   response, it MUST NOT recurse on it.  The Proxy SHOULD forward the
   best response instead of recursing, in order to allow for the UAC to
   take the appropriate action.

   When a proxy sends a request using a SIP Request-URI and receives a
   3XX response with a SIPS Contact header field, or, a 419 response, it
   MUST NOT recurse on it.  The Proxy SHOULD forward the best response
   instead of recursing, in order to allow for the UAC to take the
   appropriate action.

4.3.  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 no pre-
   established connection between the Proxy and the UAS (such as with
   [I-D.ietf-sip-outbound]), 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
   mutual TLS is used, and where there are no NAT traversal issues.  A
   redirect server would not be usable if server-side authentication is
   used or 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 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.  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 it may reject the request with a 418 (SIPS Not Allowed).






Audet                   Expires December 27, 2007              [Page 20]


Internet-Draft                    SIPS                         June 2007


5.  Response codes

   This specification defines two new responses codes.

5.1.  418 SIPS Not Allowed

   The UAS or proxy cannot process the request because the SIPS scheme
   is not allowed.  This response differs from 416 because the UAS or
   proxy recognizes the SIPS URI but it is not allowed, and because the
   UAC SHOULD NOT retry the request automatically using a SIP URI.
   Furthermore, the offending SIPS URI(s) may be in any location in the
   request (e.g., the Request-URI, a Contact header field, a Refer-To
   URI, etc.).

5.2.  419 SIPS Required

   The UAS or proxy cannot process the request because the SIPS scheme
   is required.  The UAC SHOULD retry the request automatically using a
   SIPS URI.  Furthermore, the offending SIPS URI(s) may be in any
   location in the request (e.g., the Request-URI, a Contact header
   field, a Refer-To URI, etc.).


6.  Call Flows

   The following diagram illustrates the topology used for the examples
   in this section:
























Audet                   Expires December 27, 2007              [Page 21]


Internet-Draft                    SIPS                         June 2007


                         |-----------|
                         | Registrar |
                         |-----------|
                               |
                               |
                         |-----------|          |-----------|
                         |  Outbound |__________|  Outbound |
                         |  Proxy B  |          |  Proxy A  |
                         |-----------|          |-----------|
                          /        |                  |
                         /         |                  |
                        /          |                  |
                 ______            |                  |
                |      |         _____              _____
                |______|        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 Outbound Proxy B, and
   consequently, they include a Route header indicating Proxy B. Proxy B
   removes the Route header corresponding to itself, and adds itself in
   a Path header.  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 Outbound Proxy A, including a
   Route header for Proxy A. Proxy A locates Bob's domain example.com.
   In this example, that domain is co-located with Bob's outbound proxy,
   but it could easily have been a separate proxy.  Outbound Proxy A
   removes the Route header corresponding to itself, and inserts itself
   in the Record-Route and forwards the request to Outbound Proxy B.

   The following subsections illustrates registration and three
   examples.  In the first example (Section 6.2), Alice calls Bob using
   Bob's SIPS URI.  In the second example (Section 6.3), Alice calls
   Bob's SIP AOR using TCP transport.  In the third example



Audet                   Expires December 27, 2007              [Page 22]


Internet-Draft                    SIPS                         June 2007


   (Section 6.4), Alice calls Bob's SIP AOR using TLS transport.

6.1.  Bob Registers his Contacts

   This call 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.


                                    Outbound
                 Bob@bobpc          Proxy B      Registrar
                  |                   |               |
                  |    REGISTER F1    |               |
                  |------------------>|  REGISTER F2  |
                  |                   |-------------->|
                  |                   |    200 F3     |
                  |      200 F4       |<--------------|
                  |<------------------|               |
                  |                   |               |
                  |   Bob@bobphone    |               |
                  |      |            |               |
                  |      |REGISTER F5 |               |
                  |      |----------->|  REGISTER F6  |
                  |      |            |-------------->|
                  |      |            |    200 F7     |
                  |      |   200 F8   |<--------------|
                  |      |<-----------|               |
                  |      |            |               |


                        Bob Registers His Contacts

   Message details


















Audet                   Expires December 27, 2007              [Page 23]


Internet-Draft                    SIPS                         June 2007


     F1 REGISTER Bob's PC Client -> Proxy B

     REGISTER sip:registrar.example.com SIP/2.0
     Via: SIP/2.0/TCP bobspc.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
     Route: <sip:proxyb.example.com;lr>
     Contact: <sip:bob@bobpc.example.com>
        ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
        ;reg-id=1
     Expires: 7200
     Content-Length: 0


     F2 REGISTER Proxy B -> Registrar

     REGISTER sip:registrar.example.com SIP/2.0
     Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7
     Via: SIP/2.0/TCP bobspc.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
     Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
     Contact: <sip:bob@bobpc.example.com>
        ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
        ;reg-id=1
     Expires: 7200
     Content-Length: 0
















Audet                   Expires December 27, 2007              [Page 24]


Internet-Draft                    SIPS                         June 2007


     F3 200 (REGISTER) Registrar -> Proxy B

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7
     Via: SIP/2.0/TCP bobspc.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
     Supported: outbound
     Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
     Contact: <sip:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
        ;reg-id=1
        ;expires=7200
     Date: Mon, 12 Jun 2006 16:43:12 GMT
     Content-Length: 0


     F4 200 (REGISTER) Proxy B -> Bob's PC Client

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP bobspc.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
     Supported: outbound
     Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
     Contact: <sip:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
        ;reg-id=1
        ;expires=7200
     Date: Mon, 12 Jun 2006 16:43:12 GMT
     Content-Length: 0
















Audet                   Expires December 27, 2007              [Page 25]


Internet-Draft                    SIPS                         June 2007


     F5 REGISTER Bob's Phone -> Proxy B

     REGISTER sips:registrar.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
     Route: <sips:proxyb.example.com;lr>
     Contact: <sips:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
        ;reg-id=1
     Expires: 7200
     Content-Length: 0


     F6 REGISTER Proxy B -> Registrar

     REGISTER sips:registrar.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.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
     Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
     Contact: <sips:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
        ;reg-id=1
     Expires: 7200
     Content-Length: 0
















Audet                   Expires December 27, 2007              [Page 26]


Internet-Draft                    SIPS                         June 2007


     F7 200 (REGISTER) Registrar -> Proxy B

     SIP/2.0 200 OK
     Via: SIP/2.0/TLS proxyb.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
     Supported: outbound
     Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
     Contact: <sips:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
        ;reg-id=1
        ;expires=7200
     Date: Mon, 12 Jun 2006 16:43:50 GMT
     Content-Length: 0


     F8 200 (REGISTER) 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
     Supported: outbound
     Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
     Contact: <sips:bob@bobphone.example.com>
        ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
        ;reg-id=1
        ;expires=7200
     Date: Mon, 12 Jun 2006 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).  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 Proxy B determines that the calls 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.  Proxy B inserts itself in the Record-



Audet                   Expires December 27, 2007              [Page 27]


Internet-Draft                    SIPS                         June 2007


   Route.  Bob answers at sips:bob@bobphone.example.com.


                               Outbound       Outbound
          Bob@bobpc            Proxy B        Proxy A       Alice
           |                     |              |              |
           |   Bob@bobphone      |              |  INVITE F9   |
           |      |              |  INVITE F11  |<-------------|
           |      |  INVITE F13  |<-------------|    100 F10   |
           |      |<-------------|    100 F12   |------------->|
           |      |    100 F14   |------------->|              |
           |      |------------->|              |              |
           |      |    200 F15   |              |              |
           |      |------------->|    200 F16   |              |
           |      |              |------------->|    200 F17   |
           |      |              |              |------------->|
           |      |              |              |    ACK F18   |
           |      |              |    ACK F19   |<-------------|
           |      |    ACK F20   |<-------------|              |
           |      |<-------------|              |              |
           |      |              |              |              |

                        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                   Expires December 27, 2007              [Page 28]


Internet-Draft                    SIPS                         June 2007


     F10 100 (INVITE) Proxy A -> Alice

     SIP/2.0 100 Trying
     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
     Content-Length: 0


     F11 INVITE Proxy A -> 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:KFndf+47KsFH@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) 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                   Expires December 27, 2007              [Page 29]


Internet-Draft                    SIPS                         June 2007


     F13 INVITE Proxy B -> Bob's Phone

     INVITE sips:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.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
     Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sips:KFndf+47KsFH@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) Bob's Phone -> Proxy B

     SIP/2.0 100 Trying
     Via: SIP/2.0/TLS proxyb.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                   Expires December 27, 2007              [Page 30]


Internet-Draft                    SIPS                         June 2007


     F15 200 (INVITE) Bob's Phone -> Proxy B

     SIP/2.0 200 OK
     Via: SIP/2.0/TLS proxyb.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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sips:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sips:bob@bobphone.example.com>
     Content-Length: 0


     F16 200 (INVITE) 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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sips:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sips:bob@bobphone.example.com>
     Content-Length: 0


     F17 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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sips:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sips:bob@bobphone.example.com>
     Content-Length: 0








Audet                   Expires December 27, 2007              [Page 31]


Internet-Draft                    SIPS                         June 2007


     F18 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:KFndf+47KsFH@proxya.example.net;lr>,
            <sips:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0


     F19 ACK Proxy A -> 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:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0


     F20 ACK Proxy B -> Bob's Phone

     ACK sips:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.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

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.  Proxy B
   consults the binding in the registration database, and finds the two



Audet                   Expires December 27, 2007              [Page 32]


Internet-Draft                    SIPS                         June 2007


   Contact header field bindings.  Alice had addressed Bob with a SIP
   Request-URI (sip:bob@example.com), so Proxy B determines that the
   calls 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.  Note
   that the proxy replaced the SIPS scheme with the SIP scheme for
   bob@bobphone.example.com.  Outbound Proxy B inserts itself 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                   Expires December 27, 2007              [Page 33]


Internet-Draft                    SIPS                         June 2007


                              Outbound       Outbound
           Bob@bobpc          Proxy B        Proxy A       Alice
            |                   |              |             |
            |                   |              |  INVITE F9  |
            |                   |  INVITE F11  |<------------|
            |     INVITE F13'   |<-------------|   100 F10   |
            |<------------------|   100 F12    |------------>|
            |      100 F14'     |------------->|             |
            |------------------>|              |             |
            |      180 F15'     |              |             |
            |------------------>|   180 F16'   |             |
            |                   |------------->|   180 F17'  |
            |   Bob@bobphone    |              |------------>|
            |      |            |              |             |
            |      | INVITE F13 |              |             |
            |      |<-----------|              |             |
            |      |  100 F14   |              |             |
            |      |----------->|              |             |
            |      |   200 F15  |              |             |
            |      |----------->|   200 F16    |             |
            |      |            |------------->|   200 F17   |
            |      |            |              |------------>|
            |      |            |              |   ACK F18   |
            |      |            |   ACK F19    |<------------|
            |      |  ACK F20   |<-------------|             |
            |      |<-----------|              |             |
            |                   |              |             |
            |     CANCEL F20'   |              |             |
            |<------------------|              |             |
            |      200 F21'     |              |             |
            |------------------>|              |             |
            |      487 F22'     |              |             |
            |------------------>|              |             |
            |                   |              |             |


                         Alice Calls Bob's SIP AOR

   Message details












Audet                   Expires December 27, 2007              [Page 34]


Internet-Draft                    SIPS                         June 2007


     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
     Max-Forwards: 70
     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 -> 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:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:alice@alice-1.example.net>
     Content-Type: application/sdp
     Content-Length: {as per SDP}
     {SDP not shown}








Audet                   Expires December 27, 2007              [Page 35]


Internet-Draft                    SIPS                         June 2007


     F12 100 (INVITE) 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 Proxy B -> Bob's PC Client

     INVITE sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TCP proxyb.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
     Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@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) Bob's PC Client -> Proxy B

     SIP/2.0 100 Trying
     Via: SIP/2.0/TCP proxyb.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                   Expires December 27, 2007              [Page 36]


Internet-Draft                    SIPS                         June 2007


     F15' 180 (INVITE) Bob's PC Client -> Proxy B

     SIP/2.0 180 Ringing
     Via: SIP/2.0/TCP proxyb.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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0


     F16' 180 (INVITE) 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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0


     F17' 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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0








Audet                   Expires December 27, 2007              [Page 37]


Internet-Draft                    SIPS                         June 2007


     F13 INVITE Proxy B -> Bob's Phone

     INVITE sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.example.com:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@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) Bob's Phone -> Proxy B

     SIP/2.0 100 Trying
     Via: SIP/2.0/TLS proxyb.example.com:5061;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                   Expires December 27, 2007              [Page 38]


Internet-Draft                    SIPS                         June 2007


     F15 200 (INVITE) Bob's Phone -> Proxy B

     SIP/2.0 200 OK
     Via: SIP/2.0/TLS proxyb.example.com:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0


     F16 200 (INVITE) 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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0




















Audet                   Expires December 27, 2007              [Page 39]


Internet-Draft                    SIPS                         June 2007


     F17 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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0


     F18 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:KFndf+47KsFH@proxya.example.net;lr>,
            <sip:UJH-hUdvb65@proxyb.example.com;lr>,
            <sips:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0


     F19 ACK Proxy A -> 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:UJH-hUdvb65@proxyb.example.com;lr>,
            <sips:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0








Audet                   Expires December 27, 2007              [Page 40]


Internet-Draft                    SIPS                         June 2007


     F20 ACK Proxy B -> Bob's Phone

     ACK sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.example.com:5061;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


     F20' CANCEL Proxy B -> Bob's PC Client

     CANCEL sip:bob@bobpc.example.com SIP/2.0
     Via: SIP/2.0/TCP proxyb.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
     Content-Length: 0


     F21' 200 (CANCEL) Proxy B -> Bob's PC Client

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP proxyb.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                   Expires December 27, 2007              [Page 41]


Internet-Draft                    SIPS                         June 2007


     F22' 487 (INVITE) Proxy B -> Bob's PC Client

     SIP/2.0 487 Request Terminated
     Via: SIP/2.0/TCP proxyb.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 outbound proxy.
   Such an arrangement would be common if Alice's UA supported TLS and
   wanted to use a single connection to the outbound proxy (as would be
   the case when using [I-D.ietf-sip-outbound]).  In the example below,
   Outbound proxy A is also using TLS as a transport to communicate with
   Outbound proxy B, but it is not necessarily the case.

   It should be noted that 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 (if present) typically would use a SIP URI
   (but it could also be a SIPS URI).  The Contact header fields, 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).

   Messages F20'-F22' are identical to the ones in Section 6.3.  The
   other messages are as follows.
















Audet                   Expires December 27, 2007              [Page 42]


Internet-Draft                    SIPS                         June 2007


     F9 INVITE Alice -> Proxy A

     INVITE sip:bob@example.com SIP/2.0
     Via: SIP/2.0/TLS alice-1.example.net:5061;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/TLS alice-1.example.net:5061;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
     Content-Length: 0


     F11 INVITE Proxy A -> Proxy B

     INVITE sip: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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:alice@alice-1.example.net>
     Content-Type: application/sdp
     Content-Length: {as per SDP}
     {SDP not shown}








Audet                   Expires December 27, 2007              [Page 43]


Internet-Draft                    SIPS                         June 2007


     F12 100 (INVITE) 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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Content-Length: 0


     F13' INVITE Proxy B -> Bob's PC Client

     INVITE sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
     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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@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) Bob's PC Client -> Proxy B

     SIP/2.0 100 Trying
     Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
     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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Content-Length: 0









Audet                   Expires December 27, 2007              [Page 44]


Internet-Draft                    SIPS                         June 2007


     F15' 180 (INVITE) Bob's PC Client -> Proxy B

     SIP/2.0 180 Ringing
     Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
     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 <sip:bob@example.com>;tag=963258
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0


     F16' 180 (INVITE) 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 <sip:bob@example.com>;tag=963258
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0


     F17' 180 (INVITE) Proxy A -> Alice

     SIP/2.0 180 Ringing
     Via: SIP/2.0/TLS alice-1.example.net:5061;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:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobpc.example.com>
     Content-Length: 0








Audet                   Expires December 27, 2007              [Page 45]


Internet-Draft                    SIPS                         June 2007


     F13 INVITE Proxy B -> Bob's Phone

     INVITE sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
     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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@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) Bob's Phone -> Proxy B

     SIP/2.0 100 Trying
     Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
     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 <sip:bob@example.com>
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Content-Length: 0




















Audet                   Expires December 27, 2007              [Page 46]


Internet-Draft                    SIPS                         June 2007


     F15 200 (INVITE) Bob's Phone -> Proxy B

     SIP/2.0 200 OK
     Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
     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 <sip:bob@example.com>;tag=5551212
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0


     F16 200 (INVITE) 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 <sip:bob@example.com>;tag=5551212
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 INVITE
     Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0




















Audet                   Expires December 27, 2007              [Page 47]


Internet-Draft                    SIPS                         June 2007


     F17 200 (INVITE) Proxy A -> Alice

     SIP/2.0 200 OK
     Via: SIP/2.0/TLS alice-1.example.net:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:UJH-hUdvb65@proxyb.example.com;lr>,
                   <sip:KFndf+47KsFH@proxya.example.net;lr>
     Contact: <sip:bob@bobphone.example.com>
     Content-Length: 0


     F18 ACK Alice -> Proxy A

     ACK sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS alice-1.example.net:5061;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:KFndf+47KsFH@proxya.example.net;lr>,
            <sip:UJH-hUdvb65@proxyb.example.com;lr>,
            <sips:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0


     F19 ACK Proxy A -> Proxy B

     ACK sip:bob@bobphone.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 <sip:bob@example.com>;tag=5551212
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 ACK
     Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
            <sips:UJH-hUdvb65@proxyb.example.com;lr>
     Content-Length: 0








Audet                   Expires December 27, 2007              [Page 48]


Internet-Draft                    SIPS                         June 2007


     F20 ACK Proxy B -> Bob's Phone

     ACK sip:bob@bobphone.example.com SIP/2.0
     Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
     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 <sip:bob@example.com>;tag=5551212
     From: Alice <sip:alice@example.net>;tag=8675309
     Call-ID: lzksjf8723k@sodk6587
     CSeq: 1 ACK
     Content-Length: 0


7.  Conclusion

   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 may 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
   may occur.  In this case, using Record-Route so that the requests are
   sent through proxies may 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 may
   still not be possible for the far end to establish a TLS connection
   with the SIP originating end if the certificate can not 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 may 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.  "Mutual TLS" (where both the client 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 TLS
   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



Audet                   Expires December 27, 2007              [Page 49]


Internet-Draft                    SIPS                         June 2007


   URI is used to establish a TLS connection, it must be possible for
   the entity establishing the connection (the client) to validate the
   certificate from the server side.  For server-side authentication,
   [I-D.ietf-sip-outbound] is the recommended approach.  For mutual TLS,
   it means that one should be very careful 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 re-used.  Other mechanisms may also be used in
   certain circumstances: for example, using root certificates that are
   widely recognized may allow for more easily created TLS connections.

   The "last hop exception" introduces significant potential
   vulnerabilities in SIP and it has therefore been deprecated by this
   specification.


8.  Security Considerations

   Most of this document can be considered to be security considerations
   since it applies to the usage of the SIPS URI.


9.  IANA Considerations

   This specification registers two new response codes, namely 418 (SIPS
   Not Allowed) and 419 (SIPS Required).  The response codes are defined
   by the following information, which has been included to the sub-
   registry for SIP methods and response-codes under
   http://www.iana.org/assignments/sip-parameters.

      Code: 418
      Default Reason Phrase: SIPS Not Allowed
      Reference: RFC XXX [Note to IANA Editor, please replace with RFC
      number of this document]

      Code: 419
      Default Reason Phrase: SIPS Required
      Reference: RFC XXX [Note to IANA Editor, please replace with RFC
      number of this document]


10.  IAB Considerations

   There are no IAB considerations.






Audet                   Expires December 27, 2007              [Page 50]


Internet-Draft                    SIPS                         June 2007


11.  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 and Hans Persson for their careful review and
   input.


12.  References

12.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.

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, December 2002.

12.2.  Informational References

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 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.




Audet                   Expires December 27, 2007              [Page 51]


Internet-Draft                    SIPS                         June 2007


   [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.

   [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.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-08 (work in progress), March 2007.

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-14 (work in progress),
              June 2007.

   [I-D.gurbani-sip-sipsec]
              Gurbani, V., "The SIPSEC Uniform Resource Identifier
              (URI)", draft-gurbani-sip-sipsec-01 (work in progress),
              June 2007.


Appendix A.  Future Steps in Specification

   This section is a placeholder for a discussion of possible future
   steps in specification, and the pros and cons of making such changes.



Audet                   Expires December 27, 2007              [Page 52]


Internet-Draft                    SIPS                         June 2007


   Protocol and normative changes to any specifications (such as RFC
   3261) resulting from this discussion would be specified in further
   documents.

A.1.  Indication of Validity of SIPS

   Since the presence of a SIPS URI in a Request-URI in an incoming
   request currently does not guarantee that SIPS and TLS was indeed
   used on every hop along the path, it has been suggested that it would
   be useful to define a mechanism for a verifiable assertion that TLS
   and SIPS were used on every hop.

A.2.  True End-to-End Encryption of SIP

   Another suggestion has been to define a mechanism to encrypt SIP end-
   to-end.  This would require either an peer-to-peer SIP model, or
   alternatively a mechanism that allows the encrypted SIP signalling to
   be tunnelled through proxies.  [I-D.gurbani-sip-sipsec] is an example
   of such a mechanism.

A.3.  Use of the transport parameter for TLS on a single hop

   A way to describe in a URI that TLS should be used on a specific hop
   (similar to what the transport=tls used to mean) has been suggested
   as a possible area for future steps in specification.  See discussion
   in Section 3.4.


Appendix B.  Bug Fixes for RFC 3261

   The last sentence of the fifth paragraph of 8.1.3.5 must be 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 must be replaced by:

      If the address-of-record in the To header field of a REGISTER
      request is a SIPS URI, then any Contact header field value in the
      request MUST also be SIPS URIs.

   In section 16.7 on p. 112 describing Record-Route, the second
   paragraph must be deleted.

   The last paragraph of section 19.1 must be reworded as follows:




Audet                   Expires December 27, 2007              [Page 53]


Internet-Draft                    SIPS                         June 2007


      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 (...)

   The second paragraph of section 26.2.2 must be 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,
      must be 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 must be replaced by the
   following:

      Actually using TLS on every segment of a request path entails that
      the terminating UAS must be reachable over TLS (by registering
      with a SIPS URI as a contact address).  The SIPS scheme implies
      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 fourth paragraph of section 26.4.4 must be deleted.

   The last sentence of the fifth paragraph of section 26.4.5 must be
   reworded as follows:

      (...)  S/MIME or, preferably, [RFC4474] may also be used (...)















Audet                   Expires December 27, 2007              [Page 54]


Internet-Draft                    SIPS                         June 2007


Author's Address

   Francois Audet
   Nortel Networks
   4655 Great America Parkway
   Santa Clara, CA  95054
   US

   Phone: +1 408 495 2456
   Email: audet@nortel.com









































Audet                   Expires December 27, 2007              [Page 55]


Internet-Draft                    SIPS                         June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Audet                   Expires December 27, 2007              [Page 56]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/