tech-invite   World Map     

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

RFC 5630

 
 
 

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

Part 2 of 3, p. 13 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
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.

Top      Up      ToC       Page 14 
   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

Top      Up      ToC       Page 15 
   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.

Top      Up      ToC       Page 16 
   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).

Top      Up      ToC       Page 17 
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.

Top      Up      ToC       Page 18 
   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

Top      Up      ToC       Page 19 
   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.

Top      Up      ToC       Page 20 
   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.

Top      Up      ToC       Page 21 
   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

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
                                    (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

Top      Up      ToC       Page 24 
   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

Top      Up      ToC       Page 25 
   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

Top      Up      ToC       Page 26 
   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

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
                           (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}

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
   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

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
   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

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
   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


Next RFC Part