GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5630

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

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

Abstract

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

Status of This Memo

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

Copyright and License Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Audet Standards Track [Page 1] RFC 5630 SIPS October 2009

Table of Contents

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

Audet Standards Track [Page 2] RFC 5630 SIPS October 2009

1. Introduction

 The meaning and usage of the SIPS URI scheme and of Transport Layer
 Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have
 been a source of confusion for implementers.
 This document provides clarifications and guidelines concerning the
 use of the SIPS URI scheme in the Session Initiation Protocol (SIP).
 It also makes normative changes to SIP (including both [RFC3261] and
 [RFC3608].

2. Terminology

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

3. Background

3.1. Models for Using TLS in SIP

 This section describes briefly the usage of TLS in SIP.

3.1.1. Server-Provided Certificate

 In this model, only the TLS server provides a certificate during the
 TLS handshake.  This is applicable only between a user agent (UA) and
 a proxy, where the UA is the TLS client and the proxy is the TLS
 server, and hence the UA uses TLS to authenticate the proxy but the
 proxy does not use TLS to authenticate the UA.  If the proxy needs to
 authenticate the UA, this can be achieved by SIP HTTP digest
 authentication.  This directionality implies that the TLS connection
 always needs to be set up by the UA (e.g., during the registration
 phase).  Since SIP allows for requests in both directions (e.g., an
 incoming call), the UA is expected to keep the TLS connection alive,
 and that connection is expected to be reused for both incoming and
 outgoing requests.
 This solution of having the UA always initiate and keep alive the
 connection also solves the Network Address Translation (NAT) and
 firewall problem as it ensures that responses and further requests
 will always be deliverable on the existing connection.
 [RFC5626] provides the mechanism for initiating and maintaining
 outbound connections in a standard interoperable way.

Audet Standards Track [Page 3] RFC 5630 SIPS October 2009

3.1.2. Mutual Authentication

 In this model, both the TLS client and the TLS server provide a
 certificate in the TLS handshake phase.  When used between a UA and a
 proxy (or between two UAs), this implies that a UA is in possession
 of a certificate.  When sending a SIP request when there is not
 already a suitable TLS connection in place, a user agent client (UAC)
 takes on the role of TLS client in establishing a new TLS connection.
 When establishing a TLS connection for receipt of a SIP request, a
 user agent server (UAS) takes on the role of TLS server.  Because in
 SIP a UA or a proxy acts both as UAC and UAS depending on if it is
 sending or receiving requests, the symmetrical nature of mutual TLS
 is very convenient.  This allows for TLS connections to be set up or
 torn down at will and does not rely on keeping the TLS connection
 alive for further requests.
 However, there are some significant limitations.
 The first obvious limitation is not with mutual authentication per
 se, but with the model where the underlying TCP connection can be
 established by either side, interchangeably, which is not possible in
 many environments.  For examples, NATs and firewalls will often allow
 TCP connections to be established in one direction only.  This
 includes most residential SIP deployments, for example.  Mutual
 authentication can be used in those environments, but only if the
 connection is always started by the same side, for example, by using
 [RFC5626] as described in Section 3.1.1.  Having to rely on [RFC5626]
 in this case negates many of the advantages of mutual authentication.
 The second significant limitation is that mutual authentication
 requires both sides to exchange a certificate.  This has proven to be
 impractical in many environments, in particular for SIP UAs, because
 of the difficulties of setting up a certificate infrastructure for a
 wide population of users.
 For these reasons, mutual authentication is mostly used in server-to-
 server communications (e.g., between SIP proxies, or between proxies
 and gateways or media servers), and in environments where using
 certificates on both sides is possible (e.g., high-security devices
 used within an enterprise).

3.1.3. Using TLS with SIP Instead of SIPS

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

Audet Standards Track [Page 4] RFC 5630 SIPS October 2009

    Users that distribute a SIPS URI as an address-of-record may elect
    to operate devices that refuse requests over insecure transports.
 If one wants to use "best-effort TLS" for SIP, one just needs to use
 a SIP URI, and send the request over TLS.
 Using SIP over TLS is very simple.  A UA opens a TLS connection and
 uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
 message (From, To, Request-URI, Contact header field, Route, etc.).
 When TLS is used, the Via header field indicates TLS.
 [RFC3261], Section 26.3.2.1, states:
    When a UA comes online and registers with its local administrative
    domain, it SHOULD establish a TLS connection with its registrar
    (...).  Once the registration has been accepted by the registrar,
    the UA SHOULD leave this TLS connection open provided that the
    registrar also acts as the proxy server to which requests are sent
    for users in this administrative domain.  The existing TLS
    connection will be reused to deliver incoming requests to the UA
    that had just completed registration.
 [RFC5626] describes how to establish and maintain a TLS connection in
 environments where it can only be initiated by the UA.
 Similarly, proxies can forward requests using TLS if they can open a
 TLS connection, even if the route set used SIP URIs instead of SIPS
 URIs.  The proxies can insert Record-Route header fields using SIP
 URIs even if it uses TLS transport.  [RFC3261], Section 26.3.2.2,
 explains how interdomain requests can use TLS.
 Some user agents, redirect servers, and proxies might have local
 policies that enforce TLS on all connections, independently of
 whether or not SIPS is used.

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

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

Audet Standards Track [Page 5] RFC 5630 SIPS October 2009

 The "tls" parameter has not been eliminated from the ABNF in
 [RFC3261], Section 25, since the parameter needs to remain in the
 ABNF for backward compatibility in order for parsers to be able to
 process the parameter correctly.  The transport=tls parameter has
 never been defined in an RFC, but only in some of the Internet drafts
 between [RFC2543] and [RFC3261].
 This specification does not make use of the transport=tls parameter.
 The reinstatement of the transport=tls parameter, or an alternative
 mechanism for indicating the use of the TLS on a single hop in a URI,
 is outside the scope of this specification.
 For Via header fields, the following transport protocols are defined
 in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-
 SCTP".

3.2. Detection of Hop-by-Hop Security

 The presence of a SIPS Request-URI does not necessarily indicate that
 the request was sent securely on each hop.  So how does a UAS know if
 SIPS was used for the entire request path to secure the request end-
 to-end?  Effectively, the UAS cannot know for sure.  However,
 [RFC3261], Section 26.4.4, recommends how a UAS can make some checks
 to validate the security.  Additionally, the History-Info header
 field [RFC4244] could be inspected for detecting retargeting from SIP
 and SIPS.  Retargeting from SIP to SIPS by a proxy is an issue
 because it can leave the receiver of the request with the impression
 that the request was delivered securely on each hop, while in fact,
 it was not.
 To emphasize, all the checking can be circumvented by any proxies or
 back-to-back user agents (B2BUAs) on the path that do not follow the
 rules and recommendations of this specification and of [RFC3261].
 Proxies can have their own policies regarding routing of requests to
 SIP or SIPS URIs.  For example, some proxies in some environments can
 be configured to only route SIPS URIs.  Some proxies can be
 configured to detect non-compliances and reject unsecure requests.
 For example, proxies could inspect Request-URIs, Path, Record-Route,
 To, From, Contact header fields, and Via header fields to enforce
 SIPS.
 [RFC3261], Section 26.4.4, explains that S/MIME can also be used by
 the originating UAC to ensure that the original form of the To header
 field is carried end-to-end.  While not specifically mentioned in
 [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893]
 would be used to "tunnel" important header fields (such as To and

Audet Standards Track [Page 6] RFC 5630 SIPS October 2009

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

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

 [RFC3261], Section 19.1, describes a SIPS URI as follows:
    A SIPS URI specifies that the resource be contacted securely.
    This means, in particular, that TLS is to be used between the UAC
    and the domain that owns the URI.  From there, secure
    communications are used to reach the user, where the specific
    security mechanism depends on the policy of the domain.
 Section 26.2.2 re-iterates it, with regards to Request-URIs:
    When used as the Request-URI of a request, the SIPS scheme
    signifies that each hop over which the request is forwarded, until
    the request reaches the SIP entity responsible for the domain
    portion of the Request-URI, must be secured with TLS; once it
    reaches the domain in question it is handled in accordance with
    local security and routing policy, quite possibly using TLS for
    any last hop to a UAS.  When used by the originator of a request
    (as would be the case if they employed a SIPS URI as the address-
    of-record of the target), SIPS dictates that the entire request
    path to the target domain be so secured.
 Let's take the classic SIP trapezoid to explain the meaning of a
 sips:b@B URI.  Instead of using real domain names like example.com
 and example.net, logical names like "A" and "B" are used, for
 clarity.

Audet Standards Track [Page 7] RFC 5630 SIPS October 2009

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

Audet Standards Track [Page 8] RFC 5630 SIPS October 2009

 not be transported over TLS when a SIPS URI is used, and it does not
 apply to outgoing requests.  The rationale for this was somewhat
 flawed, and since then, [RFC5626] has provided a more satisfactory
 solution to this problem.  [RFC5626] also solves the problem that if
 UA b is behind a NAT or firewall, Proxy B would not even be able to
 establish a TCP session in the first place.
 Furthermore, consider the problem of using SIPS inside a dialog.  If
 a@A sends a request to b@B using a SIPS Request-URI, then, according
 to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain
 a SIPS URI as well".  This means that b@B, upon sending a new Request
 within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS
 URI.  If there is no Record-Route entry, or if the last Record-Route
 entry consists of a SIPS URI, this implies that b@B is expected to
 understand SIPS in the first place, and is required to also support
 TLS.  If the last Record-Route entry however is a sip URI, then b
 would be able to send requests without using TLS (but b would still
 have to be able to handle SIPS schemes when parsing the message).  In
 either case, the Request-URI in the request from b@B to B would be a
 SIPS URI.

4. Overview of Operations

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

Audet Standards Track [Page 9] RFC 5630 SIPS October 2009

      ..........................         ...........................
      .                        .         .                         .
      .              +-------+ .         . +-------+               .
      .              |       | .         . |       |               .
      .              | Proxy |-----TLS---- | Proxy |               .
      .              |   A   | .         . |  B    |               .
      .              |       | .         . |       |               .
      .            / +-------+ .         . +-------+ \             .
      .           /            .         .            \            .
      .          /             .         .             \           .
      .        TLS             .         .             TLS         .
      .        /               .         .               \         .
      .       /                .         .                \        .
      .      /                 .         .                 \       .
      .   +-------+            .         .              +-------+  .
      .   |       |            .         .              |       |  .
      .   | UAC a |            .         .              | UAS b |  .
      .   |       |            .         .              |       |  .
      .   +-------+            .         .              +-------+  .
      .             Domain A   .         .   Domain B              .
      ..........................         ...........................
               SIP trapezoid without last-hop exception
 The SIPS scheme implies transitive trust.  Obviously, there is
 nothing that prevents proxies from cheating (see [RFC3261], Section
 26.4.4).  While SIPS is useful to request that a resource be
 contacted securely, it is not useful as an indication that a resource
 was in fact contacted securely.  Therefore, it is not appropriate to
 infer that because an incoming request had a Request-URI (or even a
 To header field) containing a SIPS URI, that it necessarily
 guarantees that the request was in fact transmitted securely on each
 hop.  Some have been tempted to believe that the SIPS scheme was
 equivalent to an HTTPS scheme in the sense that one could provide a
 visual indication to a user (e.g., a padlock icon) to the effect that
 the session is secured.  This is obviously not the case, and
 therefore the meaning of a SIPS URI is not to be oversold.  There is
 currently no mechanism to provide an indication of end-to-end
 security for SIP.  Other mechanisms can provide a more concrete
 indication of some level of security.  For example, SIP Identity
 [RFC4474] provides an authenticated identity mechanism and a domain-
 to-domain integrity protection mechanism.
 Some have asked why is SIPS useful in a global open environment such
 as the Internet, if (when used in a Request-URI) it is not an
 absolute guarantee that the request will in fact be delivered over
 TLS on each hop?  Why is SIPS any different from just using TLS
 transport with SIP?  The difference is that using a SIPS URI in a

Audet Standards Track [Page 10] RFC 5630 SIPS October 2009

 Request-URI means that if you are instructing the network to use TLS
 over each hop and if it is not possible to reject the request, you
 would rather have the request fail than have the request delivered
 without TLS.  Just using TLS with a SIP Request-URI instead of a SIPS
 Request-URI implies a "best-effort" service: the request can but need
 not be delivered over TLS on each hop.
 Another common question is why not have a Proxy-Require and Require
 option tag forcing the use of TLS instead?  The answer is that it
 would only be functionally equivalent to using SIPS in a Request-URI.
 SIPS URIs however can be used in many other header fields: in Contact
 for registration, Contact in dialog-creating requests, Route, Record-
 Route, Path, From, To, Refer-To, Referred-By, etc.  SIPS URIs can
 also be used in human-usable format (e.g., business cards, user
 interface).  SIPS URIs can even be used in other protocols or
 document formats that allow for including SIPS URIs (e.g., HTML).
 This document specifies that SIPS means that the SIP resource
 designated by the target SIPS URI is to be contacted securely, using
 TLS on each hop between the UAC and the remote UAS (as opposed to
 only to the proxy responsible for the target domain of the Request-
 URI).  It is outside of the scope of this document to specify what
 happens when a SIPS URI identifies a UAS resource that "maps" outside
 the SIP network, for example, to other networks such as the Public
 Switched Telephone Network (PSTN).

4.1. Routing

 SIP and SIPS URIs that are identical except for the scheme itself
 (e.g., sip:alice@example.com and sips:alice@example.com) refer to the
 same resource.  This requirement is implicit in [RFC3261], Section
 19.1, which states that "any resource described by a SIP URI can be
 'upgraded' to a SIPS URI by just changing the scheme, if it is
 desired to communicate with that resource securely".  This does not
 mean that the SIPS URI will necessarily be reachable, in particular,
 if the proxy cannot establish a secure connection to a client or
 another proxy.  This does not suggest either that proxies would
 arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request
 (see Section 5.3).  Rather, it means that when a resource is
 addressable with SIP, it will also be addressable with SIPS.
 For example, consider the case of a UA that has registered with a
 SIPS Contact header field.  If a UAC later addresses a request using
 a SIP Request-URI, the proxy will forward the request addressed to a
 SIP Request-URI to the UAS, as illustrated by message F13 in Sections
 6.3 and in 6.4.  The proxy forwards the request to the UA using a SIP
 Request-URI and not the SIPS Request-URI used in registration.  The
 proxy does this by replacing the SIPS scheme that was used in the

Audet Standards Track [Page 11] RFC 5630 SIPS October 2009

 registered Contact header field binding with a SIP scheme while
 leaving the rest of the URI as is, and then by using this new URI as
 the Request-URI.  If the proxy did not do this, and instead used a
 SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would
 have to include a SIPS Contact header field.  That SIPS Contact
 header field would then force the other UA to use a SIPS Contact
 header field in any mid-dialog request, including the ACK (which
 would not be possible if that UA did not support SIPS).
 This specification mandates that when a proxy is forwarding a
 request, a resource described by a SIPS Request-URI cannot be
 "downgraded" to a SIP URI by changing the scheme, or by sending the
 associated request over a nonsecure link.  If a request needs to be
 rejected because otherwise it would be a "downgrade", the request
 would be rejected with a 480 (Temporarily Unavailable) response
 (potentially with a Warning header with warn-code 380 "SIPS Not
 Allowed").  Similarly, this specification mandates that when a proxy
 is forwarding a request, a resource described by a SIP Request-URI
 cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise
 it would be an "upgrade" only for that hop onwards rather than on all
 hops, and would therefore mislead the UAS).  If a request needs to be
 rejected because otherwise it would be a misleading "upgrade", the
 request would be rejected with a 480 (Temporarily Unavailable)
 response (potentially with a Warning header field with warn-code 381
 "SIPS Required").  See Section 5.3 for more details.
 For example, the sip:bob@example.com and sips:bob@example.com AORs
 refer to the same user "Bob" in the domain "example.com": the first
 URI is the SIP version, and the second one is the SIPS version.  From
 the point of view of routing, requests to either sip:bob@example.com
 or sips:bob@example.com are treated the same way.  When Bob
 registers, it therefore does not really matter if he is using a SIP
 or a SIPS AOR, since they both refer to the same user.  At first
 glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by
 stating that a SIP and a SIPS URI are never equivalent.
 Specifically, it says that they are never equivalent for the purpose
 of comparing bindings in Contact header field URIs in REGISTER
 requests.  The key point is that this statement applies to the
 Contact header field bindings in a registration: it is the
 association of the Contact header field with the AOR that will
 determine whether or not the user is reachable with a SIPS URI.
 Consider this example: if Bob (AOR bob@example.com) registers with a
 SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the
 registrar and the location service then know that Bob is reachable at
 sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.

Audet Standards Track [Page 12] RFC 5630 SIPS October 2009

 If a request is sent to AOR sips:bob@example.com, Bob's proxy will
 route it to Bob at Request-URI sips:bob@bobphone.example.com.  If a
 request is sent to AOR sip:bob@example.com, Bob's proxy will route it
 to Bob at Request-URI sip:bob@bobphone.example.com.
 If Bob wants to ensure that every request delivered to him always be
 transported over TLS, Bob can use [RFC5626] when registering.
 However, if Bob had registered with a SIP Contact header field
 instead of a SIPS Contact header field (e.g.,
 sip:bob@bobphone.example.com), then a request to AOR
 sips:bob@example.com would not be routed to Bob, since there is no
 SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP
 are not allowed.
 See Section 6 for illustrative call flows.

5. Normative Requirements

 This section describes all the normative requirements defined by this
 specification.

5.1. General User Agent Behavior

5.1.1. UAC Behavior

 When presented with a SIPS URI, a UAC MUST NOT change it to a SIP
 URI.  For example, if a directory entry includes a SIPS AOR, the UAC
 is not expected to send requests to that AOR using a SIP Request-URI.
 Similarly, if a user reads a business card with a SIPS URI, it is not
 possible to infer a SIP URI.  If a 3XX response includes a SIPS
 Contact header field, the UAC does not replace it with a SIP Request-
 URI (e.g., by replacing the SIPS scheme with a SIP scheme) when
 sending a request as a result of the redirection.
 As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the
 Request-URI or top Route header field value contains a SIPS URI, the
 Contact header field MUST contain a SIPS URI as well".
 Upon receiving a 416 response or a 480 (Temporarily Unavailable)
 response with a Warning header with warn-code 380 "SIPS Not Allowed",
 a UAC MUST NOT re-attempt the request by automatically replacing the
 SIPS scheme with a SIP scheme as described in [RFC3261], Section
 8.1.3.5, as it would be a security vulnerability.  If the UAC does
 re-attempt the call with a SIP URI, the UAC SHOULD get a confirmation
 from the user to authorize re-initiating the session with a SIP
 Request-URI instead of a SIPS Request-URI.

Audet Standards Track [Page 13] RFC 5630 SIPS October 2009

 When the route set is not empty (e.g., when a service route [RFC3608]
 is returned by the registrar), it is the responsibility of the UAC to
 use a Route header field consisting of all SIPS URIs when using a
 SIPS Request-URI.  Specifically, if the route set included any SIP
 URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing
 the scheme from "sip" to "sips" before sending the request.  This
 allows for configuring or discovering one service route with all SIP
 URIs and allowing sending requests to both SIP and SIPS URIs.
 When the UAC is using a SIP Request-URI, if the route set is not
 empty and the topmost Route header field entry is a SIPS URI with the
 lr parameter, the UAC MUST send the request over TLS (using a SIP
 Request-URI).  If the route is not empty and the Route header field
 entry is a SIPS URI without the lr parameter, the UAC MUST send the
 request over TLS using a SIPS Request-URI corresponding to the
 topmost entry in the route set.
 To emphasize what is already defined in [RFC3261], UAs MUST NOT use
 the "transport=tls" parameter.

5.1.1.1. Registration

 The UAC registers Contacts header fields to either a SIPS or a SIP
 AOR.
 If a UA wishes to be reachable with a SIPS URI, the UA MUST register
 with a SIPS Contact header field.  Requests addressed to that UA's
 AOR using either a SIP or SIPS Request-URI will be routed to that UA.
 This includes UAs that support both SIP and SIPS.  This specification
 does not provide any SIP-based mechanism for a UA to provision its
 proxy to only forward requests using a SIPS Request-URI.  A non-SIP
 mechanism such as a web interface could be used to provision such a
 preference.  A SIP mechanism for provisioning such a preference is
 outside the scope of this specification.
 If a UA does not wish to be reached with a SIPS URI, it MUST register
 with a SIP Contact header field.
 Because registering with a SIPS Contact header field implies a
 binding of both a SIPS Contact and a corresponding SIP Contact to the
 AOR, a UA MUST NOT include both the SIPS and the SIP versions of the
 same Contact header field in a REGISTER request; the UA MUST only use
 the SIPS version in this case.  Similarly, a UA SHOULD NOT register
 both a SIP Contact header field and a SIPS Contact header field in
 separate registrations as the SIP Contact header field would be
 superfluous.  If it does, the second registration replaces the first
 one (e.g., a UA could register first with a SIP Contact header field,
 meaning it does not support SIPS, and later register with a SIPS

Audet Standards Track [Page 14] RFC 5630 SIPS October 2009

 Contact header field, meaning it now supports SIPS).  Similarly, if a
 UA registers first with a SIPS Contact header field and later
 registers with a SIP Contact header field, that SIP Contact header
 field replaces the SIPS Contact header field.
 [RFC5626] can be used by a UA if it wants to ensure that no requests
 are delivered to it without using the TLS connection it used when
 registering.
 If all the Contact header fields in a REGISTER request are SIPS, the
 UAC MUST use SIPS AORs in the From and To header fields in the
 REGISTER request.  If at least one of the Contact header fields is
 not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP
 AORs in the From and To header fields in the REGISTER request.
 To emphasize what is already defined in [RFC3261], UACs MUST NOT use
 the "transport=tls" parameter.

5.1.1.2. SIPS in a Dialog

 If the Request-URI in a request that initiates a dialog is a SIP URI,
 then the UAC needs to be careful about what to use in the Contact
 header field (in case Record-Route is not used for this hop).  If the
 Contact header field was a SIPS URI, it would mean that the UAS would
 only accept mid-dialog requests that are sent over secure transport
 on each hop.  Since the Request-URI in this case is a SIP URI, it is
 quite possible that the UA sending a request to that URI might not be
 able to send requests to SIPS URIs.  If the top Route header field
 does not contain a SIPS URI, the UAC MUST use a SIP URI in the
 Contact header field, even if the request is sent over a secure
 transport (e.g., the first hop could be re-using a TLS connection to
 the proxy as would be the case with [RFC5626]).
 When a target refresh occurs within a dialog (e.g., re-INVITE
 request, UPDATE request), the UAC MUST include a Contact header field
 with a SIPS URI if the original request used a SIPS Request-URI.

5.1.1.3. Derived Dialogs and Transactions

 Sessions, dialogs, and transactions can be "derived" from existing
 ones.  A good example of a derived dialog is one that was established
 as a result of using the REFER method [RFC3515].
 As a general principle, derived dialogs and transactions cannot
 result in an effective downgrading of SIPS to SIP, without the
 explicit authorization of the entities involved.

Audet Standards Track [Page 15] RFC 5630 SIPS October 2009

 For example, when a REFER request is used to perform a call transfer,
 it results in an existing dialog being terminated and another one
 being created based on the Refer-To URI.  If that initial dialog was
 established using SIPS, then the UAC MUST NOT establish a new one
 using SIP, unless there is an explicit authorization given by the
 recipient of the REFER request.  This could be a warning provided to
 the user.  Having such a warning could be useful, for example, for a
 secure directory service application, to warn a user that a request
 may be routed to a UA that does not support SIPS.
 A REFER request can also be used for referring to resources that do
 not result in dialogs being created.  In fact, a REFER request can be
 used to point to resources that are of a different type than the
 original one (i.e., not SIP or SIPS).  Please see [RFC3515], Section
 5.2, for security considerations related to this.
 Other examples of derived dialogs and transactions include the use of
 Third-Party Call Control [RFC3725], the Replaces header field
 [RFC3891], and the Join header field [RFC3911].  Again, the general
 principle is that these mechanisms SHOULD NOT result in an effective
 downgrading of SIPS to SIP, without the proper authorization.

5.1.1.4. GRUU

 When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned
 to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned.
 When a GRUU is obtained through registration, if the Contact header
 field in the REGISTER request contains a SIP URI, the SIP version of
 the GRUU is returned.  If the Contact header field in the REGISTER
 request contains a SIPS URI, the SIPS version of the GRUU is
 returned.
 If the wrong scheme is received in the GRUU (which would be an error
 in the registrar), the UAC SHOULD treat it as if the proper scheme
 was used (i.e., it SHOULD replace the scheme with the proper scheme
 before using the GRUU).

Audet Standards Track [Page 16] RFC 5630 SIPS October 2009

5.1.2. UAS Behavior

 When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
 URI.
 As mandated by [RFC3261], Section 12.1.1:
    If the request that initiated the dialog contained a SIPS URI in
    the Request-URI or in the top Record-Route header field value, if
    there was any, or the Contact header field if there was no Record-
    Route header field, the Contact header field in the response MUST
    be a SIPS URI.
 If a UAS does not wish to be reached with a SIPS URI but only with a
 SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable)
 response.  The UAS SHOULD include a Warning header with warn-code 380
 "SIPS Not Allowed".  [RFC3261], Section 8.2.2.1, states that UASs
 that do not support the SIPS URI scheme at all "SHOULD reject the
 request with a 416 (Unsupported URI scheme) response".
 If a UAS does not wish to be contacted with a SIP URI but instead by
 a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480
 (Temporarily Unavailable) response.  The UAS SHOULD include a Warning
 header with warn-code 381 "SIPS Required".
 It is a matter of local policy for a UAS to accept incoming requests
 addressed to a URI scheme that does not correspond to what it used
 for registration.  For example, a UA with a policy of "always SIPS"
 would address the registrar using a SIPS Request-URI over TLS, would
 register with a SIPS Contact header field, and the UAS would reject
 requests using the SIP scheme with a 480 (Temporarily Unavailable)
 response with a Warning header with warn-code 381 "SIPS Required".  A
 UA with a policy of "best-effort SIPS" would address the registrar
 using a SIPS Request-URI over TLS, would register with a SIPS Contact
 header field, and the UAS would accept requests addressed to either
 SIP or SIPS Request-URIs.  A UA with a policy of "No SIPS" would
 address the registrar using a SIP Request-URI, could use TLS or not,
 would register with a SIP AOR and a SIP Contact header field, and the
 UAS would accept requests addressed to a SIP Request-URI.
 If a UAS needs to reject a request because the URIs are used
 inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact
 header field is a SIP URI), the UAS MUST reject the request with a
 400 (Bad Request) response.
 When a target refresh occurs within a dialog (e.g., re-INVITE
 request, UPDATE request), the UAS MUST include a Contact header field
 with a SIPS URI if the original request used a SIPS Request-URI.

Audet Standards Track [Page 17] RFC 5630 SIPS October 2009

 To emphasize what is already defined in [RFC3261], UASs MUST NOT use
 the "transport=tls" parameter.

5.2. Registrar Behavior

 The UAC registers Contacts header fields to either a SIPS or a SIP
 AOR.  From a routing perspective, it does not matter which one is
 used for registration as they identify the same resource.  The
 registrar MUST consider AORs that are identical except for one having
 the SIP scheme and the other having the SIPS scheme to be equivalent.
 A registrar MUST accept a binding to a SIPS Contact header field only
 if all the appropriate URIs are of the SIPS scheme; otherwise, there
 could be an inadvertent binding of a secure resource (SIPS) to an
 unsecured one (SIP).  This includes the Request-URI and the Contacts
 and all the Path header fields, but does not include the From and To
 header fields.  If the URIs are not of the proper SIPS scheme, the
 registrar MUST reject the REGISTER with a 400 (Bad Request).
 A registrar can return a service route [RFC3608] and impose some
 constraints on whether or not TLS will be mandatory on specific hops.
 For example, if the topmost entry in the Path header field returned
 by the registrar is a SIPS URI, the registrar is telling the UAC that
 TLS is to be used for the first hop, even if the Request-URI is SIP.
 If a UA registered with a SIPS Contact header field, the registrar
 returning a service route [RFC3608] MUST return a service route
 consisting of SIP URIs if the intent of the registrar is to allow
 both SIP and SIPS to be used in requests sent by that client.  If a
 UA registers with a SIPS Contact header field, the registrar
 returning a service route MUST return a service route consisting of
 SIPS URIs if the intent of the registrar is to allow only SIPS URIs
 to be used in requests sent by that UA.

5.2.1. GRUU

 When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through
 registration, the registrar MUST assign both a SIP GRUU and a SIPS
 GRUU.  If the Contact header field in the REGISTER request contains a
 SIP URI, the registrar MUST return the SIP version of the GRUU.  If
 the Contact header field in the REGISTER request contains a SIPS URI,
 the registrar MUST return the SIPS version of the GRUU.

5.3. Proxy Behavior

 Proxies MUST NOT use the last-hop exception of [RFC3261] when
 forwarding or retargeting a request to the last hop.  Specifically,
 when a proxy receives a request with a SIPS Request-URI, the proxy

Audet Standards Track [Page 18] RFC 5630 SIPS October 2009

 MUST only forward or retarget the request to a SIPS Request-URI.  If
 the target UAS had registered previously using a SIP Contact header
 field instead of a SIPS Contact header field, the proxy MUST NOT
 forward the request to the URI indicated in the Contact header field.
 If the proxy needs to reject the request for that reason, the proxy
 MUST reject it with a 480 (Temporarily Unavailable) response.  In
 this case, the proxy SHOULD include a Warning header with warn-code
 380 "SIPS Not Allowed".
 Proxies SHOULD transport requests using a SIP URI over TLS when it is
 possible to set up a TLS connection, or reuse an existing one.
 [RFC5626], for example, allows for re-using an existing TLS
 connection.  Some proxies could have policies that prohibit sending
 any request over anything but TLS.
 When a proxy receives a request with a SIP Request-URI, the proxy
 MUST NOT forward the request to a SIPS Request-URI.  If the target
 UAS had registered previously using a SIPS Contact header field, and
 the proxy decides to forward the request, the proxy MUST replace that
 SIPS scheme with a SIP scheme while leaving the rest of the URI as
 is, and use the resulting URI as the Request-URI of the forwarded
 request.  The proxy MUST use TLS to forward the request to the UAS.
 Some proxies could have a policy of not forwarding at all requests
 using a non-SIPS Request-URI if the UAS had registered using a SIPS
 Contact header field.  If the proxy elects to reject the request
 because it has such a policy or because it is not capable of
 establishing a TLS connection, the proxy MAY reject it with a 480
 (Temporarily Unavailable) response with a Warning header with warn-
 code 381 "SIPS Required".
 If a proxy needs to reject a request because the URIs are used
 inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact
 header field is a SIP URI), the proxy SHOULD use response code 400
 (Bad Request).
 It is RECOMMENDED that the proxy use the outbound proxy procedures
 defined in [RFC5626] for supporting UACs that cannot provide a
 certificate for establishing a TLS connection (i.e., when server-side
 authentication is used).
 When a proxy sends a request using a SIPS Request-URI and receives a
 3XX response with a SIP Contact header field, or a 416 response, or a
 480 (Temporarily Unavailable) response with a Warning header with
 warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse
 on the response.  In this case, the proxy SHOULD forward the best
 response instead of recursing, in order to allow for the UAC to take
 the appropriate action.

Audet Standards Track [Page 19] RFC 5630 SIPS October 2009

 When a proxy sends a request using a SIP Request-URI and receives a
 3XX response with a SIPS Contact header field, or a 480 (Temporarily
 Unavailable) response with a Warning header with warn-code 381 "SIPS
 Required", the proxy MUST NOT recurse on the response.  In this case,
 the proxy SHOULD forward the best response instead of recursing, in
 order to allow for the UAC to take the appropriate action.
 To emphasize what is already defined in [RFC3261], proxies MUST NOT
 use the "transport=tls" parameter.

5.4. Redirect Server Behavior

 Using a redirect server with TLS instead of using a proxy has some
 limitations that have to be taken into account.  Since there is no
 pre-established connection between the proxy and the UAS (such as
 with [RFC5626]), it is only appropriate for scenarios where inbound
 connections are allowed.  For example, it could be used in a server-
 to-server environment (redirect server or proxy server) where TLS
 mutual authentication is used, and where there are no NAT traversal
 issues.  A redirect server would not be able to redirect to an entity
 that does not have a certificate.  A redirect server might not be
 usable if there is a NAT between the server and the UAS.
 When a redirect server receives a request with a SIP Request-URI, the
 redirect server MAY redirect with a 3XX response to either a SIP or a
 SIPS Contact header field.  If the target UAS had registered
 previously using a SIPS Contact header field, the redirect server
 SHOULD return a SIPS Contact header field if it is in an environment
 where TLS is usable (as described in the previous paragraph).  If the
 target UAS had registered previously using a SIP Contact header
 field, the redirect server MUST return a SIP Contact header field in
 a 3XX response if it redirects the request.
 When a redirect server receives a request with a SIPS Request-URI,
 the redirect server MAY redirect with a 3XX response to a SIP or a
 SIPS Contact header field.  If the target UAS had registered
 previously using a SIPS Contact header field, the redirect server
 SHOULD return a SIPS Contact header field if it is in an environment
 where TLS is usable.  If the target UAS had registered previously
 using a SIP Contact header field, the redirect server MUST return a
 SIP Contact header field in a 3XX response if it chooses to redirect;
 otherwise, the UAS MAY reject the request with a 480 (Temporarily
 Unavailable) response with a Warning header with warn-code 380 "SIPS
 Not Allowed".  If a redirect server redirects to a UAS that it has no
 knowledge of (e.g., an AOR in a different domain), the Contact header
 field could be of any scheme.

Audet Standards Track [Page 20] RFC 5630 SIPS October 2009

 If a redirect server needs to reject a request because the URIs are
 used inconsistently (e.g., the Request-URI is a SIPS URI, but the
 Contact header field is a SIP URI), the redirect server SHOULD use
 response code 400 (Bad Request).
 To emphasize what is already defined in [RFC3261], redirect servers
 MUST NOT use the "transport=tls" parameter.

6. Call Flows

 The following diagram illustrates the topology used for the examples
 in this section:
                       example.com       .      example.net
                                         .
                     |-------------|     .    |------------|
                     | Registrar/  |__________|  Proxy  A  |
                     | Auth. Proxy |     .    |  (proxya)  |
                     |    (pb)     |     .    |------------|
                     |-------------|     .          |
                           |             .          |
                           |             .          |
                     |-----------|       .          |
                     |   Edge    |       .          |
                     |  Proxy B  |       .          |
                     |   (eb)    |       .          |
                     |-----------|       .          |
                      /        |         .          |
                     /         |         .          |
                    /          |         .          |
             ______            |         .          |
            |      |         _____       .        _____
            |______|        O / \ O      .       O / \ O
           /_______/         /___\       .        /___\
                                         .
           bob@bobpc      bob@bobphone   .         alice
                               Topology
 In the following examples, Bob has two clients; one is a SIP PC
 client running on his computer, and the other one is a SIP phone.
 The PC client does not support SIPS, and consequently only registers
 with a SIP Contact header field.  The SIP phone however does support
 SIPS and TLS, and consequently registers with a SIPS Contact header
 field.  Both of Bob's devices are going through Edge Proxy B, and
 consequently, they include a Route header field indicating

Audet Standards Track [Page 21] RFC 5630 SIPS October 2009

 eb.example.com.  Edge Proxy B removes the Route header field
 corresponding to itself, and adds itself in a Path header field.  The
 registration process call flow is illustrated in Section 6.1.
 After registration, there are two Contact bindings associated with
 Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and
 sip:bob@bobpc.example.com.
 Alice then calls Bob through her own Proxy A.  Proxy A locates Bob's
 domain example.com.  In this example, that domain is owned by Bob's
 Registrar/Authoritative Proxy B.  Proxy A removes the Route header
 field corresponding to itself, and inserts itself in the Record-Route
 and forwards the request to Registrar/Authoritative Proxy B.
 The following subsections illustrate registration and three examples.
 In the first example (Section 6.2), Alice calls Bob's SIPS AOR.  In
 the second example (Section 6.3), Alice calls Bob's SIP AOR using TCP
 transport.  In the third example (Section 6.4), Alice calls Bob's SIP
 AOR using TLS transport.

6.1. Bob Registers His Contacts

 This flow illustrates the registration process by which Bob's device
 registers.  His PC client (Bob@bobpc) registers with a SIP scheme,
 and his SIP phone (Bob@phone) registers with a SIPS scheme.

Audet Standards Track [Page 22] RFC 5630 SIPS October 2009

                                  (eb)           (pb)
                                  Edge        Registrar/
              Bob@bobpc          Proxy B     Auth. Proxy B
               |                   |               |
               |    REGISTER F1    |               |
               |------------------>|  REGISTER F2  |
               |                   |-------------->|
               |                   |    200 F3     |
               |      200 F4       |<--------------|
               |<------------------|               |
               |                   |               |
               |   Bob@bobphone    |               |
               |      |            |               |
               |      |REGISTER F5 |               |
               |      |----------->|  REGISTER F6  |
               |      |            |-------------->|
               |      |            |    200 F7     |
               |      |   200 F8   |<--------------|
               |      |<-----------|               |
               |      |            |               |
                      Bob Registers His Contacts
 Message details
 F1 REGISTER Bob's PC Client -> Edge Proxy B
 REGISTER sip:pb.example.com SIP/2.0
 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
 Max-Forwards: 70
 To: Bob <sip:bob@example.com>
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Supported: path, outbound
 Route: <sip:eb.example.com;lr>
 Contact: <sip:bob@bobpc.example.com>
    ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
    ;reg-id=1
 Content-Length: 0

Audet Standards Track [Page 23] RFC 5630 SIPS October 2009

 F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
 REGISTER sip:pb.example.com SIP/2.0
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
 Max-Forwards: 69
 To: Bob <sip:bob@example.com>
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Supported: path, outbound
 Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
 Contact: <sip:bob@bobpc.example.com>
    ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
    ;reg-id=1
 Content-Length: 0
 F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
 To: Bob <sip:bob@example.com>;tag=2493K59K9
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Require: outbound
 Supported: path, outbound
 Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
 Contact: <sip:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
    ;reg-id=1
    ;expires=3600
 Date: Mon, 12 Jun 2006 16:43:12 GMT
 Content-Length: 0

Audet Standards Track [Page 24] RFC 5630 SIPS October 2009

 F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
 To: Bob <sip:bob@example.com>;tag=2493K59K9
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Require: outbound
 Supported: path, outbound
 Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
 Contact: <sip:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
    ;reg-id=1
    ;expires=3600
 Date: Thu, 09 Aug 2007 16:43:12 GMT
 Content-Length: 0
 F5 REGISTER Bob's Phone -> Edge Proxy B
 REGISTER sips:pb.example.com SIP/2.0
 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
 Max-Forwards: 70
 To: Bob <sips:bob@example.com>
 From: Bob <sips:bob@example.com>;tag=90210
 Call-ID: faif9a@qwefnwdclk
 CSeq: 12 REGISTER
 Supported: path, outbound
 Route: <sips:eb.example.com;lr>
 Contact: <sips:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
    ;reg-id=1
 Content-Length: 0

Audet Standards Track [Page 25] RFC 5630 SIPS October 2009

 F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
 REGISTER sips:pb.example.com SIP/2.0
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
 Max-Forwards: 69
 To: Bob <sips:bob@example.com>
 From: Bob <sips:bob@example.com>;tag=90210
 Call-ID: faif9a@qwefnwdclk
 CSeq: 12 REGISTER
 Supported: path, outbound
 Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Contact: <sips:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
    ;reg-id=1
 Content-Length: 0
 F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
 To: Bob <sips:bob@example.com>;tag=5150
 From: Bob <sips:bob@example.com>;tag=90210
 Call-ID: faif9a@qwefnwdclk
 CSeq: 12 REGISTER
 Require: outbound
 Supported: path, outbound
 Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Contact: <sips:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
    ;reg-id=1
    ;expires=3600
 Date: Thu, 09 Aug 2007 16:43:50 GMT
 Content-Length: 0

Audet Standards Track [Page 26] RFC 5630 SIPS October 2009

 F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
 To: Bob <sips:bob@example.com>;tag=5150
 From: Bob <sips:bob@example.com>;tag=90210
 Call-ID: faif9a@qwefnwdclk
 CSeq: 12 REGISTER
 Require: outbound
 Supported: path, outbound
 Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Contact: <sips:bob@bobphone.example.com>
    ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
    ;reg-id=1
    ;expires=3600
 Date: Thu, 09 Aug 2007 16:43:50 GMT
 Content-Length: 0

6.2. Alice Calls Bob's SIPS AOR

 Bob's registration has already occurred as per Section 6.1.
 In this first example, Alice calls Bob's SIPS AOR
 (sips:bob@example.com).  Registrar/Authoritative Proxy B consults the
 binding in the registration database, and finds the two Contact
 header field bindings.  Alice had addressed Bob with a SIPS Request-
 URI (sips:bob@example.com), so Registrar/Authoritative Proxy B
 determines that the call needs to be routed only to bobphone (which
 registered using a SIPS Contact header field), and therefore the
 request is only sent to sips:bob@bobphone.example.com, through Edge
 Proxy B.  Both Registrar/Authoritative Proxy B and Edge Proxy B
 insert themselves in the Record-Route.  Bob answers at
 sips:bob@bobphone.example.com.

Audet Standards Track [Page 27] RFC 5630 SIPS October 2009

                         (eb)         (pb)
                         Edge      Registrar/
     Bob@bobpc          Proxy B   Auth. Proxy B   Proxy A     Alice
      |                   |            |            |            |
      |                   |            |            | INVITE F9  |
      |   Bob@bobphone    |            | INVITE F11 |<-----------|
      |      |            | INVITE F13 |<-----------|   100 F10  |
      |      | INVITE F15 |<-----------|   100 F12  |----------->|
      |      |<-----------|   100 F14  |----------->|            |
      |      |   180 F16  |----------->|            |            |
      |      |----------->|   180 F17  |            |            |
      |      |   200 F20  |----------->|   180 F18  |            |
      |      |----------->|   200 F21  |----------->|   180 F19  |
      |      |            |----------->|   200 F22  |----------->|
      |      |            |            |----------->|   200 F23  |
      |      |            |            |            |----------->|
      |      |            |            |            |   ACK F24  |
      |      |            |            |   ACK F25  |<-----------|
      |      |            |   ACK F26  |<-----------|            |
      |      |   ACK F27  |<-----------|            |            |
      |      |<-----------|            |            |            |
      |      |            |            |            |            |
                      Alice Calls Bob's SIPS AOR
 Message details
 F9 INVITE Alice -> Proxy A
 INVITE sips:bob@example.com SIP/2.0
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 Max-Forwards: 70
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Route: <sips:proxya.example.net;lr>
 Contact: <sips:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}

Audet Standards Track [Page 28] RFC 5630 SIPS October 2009

 F10 100 (INVITE) Proxy A -> Alice
 SIP/2.0 100 Trying
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0
 F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
 INVITE sips:bob@example.com SIP/2.0
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 Max-Forwards: 69
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route: <sips:proxya.example.net;lr>
 Contact: <sips:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 100 Trying
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0

Audet Standards Track [Page 29] RFC 5630 SIPS October 2009

 F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
 INVITE sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 Max-Forwards: 68
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
 Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 100 Trying
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0

Audet Standards Track [Page 30] RFC 5630 SIPS October 2009

 F15 INVITE Edge Proxy B -> Bob's phone
 INVITE sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 Max-Forwards: 67
 To: Bob <sips:bob@example.com>
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F16 180 (INVITE) Bob's Phone -> Edge Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 31] RFC 5630 SIPS October 2009

 F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0
 F18 180 Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0
 F19 180 (INVITE) Proxy A -> Alice
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 32] RFC 5630 SIPS October 2009

 F20 200 (INVITE) Bob's Phone -> Edge Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0
 F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 33] RFC 5630 SIPS October 2009

 F22 200 Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0
 F23 200 (INVITE) Proxy A -> Alice
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
 Contact: <sips:bob@bobphone.example.com>
 Content-Length: 0
 F24 ACK Alice -> Proxy A
 ACK sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
 Max-Forwards: 70
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
 Content-Length: 0

Audet Standards Track [Page 34] RFC 5630 SIPS October 2009

 F25 ACK Proxy A -> Registrar/Authoritative Proxy B
 ACK sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
 Max-Forwards: 69
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sips:pb.example.com;lr>,
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
 Content-Length: 0
 F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
 ACK sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
 Max-Forwards: 69
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sips:pb.example.com;lr>,
  <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
 Content-Length: 0
 F27 ACK Proxy B -> Bob's Phone
 ACK sips:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
 Max-Forwards: 68
 To: Bob <sips:bob@example.com>;tag=5551212
 From: Alice <sips:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Content-Length: 0

Audet Standards Track [Page 35] RFC 5630 SIPS October 2009

6.3. Alice Calls Bob's SIP AOR Using TCP

 Bob's registration has already occurred as per Section 6.1.
 In the second example, Alice calls Bob's SIP AOR instead
 (sip:bob@example.com), and she uses TCP as a transport.  Registrar/
 Authoritative Proxy B consults the binding in the registration
 database, and finds the two Contact header field bindings.  Alice had
 addressed Bob with a SIP Request-URI (sip:bob@example.com), so
 Registrar/Authoritative Proxy B determines that the call needs to be
 routed both to bobpc (which registered with a SIP Contact header
 field) and bobphone (which registered with a SIPS Contact header
 field), and therefore the request is forked to
 sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through
 Edge Proxy B.  Note that Registrar/Authoritative Proxy B preserved
 the SIP scheme of the Request-URI instead of replacing it with the
 SIPS scheme of the Contact header field that was used for
 registration.  Both Registrar/Authoritative Proxy B and Edge Proxy B
 insert themselves in the Record-Route.  Bob's phone's policy is to
 accept calls to SIP and SIPS (i.e., "best effort"), so both his PC
 client and his SIP phone ring simultaneously.  Bob answers on his SIP
 phone, and the forked call leg to the PC client is canceled.

Audet Standards Track [Page 36] RFC 5630 SIPS October 2009

                         (eb)         (pb)
                         Edge      Registrar/
     Bob@bobpc          Proxy B   Auth. Proxy B   Proxy A     Alice
      |                   |            |            |            |
      |                   |            |            | INVITE F9  |
      |                   |            | INVITE F11 |<-----------|
      |                   | INVITE F13'|<-----------|   100 F10  |
      |    INVITE F15'    |<-----------|   100 F12  |----------->|
      |<------------------|   100 F14' |----------->|            |
      |     180 F16'      |----------->|            |            |
      |------------------>|   180 F17' |            |            |
      |                   |----------->|  180 F18'  |            |
      |   Bob@bobphone    |            |----------->|   180 F19' |
      |      |            | INVITE F13 |            |----------->|
      |      | INVITE F15 |<-----------|            |            |
      |      |<-----------|   100 F14  |            |            |
      |      |   180 F16  |----------->|            |            |
      |      |----------->|   180 F17  |            |            |
      |      |   200 F20  |----------->|   180 F18  |            |
      |      |----------->|   200 F21  |----------->|   180 F19  |
      |      |            |----------->|   200 F22  |----------->|
      |      |            |            |----------->|   200 F23  |
      |      |            |            |            |----------->|
      |      |            |            |            |   ACK F24  |
      |      |            |            |   ACK F25  |<-----------|
      |      |            |   ACK F26  |<-----------|            |
      |      |   ACK F27  |<-----------|            |            |
      |      |<-----------|            |            |            |
      |                   | CANCEL F26'|            |            |
      |    CANCEL F27'    |<-----------|            |            |
      |<------------------|            |            |            |
      |     200 F28'      |            |            |            |
      |------------------>|   200 F29' |            |            |
      |     487 F30'      |----------->|            |            |
      |------------------>|   487 F31' |            |            |
      |                   |----------->|            |            |
                       Alice Calls Bob's SIP AOR

Audet Standards Track [Page 37] RFC 5630 SIPS October 2009

 Message details
 F9 INVITE Alice -> Proxy A
 INVITE sip:bob@example.com SIP/2.0
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 70
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Route: <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F10 100 (INVITE) Proxy A -> Alice
 SIP/2.0 100 Trying
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0
 F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
 INVITE sip:bob@example.com SIP/2.0
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 69
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route: <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}

Audet Standards Track [Page 38] RFC 5630 SIPS October 2009

 F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 100 Trying
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0
 F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
 INVITE sip:bob@bobpc.example.com SIP/2.0
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 68
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
 Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 100 Trying
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0

Audet Standards Track [Page 39] RFC 5630 SIPS October 2009

 F15' INVITE Edge Proxy B -> Bob's PC Client
 INVITE sip:bob@bobpc.example.com SIP/2.0
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 67
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=963258
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobpc.example.com>
 Content-Length: 0

Audet Standards Track [Page 40] RFC 5630 SIPS October 2009

 F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=963258
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobpc.example.com>
 Content-Length: 0
 F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=963258
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobpc.example.com>
 Content-Length: 0

Audet Standards Track [Page 41] RFC 5630 SIPS October 2009

 F19' 180 (INVITE) Proxy A -> Alice
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=963258
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobpc.example.com>
 Content-Length: 0
 F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
 INVITE sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 68
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 100 Trying
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0

Audet Standards Track [Page 42] RFC 5630 SIPS October 2009

 F15 INVITE Edge Proxy B -> Bob's Phone
 INVITE sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 68
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:alice@alice-1.example.net>
 Content-Type: application/sdp
 Content-Length: {as per SDP}
 {SDP not shown}
 F16 180 (INVITE) Bob's Phone -> Edge Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 43] RFC 5630 SIPS October 2009

 F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0
 F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 44] RFC 5630 SIPS October 2009

 F19 180 (INVITE) Proxy A -> Alice
 SIP/2.0 180 Ringing
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0
 F20 200 (INVITE) Bob's Phone -> Edge Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 45] RFC 5630 SIPS October 2009

 F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0
 F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0

Audet Standards Track [Page 46] RFC 5630 SIPS October 2009

 F23 200 (INVITE) Proxy A -> Alice
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Record-Route:
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
  <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
 Contact: <sip:bob@bobphone.example.com>
 Content-Length: 0
 F24 ACK Alice -> Proxy A
 ACK sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 70
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
  <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
 Content-Length: 0
 F25 ACK Proxy A -> Registrar/Authoritative Proxy B
 ACK sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 69
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sip:pb.example.com;lr>,
        <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
  Content-Length: 0

Audet Standards Track [Page 47] RFC 5630 SIPS October 2009

 F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
 ACK sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 69
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Content-Length: 0
 F27 ACK Proxy B -> Bob's Phone
 ACK sip:bob@bobphone.example.com SIP/2.0
 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 Max-Forwards: 68
 To: Bob <sip:bob@example.com>;tag=5551212
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 ACK
 Content-Length: 0
 F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
 CANCEL sip:bob@bobpc.example.com SIP/2.0
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Max-Forwards: 70
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 CANCEL
 Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
 Content-Length: 0

Audet Standards Track [Page 48] RFC 5630 SIPS October 2009

 F27' CANCEL Edge Proxy B -> Bob's PC Client
 CANCEL sip:bob@bobpc.example.com SIP/2.0
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Max-Forwards: 69
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 CANCEL
 Content-Length: 0
 F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 CANCEL
 Content-Length: 0
 F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 CANCEL
 Content-Length: 0

Audet Standards Track [Page 49] RFC 5630 SIPS October 2009

 F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
 SIP/2.0 487 Request Terminated
 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0
 F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
 SIP/2.0 487 Request Terminated
 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
 To: Bob <sip:bob@example.com>
 From: Alice <sip:alice@example.net>;tag=8675309
 Call-ID: lzksjf8723k@sodk6587
 CSeq: 1 INVITE
 Content-Length: 0

6.4. Alice Calls Bob's SIP AOR Using TLS

 Bob's registration has already occurred as per Section 6.1.
 The third example is identical to the second one, except that Alice
 uses TLS as the transport for her connection to her proxy.  Such an
 arrangement would be common if Alice's UA supported TLS and wanted to
 use a single connection to the proxy (as would be the case when using
 [RFC5626]).  In the example below, Proxy A is also using TLS as a
 transport to communicate with Outbound Proxy B, but it is not
 necessarily the case.
 When using a SIP URI in the Request-URI but TLS as a transport for
 sending the request, the Via field indicates TLS.  The Route header
 field (if present) typically would use a SIP URI (but it could also
 be a SIPS URI).  The Contact header fields and To and From, however
 would also normally indicate a SIP URI.
 The call flow would be exactly as per the second example
 (Section 6.3).  The only difference would be that all the Via header
 fields would use TLS Via parameters.  The URIs would remain SIP URIs
 and not SIPS URIs.

Audet Standards Track [Page 50] RFC 5630 SIPS October 2009

7. Further Considerations

 SIP [RFC3261] itself introduces some complications with using SIPS,
 for example, when Record-Route is not used.  When a SIPS URI is used
 in a Contact header field in a dialog-initiating request and Record-
 Route is not used, that SIPS URI might not be usable by the other
 end.  If the other end does not support SIPS and/or TLS, it will not
 be able to use it.  The last-hop exception is an example of when this
 can occur.  In this case, using Record-Route so that the requests are
 sent through proxies can help in making it work.  Another example is
 that even in a case where the Contact header field is a SIPS URI, no
 Record-Route is used, and the far end supports SIPS and TLS, it might
 still not be possible for the far end to establish a TLS connection
 with the SIP originating end if the certificate cannot be validated
 by the far end.  This could typically be the case if the originating
 end was using server-side authentication as described below, or if
 the originating end is not using a certificate that can be validated.
 TLS itself has a significant impact on how SIPS can be used.  Server-
 side authentication (where the server side provides its certificate
 but the client side does not) is typically used between a SIP end-
 user device acting as the TLS client side (e.g., a phone or a
 personal computer) and its SIP server (proxy or registrar) acting as
 the TLS server side.  TLS mutual authentication (where both the
 client side and the server side provide their respective
 certificates) is typically used between SIP servers (proxies,
 registrars), or statically configured devices such as PSTN gateways
 or media servers.  In the mutual authentication model, for two
 entities to be able to establish a TLS connection, it is required
 that both sides be able to validate each other's certificates, either
 by static configuration or by being able to recurse to a valid root
 certificate.  With server-side authentication, only the client side
 is capable of validating the server side's certificate, as the client
 side does not provide a certificate.  The consequences of all this
 are that whenever a SIPS URI is used to establish a TLS connection,
 it is expected to be possible for the entity establishing the
 connection (the client) to validate the certificate from the server
 side.  For server-side authentication, [RFC5626] is the recommended
 approach.  For mutual authentication, one needs to ensure that the
 architecture of the network is such that connections are made between
 entities that have access to each other's certificates.  Record-Route
 [RFC3261] and Path [RFC3327] are very useful in ensuring that
 previously established TLS connections can be reused.  Other
 mechanisms might also be used in certain circumstances: for example,
 using root certificates that are widely recognized allows for more
 easily created TLS connections.

Audet Standards Track [Page 51] RFC 5630 SIPS October 2009

8. Security Considerations

 Most of this document can be considered to be security considerations
 since it applies to the usage of the SIPS URI.
 The "last-hop exception" of [RFC3261] introduced significant
 potential vulnerabilities in SIP, and it has therefore been
 deprecated by this specification.
 Section 26.4.4 of [RFC3261] describes the security considerations for
 the SIPS URI scheme.  These security considerations also applies
 here, as modified by Appendix A.

9. IANA Considerations

 This specification registers two new warning codes, namely, 380 "SIPS
 Not Allowed" and 381 "SIPS Required".  The warning codes are defined
 as follows, and have been included in the Warning Codes (warn-codes)
 sub-registry of the SIP Parameters registry available from
 http://www.iana.org.
 380  SIPS Not Allowed: The UAS or proxy cannot process the request
      because the SIPS scheme is not allowed (e.g., because there are
      currently no registered SIPS contacts).
 381  SIPS Required: The UAS or proxy cannot process the request
      because the SIPS scheme is required.
 Reference: RFC 5630
 The note in the Warning Codes sub-registry is as follows:
    Warning codes provide information supplemental to the status code
    in SIP response messages.

10. Acknowledgments

 The author would like to thank Jon Peterson, Cullen Jennings,
 Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert
 Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage,
 Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham
 Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell
 for their careful review and input.  Many thanks to Rohan Mahy for
 helping me with the subtleties of [RFC5626].

Audet Standards Track [Page 52] RFC 5630 SIPS October 2009

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 [RFC5626]  Jennings, C., "Managing Client-Initiated Connections in
            the Session Initiation Protocol (SIP)", RFC 5626, October
            2009.

11.2. Informative References

 [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
            Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
            March 1999.
 [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
            (SIP) Extension Header Field for Registering Non-Adjacent
            Contacts", RFC 3327, December 2002.
 [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
            Method", RFC 3515, April 2003.
 [RFC3608]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
            (SIP) Extension Header Field for Service Route Discovery
            During Registration", RFC 3608, October 2003.
 [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
            Camarillo, "Best Current Practices for Third Party Call
            Control (3pcc) in the Session Initiation Protocol (SIP)",
            BCP 85, RFC 3725, April 2004.
 [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
            Protocol (SIP) "Replaces" Header", RFC 3891,
            September 2004.
 [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
            Authenticated Identity Body (AIB) Format", RFC 3893,
            September 2004.

Audet Standards Track [Page 53] RFC 5630 SIPS October 2009

 [RFC3911]  Mahy, R. and D. Petrie, "The Session Initiation Protocol
            (SIP) "Join" Header", RFC 3911, October 2004.
 [RFC4168]  Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
            Stream Control Transmission Protocol (SCTP) as a Transport
            for the Session Initiation Protocol (SIP)", RFC 4168,
            October 2005.
 [RFC4244]  Barnes, M., "An Extension to the Session Initiation
            Protocol (SIP) for Request History Information", RFC 4244,
            November 2005.
 [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
            Authenticated Identity Management in the Session
            Initiation Protocol (SIP)", RFC 4474, August 2006.
 [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
            Agent URIs (GRUU) in the Session Initiation Protocol
            (SIP)", RFC 5627, October 2009.

Audet Standards Track [Page 54] RFC 5630 SIPS October 2009

Appendix A. Bug Fixes for RFC 3261

 In order to support the material in this document, this section makes
 corrections to RFC 3261.
 The last sentence of the fifth paragraph of Section 8.1.3.5 is
 replaced by:
    The client SHOULD retry the request, this time, using a SIP URI
    unless the original Request-URI used a SIPS scheme, in which case
    the client MUST NOT retry the request automatically.
 The fifth paragraph of Section 10.2.1 is replaced by:
    If the Address of Record in the To header field of a REGISTER
    request is a SIPS URI, then the UAC MUST also include only SIPS
    URIs in any Contact header field value in the requests.
 In Section 16.7 on p. 112 describing Record-Route, the second
 paragraph is deleted.
 The last paragraph of Section 19.1 is reworded as follows:
    A SIPS URI specifies that the resource be contacted securely.
    This means, in particular, that TLS is to be used on each hop
    between the UAC and the resource identified by the target SIPS
    URI.  Any resources described by a SIP URI (...)
 In the third paragraph of Section 20.43, the words "the session
 description" in the first sentence are replaced with "SIP".  Later in
 the paragraph, "390" is replaced with "380", and "miscellaneous
 warnings" is replaced with "miscellaneous SIP-related warnings".
 The second paragraph of Section 26.2.2 is reworded as follows:
    (...)  When used as the Request-URI of a request, the SIPS scheme
    signifies that each hop over which the request is forwarded, until
    the request reaches the resource identified by the Request-URI, is
    secured with TLS.  When used by the originator of a request (as
    would be the case if they employed a SIPS URI as the address-of-
    record of the target), SIPS dictates that the entire request path
    to the target domain be so secured.
 The first paragraph of Section 26.4.4 is replaced by the following:
    Actually using TLS on every segment of a request path entails that
    the terminating UAS is reachable over TLS (by registering with a
    SIPS URI as a contact address).  The SIPS scheme implies

Audet Standards Track [Page 55] RFC 5630 SIPS October 2009

    transitive trust.  Obviously, there is nothing that prevents
    proxies from cheating.  Thus, SIPS cannot guarantee that TLS usage
    will be truly respected end-to-end on each segment of a request
    path.  Note that since many UAs will not accept incoming TLS
    connections, even those UAs that do support TLS will be required
    to maintain persistent TLS connections as described in the TLS
    limitations section above in order to receive requests over TLS as
    a UAS.
 The first sentence of the third paragraph of Section 26.4.4 is
 replaced by the following:
    Ensuring that TLS will be used for all of the request segments up
    to the target UAS is somewhat complex.
 The fourth paragraph of Section 26.4.4 is deleted.
 The last sentence of the fifth paragraph of Section 26.4.4 is
 reworded as follows:
    S/MIME or, preferably, [RFC4474] may also be used by the
    originating UAC to help ensure that the original form of the To
    header field is carried end-to-end.
 In the third paragraph of Section 27.2, the phrase "when the failure
 of the transaction results from a Session Description Protocol (SDP)
 (RFC 2327 [1]) problem" is deleted.
 In the fifth paragraph of Section 27.2, "390" is replaced with "380",
 and "miscellaneous warnings" is replaced with "miscellaneous SIP-
 related warnings".

Author's Address

 Francois Audet
 Skype Labs
 EMail: francois.audet@skypelabs.com

Audet Standards Track [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5630.txt · Last modified: 2009/10/21 23:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki