RFC 5630
The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
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.
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
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.
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).
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.
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
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.
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.
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
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.
(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
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
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
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
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.
(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}
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
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
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
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
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
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
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)
