Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5630

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

Pages: 56
Proposed Standard
Updates:  32613608
Part 2 of 3 – Pages 13 to 35
First   Prev   Next

Top   ToC   RFC5630 - Page 13   prevText

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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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   ToC   RFC5630 - 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 page on part 3)

Next Section