idnits 2.17.00 (12 Aug 2021) /tmp/idnits22870/draft-ietf-sip-sips-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2316. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3608, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2008) is 5201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2261 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP F. Audet 3 Internet-Draft Nortel 4 Updates: 3261, 3608 February 23, 2008 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 26, 2008 9 The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) 10 draft-ietf-sip-sips-08 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 26, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document provides clarifications and guidelines concerning the 44 use of the SIPS URI scheme in the Session Initiation Protocol (SIP). 45 It also makes normative changes to SIP. This document also provides 46 a discussion of possible future steps in specification. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Models for Using TLS in SIP . . . . . . . . . . . . . . . 3 54 3.1.1. Server-Provided Certificate . . . . . . . . . . . . . 3 55 3.1.2. Mutual authentication . . . . . . . . . . . . . . . . 4 56 3.1.3. Using TLS with SIP instead of SIPS . . . . . . . . . . 4 57 3.1.4. Usage of the transport=tls URI Parameter and the 58 TLS Via Parameter . . . . . . . . . . . . . . . . . . 5 59 3.2. Detection of Hop-by-Hop Security . . . . . . . . . . . . . 6 60 3.3. The Problems with the Meaning of SIPS in RFC 3261 . . . . 7 61 4. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Normative Requirements . . . . . . . . . . . . . . . . . . . . 12 64 5.1. General User Agent Behavior . . . . . . . . . . . . . . . 13 65 5.1.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13 66 5.1.2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 16 67 5.2. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 17 68 5.2.1. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 5.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 18 70 5.4. Redirect Server Behavior . . . . . . . . . . . . . . . . . 19 71 6. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 6.1. Bob Registers his Contacts . . . . . . . . . . . . . . . . 22 73 6.2. Alice Calls Bob's SIPS AOR . . . . . . . . . . . . . . . . 26 74 6.3. Alice Calls Bob's SIP AOR using TCP . . . . . . . . . . . 35 75 6.4. Alice Calls Bob's SIP AOR using TLS . . . . . . . . . . . 49 76 7. Further Considerations . . . . . . . . . . . . . . . . . . . . 50 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 51 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 79 10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 51 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 83 12.2. Informational References . . . . . . . . . . . . . . . . . 52 84 Appendix A. Future Steps in Specification . . . . . . . . . . . . 53 85 A.1. Indication of Validity of SIPS . . . . . . . . . . . . . . 53 86 A.2. True End-to-End Encryption of SIP . . . . . . . . . . . . 54 87 A.3. Use of the transport parameter for TLS on a single hop . . 54 88 Appendix B. Bug Fixes for RFC 3261 . . . . . . . . . . . . . . . 54 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 90 Intellectual Property and Copyright Statements . . . . . . . . . . 57 92 1. Introduction 94 The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] is 95 underspecified in SIP [RFC3261] and has been a source of confusion 96 for implementers. 98 This document provides clarifications and guidelines concerning the 99 use of the SIPS URI scheme in the Session Initiation Protocol (SIP). 100 It also makes normative changes to SIP (including both [RFC3261] and 101 [RFC3608]. This document also provides a discussion of possible 102 future steps in specification. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Background 112 3.1. Models for Using TLS in SIP 114 This section describes briefly the usage of TLS in SIP. 116 3.1.1. Server-Provided Certificate 118 In this model, only the TLS server provides a certificate during the 119 TLS handshake. This is applicable only between a UA and a proxy, 120 where the UA is the TLS client and the proxy is the TLS server, and 121 hence the UA uses TLS to authenticate the proxy but the proxy does 122 not use TLS to authenticate the UA. If the proxy needs to 123 authenticate the UA, this can be achieved by SIP HTTP digest 124 authentication. This directionality implies that the TLS connection 125 always needs to be setup by the UA (e.g., during the registration 126 phase). Since SIP allows for requests in both directions (e.g, an 127 incoming call), the UA is expected to keep the TLS connection alive 128 and that connection is expected to be re-used for both incoming and 129 outgoing requests. 131 This solution of having the UA always initiate and keep alive the 132 connection also solves the NAT and firewall problem as it ensures 133 that responses and further requests will always be deliverable on the 134 existing connection. 136 [I-D.ietf-sip-outbound] provides the mechanism for initiating and 137 maintaining outbound connections in a standard interoperable way. 139 3.1.2. Mutual authentication 141 In this model, both the TLS client and the TLS server provide a 142 certificate in the TLS handshake phase. When used between a UA and a 143 proxy (or between two UAs), this implies that a UA is in possession 144 of a certificate. When sending a SIP request when there is not 145 already a suitable TLS connection in place, a UAC takes on the role 146 of TLS client in establishing a new TLS connection. When 147 establishing a TLS connection for receipt of a SIP request, a UAS 148 takes on the role of TLS server. Since in SIP, a UA or a Proxy act 149 both as UAC and UAS depending on if they are sending or receiving 150 requests, the symmetrical nature of mutual TLS is very convenient. 151 This allows for TLS connections to be set-up or torn down at will and 152 does not rely on keeping the TLS connection alive for further 153 requests. 155 However, there are some significant limitations. 157 The first obvious limitation is not with mutual authentication per 158 se, but with the model where the underlying TCP connection can be 159 established by either side, interchangeably, which is not possible in 160 many environments. For examples, NATs and firewalls will often allow 161 TCP connections to be established in one direction only. This 162 includes most residential SIP deployments, for example. Mutual 163 authentication can be used in those environments, but only if the 164 connection is always started by the same side, for example, by using 165 [I-D.ietf-sip-outbound] as described in Section 3.1.1. Having to 166 rely on [I-D.ietf-sip-outbound] in this case negates many of the 167 advantages of mutual authentication. 169 The second significant limitation is that mutual authentication 170 requires both sides to exchange a certificate. This has proven to be 171 impractical in many environments, in particular for SIP UAs, because 172 of the difficulties of setting up a certificate infrastructure for a 173 wide population of users. 175 For these reasons, mutual authentication is mostly used in server-to- 176 server communications (e.g., between SIP proxies, or between proxies 177 and gateways or media servers), and in environments where using 178 certificates on both sides is possible (e.g., high-security devices 179 used within an enterprise). 181 3.1.3. Using TLS with SIP instead of SIPS 183 Because a SIPS URI implies that requests sent to the resource 184 identified by it be sent over each SIP hop over TLS, SIPS URIs are 185 not suitable for "best-effort TLS": they are only suitable for "TLS- 186 only" requests. This is recognized in section [RFC3261]/26.2.2: 188 "Users that distribute a SIPS URI as an address-of-record may 189 elect to operate devices that refuse requests over insecure 190 transports." 192 If one wants to use "best-effort TLS" for SIP, one just needs to use 193 a SIP URI, and send the request over TLS. 195 Using SIP over TLS is very simple. A UA opens a TLS connection and 196 uses SIP URIs instead of SIPS URIs for all the header fields in a SIP 197 message (From, To, Request-URI, Contact header field, Route, etc.). 198 When TLS is used, the Via header field indicates TLS. 200 [RFC3261]/26.3.2.1 states: 202 "When a UA comes online and registers with its local 203 administrative domain, it SHOULD establish a TLS connection with 204 its registrar (...). Once the registration has been accepted by 205 the registrar, the UA SHOULD leave this TLS connection open 206 provided that the registrar also acts as the proxy server to which 207 requests are sent for users in this administrative domain. The 208 existing TLS connection will be reused to deliver incoming 209 requests to the UA that had just completed registration." 211 [I-D.ietf-sip-outbound] describes how to establish and maintain a TLS 212 connection in environments where it can only be initiated by the UA. 214 Similarly, proxies can forward requests using TLS if they can open a 215 TLS connection, even if the route set used SIP URIs instead of SIPS 216 URIs. The proxies can insert Record-Route header fields using SIP 217 URIs even if it uses TLS transport. [RFC3261]/26.3.2.2 explains how 218 interdomain requests can use TLS. 220 Some user agents, redirect servers and proxies might have local 221 policies that enforce TLS on all connections, independently of if 222 SIPS is used or not. 224 3.1.4. Usage of the transport=tls URI Parameter and the TLS Via 225 Parameter 227 [RFC3261]/26.2.2 deprecated the "transport=tls" URI transport 228 parameter in SIPS or SIP URIs: 230 "Note that in the SIPS URI scheme, transport is independent of 231 TLS, and thus "sips:alice@atlanta.com;transport=TCP" and 232 "sips:alice@atlanta.com;transport=sctp" are both valid (although 233 note that UDP is not a valid transport for SIPS). The use of 234 "transport=tls" has consequently been deprecated, partly because 235 it was specific to a single hop of the request. This is a change 236 since RFC 2543." 238 The "tls" parameter has not been eliminated from the ABNF in 239 [RFC3261]/25 since the parameter needs to remain in the ABNF for 240 backward compatibility in order for parsers to be able to process the 241 parameter correctly. The transport=tls parameter has never been 242 defined in an RFC, but only in some of the Internet drafts between 243 [RFC2543] and [RFC3261]. 245 This specification does not make use of the transport=tls parameter. 247 The reinstatement of the transport=tls parameter, or an alternative 248 mechanism for indicating the use of the TLS on a single hop in a URI, 249 are outside the scope of this specification (see Appendix A.3). 251 For Via header fields, the following transport protocol are defined 252 in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- 253 SCTP". 255 3.2. Detection of Hop-by-Hop Security 257 The presence of a SIPS Request-URI does not necessarily indicate that 258 the request was sent securely on each hop. So how does a UAS know if 259 SIPS was used for the entire request path to secure the request end- 260 to-end? Effectively, the UAS cannot know for sure. However, 261 [RFC3261]/26.4.4 recommends how a UAS can make some checks to 262 validate the security. Additionally, the History-Info header field 263 [RFC4244] could be inspected for detecting retargeting from SIP and 264 SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it 265 can leave the receiver of the request with the impression that the 266 request was delivered securily on each hop, while in fact, in was 267 not. 269 To emphasize, all the checking can be circumvented by any proxies or 270 B2BUAs on the path that do not follow the rules and recommendations 271 of this specification and of [RFC3261]. 273 Proxies can have their own policies regarding routing of requests to 274 SIP or SIPS URIs. For example, some proxies in some environment can 275 be configured to only route SIPS URIs. Some proxies can be 276 configured to detect non-compliances and reject un-secure requests. 277 For example, proxies could inspect Request-URIs, Path, Record-Route, 278 To, From, Contact header fields and Via header fields to enforce 279 SIPS. 281 [RFC3261]/26.4.4 explains that S/MIME can also be used by the 282 originating UAC to ensure that the original form of the To header 283 field is carried end-to-end. While not specifically mentioned in 285 [RFC3261]/26.4.4, this is meant to imply that [RFC3893] would be used 286 to "tunnel" important header fields (such as To and From) in an 287 encrypted and signed S/MIME body, replicating the information in the 288 SIP message, and allowing the UAS to validate the content of those 289 important header fields. While this approach is certainly legal, a 290 preferable approach is to use the SIP Identity mechanism defined in 291 [RFC4474]. SIP Identity creates a signed identity digest which 292 includes, amongst other things, the AOR of the sender (from the From 293 header field) and the AOR of the original target (from the To header 294 field). 296 3.3. The Problems with the Meaning of SIPS in RFC 3261 298 [RFC3261]/19.1 describes a SIPS URI as follows: 300 "A SIPS URI specifies that the resource be contacted securely. 301 This means, in particular, that TLS is to be used between the UAC 302 and the domain that owns the URI. From there, secure 303 communications are used to reach the user, where the specific 304 security mechanism depends on the policy of the domain." 306 Section 26.2.2 re-iterates it, with regards to Request-URIs: 308 "When used as the Request-URI of a request, the SIPS scheme 309 signifies that each hop over which the request is forwarded, until 310 the request reaches the SIP entity responsible for the domain 311 portion of the Request-URI, must be secured with TLS; once it 312 reaches the domain in question it is handled in accordance with 313 local security and routing policy, quite possibly using TLS for 314 any last hop to a UAS. When used by the originator of a request 315 (as would be the case if they employed a SIPS URI as the address- 316 of-record of the target), SIPS dictates that the entire request 317 path to the target domain be so secured." 319 Let's take the classic SIP trapezoid to explain the meaning of a 320 sips:b@B URI. Instead of using real domain names like example.com 321 and example.net, logical names like "A" and "B" are used, for 322 clarity. 324 .......................... ........................... 325 . . . . 326 . +-------+ . . +-------+ . 327 . | | . . | | . 328 . | Proxy |-----TLS---- | Proxy | . 329 . | A | . . | B | . 330 . | | . . | | . 331 . / +-------+ . . +-------+ \ . 332 . / . . \ . 333 . / . . \ . 334 . TLS . . Policy-based . 335 . / . . \ . 336 . / . . \ . 337 . / . . \ . 338 . +-------+ . . +-------+ . 339 . | | . . | | . 340 . | UAC a | . . | UAS b | . 341 . | | . . | | . 342 . +-------+ . . +-------+ . 343 . Domain A . . Domain B . 344 .......................... ........................... 346 SIP trapezoid with last hop exception 348 According to [RFC3261], if a@A is sending a request to sips:b@B, the 349 following applies: 350 o TLS is required between UA a@A and Proxy A 351 o TLS is required between Proxy A and Proxy B 352 o TLS is required between Proxy B and UA b@B, depending on local 353 policy. 355 One can then wonder why TLS is mandatory between UA a@A and Proxy A 356 but not between Proxy B and UA b@B. The main reason is that [RFC3261] 357 was written before [I-D.ietf-sip-outbound]. At that time, it was 358 recognized that in many practical deployments, Proxy B might not be 359 able to establish a TLS connection with UA b because only Proxy B 360 would have a certificate to provide and UA b would not. Since UA b 361 would be the TLS Server, it would then not be able to accept the 362 incoming TLS connection. The consequence is that an [RFC3261]- 363 compliant UAS b, while it might not need to support TLS for incoming 364 requests, will nevertheless have to support TLS for outgoing requests 365 as it takes the UAC role. Contrary to what many believed 366 erroneously, the last-hop exception was not created to allow for 367 using a SIPS URI to address a UAS that does not support TLS: the 368 last-hop exception was an attempt to allow for incoming requests to 369 not be transported over TLS when a SIPS URI is used, and it does not 370 apply to outgoing requests. The rationale for this was somewhat 371 flawed, and since then, [I-D.ietf-sip-outbound] has provided a more 372 satisfactory solution to this problem. [I-D.ietf-sip-outbound] also 373 solves the problem that if UA b is behind a NAT or Firewall, proxy B 374 would not even be able to establish a TCP session in the first place. 376 Furthermore, consider the problem of using SIPS inside a dialog. If 377 a@A sends a request to b@B using a SIPS Request-URI, then, according 378 to [RFC3261]/8.1.1.8, "the Contact header field MUST contain a SIPS 379 URI as well". This means that b@B, upon sending a new Request within 380 the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. 381 If there is no Record-Route entry, or if the last Record-Route entry 382 consist of a SIPS URI, this implies that b@B is expected to 383 understand SIPS in the first place, and is required to also support 384 TLS. If the last Record-Route entry however is a sip URI, then b 385 would be able to send requests without using TLS (but b would still 386 have to be able to handle SIPS schemes when parsing the message). In 387 either case, the Request-URI in the request from b@B to B would be a 388 SIPS URI. 390 4. Overview of Operations 392 Because of all the problems described in Section 3.3, this 393 specification deprecates the last hop exception when forwarding a 394 request to the last hop (see Section 5.3). This will ensure that TLS 395 is used on all hops all the way up to the remote target. 397 .......................... ........................... 398 . . . . 399 . +-------+ . . +-------+ . 400 . | | . . | | . 401 . | Proxy |-----TLS---- | Proxy | . 402 . | A | . . | B | . 403 . | | . . | | . 404 . / +-------+ . . +-------+ \ . 405 . / . . \ . 406 . / . . \ . 407 . TLS . . TLS . 408 . / . . \ . 409 . / . . \ . 410 . / . . \ . 411 . +-------+ . . +-------+ . 412 . | | . . | | . 413 . | UAC a | . . | UAS b | . 414 . | | . . | | . 415 . +-------+ . . +-------+ . 416 . Domain A . . Domain B . 417 .......................... ........................... 419 SIP trapezoid without last hop exception 421 The SIPS scheme implies transitive trust. Obviously, there is 422 nothing that prevents proxies from cheating (see [RFC3261]/26.4.4). 423 While SIPS is useful to request that a resource be contacted 424 securely, it is not useful as an indication that a resource was in 425 fact contacted securely. Therefore, it is not appropriate to infer 426 that because an incoming request had a Request-URI (or even a To 427 header field) containing a SIPS URI, that it necessarily guarantees 428 that the request was in fact transmitted securely on each hop. Some 429 have been tempted to believe that the SIPS scheme was equivalent to 430 an HTTPS scheme in the sense that one could provide a visual 431 indication to a user (e.g., a padlock icon) to the effect that the 432 session is secured. This is obviously not the case, and therefore 433 the meaning of a SIPS URI is not to be oversold. There is currently 434 no mechanism to provide an indication of end-to-end security for SIP. 435 Other mechanisms can provide a more concrete indication of some level 436 of security. For example, SIP Identity [RFC4474] provides an 437 authenticated identity mechanism and a domain-to-domain integrity 438 protection mechanism. 440 Some have asked why is SIPS useful in a global open environment such 441 as the Internet, if (when used in a Request-URI) it is not an 442 absolute guarantee that the request will in fact be delivered over 443 TLS on each hop? Why is SIPS any different than just using TLS 444 transport with SIP? The difference is that using a SIPS URI in a 445 Request-URI means that if you are instructing the network to use TLS 446 over each hop, and if it is not possible, to reject the request: 447 i.e., that you would rather have the request fail than have the 448 request delivered without TLS. Just using TLS with a SIP Request-URI 449 instead of a SIPS Request-URI implies a "best-effort" service: the 450 request can but need not be delivered over TLS on each hop. 452 Another common question is why not have a Proxy-Require and Require 453 option tag forcing the use of TLS instead? The answer is that it 454 would only be functionally equivalent to using SIPS in a Request-URI. 455 SIPS URIs however can be used in many other header fields: in Contact 456 for registration, Contact in dialog-creating requests, Route, Record- 457 Route, Path, From, To, Refer-To, Referred-By, etc. SIPS URIs can 458 also be used in human-usable format (e.g., business cards, user 459 interface, etc.). SIPS URIs can even be used in other protocols or 460 document formats that allow for including SIPS URIs (e.g., HTML). 462 This document specifies that SIPS means that the SIP resource 463 designated by the target SIPS URI is to be contacted securely, using 464 TLS on each hop between the UAC and the remote UAS (as opposed to 465 only to the proxy responsible for the target domain of the Request- 466 URI). It is outside of the scope of this document to specify what 467 happens when a SIPS URI identifies a UAS resource that "maps" outside 468 of the SIP network, for example, to other networks such as the PSTN. 470 4.1. Routing 472 SIP and SIPS URIs that are identical except for the scheme itself 473 (e.g., sip:alice@example.com and sips:alice@example.com) refer to the 474 same resource. This requirement is implicit in [RFC3261]/19.1 which 475 states that "Any resource described by a SIP URI can be "upgraded" to 476 a SIPS URI by just changing the scheme, if it is desired to 477 communicate with that resource securely". This does not mean that 478 the SIPS URI will necessarily be reachable, in particular, if the 479 proxy cannot establish a secure connection to a client or another 480 proxy. This does not suggest either that proxies would arbitrarily 481 "upgrade" SIP URIs to SIPS URIs when forwarding a request (see 482 Section 5.3). Rather, it means that when a resource is addressable 483 with SIP, it will also be addressable with SIPS. 485 For example, consider the case of a UA that has registered with a 486 SIPS Contact header field. If a UAC later addresses a request using 487 a SIP Request-URI, the proxy will forward the request addressed to a 488 SIP Request-URI to the UAS, as illustrated by message F13 in 489 Section 6.3 and in Section 6.4. The proxy forwards the request to 490 the UA using a SIP Request-URI and not the SIPS Request-URI used in 491 registration. The proxy does this by replacing the SIPS scheme that 492 was used in the registered Contact header field binding with a SIP 493 scheme while leaving the rest of the URI as is, and then by using 494 this new URI as the Request-URI. If the proxy did not do this, and 495 instead used a SIPS Request-URI, then the response (e.g., a 200 to an 496 INVITE) would have to include a SIPS Contact header field. That SIPS 497 Contact header field would then force the other UA to use a SIPS 498 Contact header field in any mid-dialog request, including the ACK 499 (which would not be possible if that UA did not support SIPS). 501 This specification mandates that when a proxy is forwarding a 502 request, a resource described by a SIPS Request-URI cannot be 503 "downgraded" to a SIP URI by changing the scheme, or by sending the 504 associated request over a non-secure link. If a request needs to be 505 rejected because otherwise it would be a "downgrade", the request 506 would be rejected with a 480 (Temporarily Unavailable) response 507 (potentially with a Warning header with warn-code 380 "SIPS Not 508 Allowed"). Similarly, this specification mandates that when a proxy 509 is forwarding a request, a resource described by a SIP Request-URI 510 cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise 511 it would be an "upgrade" only for that hop onwards rather than on all 512 hops, and would therefore mislead the UAS). If a request needs to be 513 rejected because otherwise it would be a misleading "upgrade", the 514 request would be rejected with a 480 (Temporarily Unavailable) 515 response (potentially with a Warning header field with warn-code 381 516 "SIPS Required"). See Section 5.3 for more details. 518 For example, the sip:bob@example.com and sips:bob@example.com AORs 519 refers to the same user "Bob" in the domain "example.com": the first 520 URI is the SIP version, and the second one is the SIPS version. From 521 the point of view of routing, requests to either sip:bob@example.com 522 and sips:bob@example.com are treated the same way. When Bob 523 registers, it therefore does not really matter if he is using a SIP 524 or a SIPS AOR, since they both refer to the same user. At first 525 glance, section [RFC3261]/19.1.4 seems to contradict this idea by 526 stating that a SIP and a SIPS URI are never equivalent. 527 Specifically, it says that they are never equivalent for the purpose 528 of comparing bindings in Contact header field URIs in REGISTER 529 requests. The key point is that this statement applies to the 530 Contact header field bindings in a registration: it is the 531 association of the Contact header field with the AOR that will 532 determine if the user is reachable or not with a SIPS URI. 534 Consider this example: if Bob (AOR bob@example.com) registers with a 535 SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the 536 registrar and the location service then know that Bob is reachable at 537 sips:bob@bobphone.example.com, and at sip:bob@bobphone.example.com. 538 If a request is sent to AOR sips:bob@example.com, Bob's proxy will 539 route it to Bob at Request-URI sips:bob@bobphone.example.com. If a 540 request is sent to AOR sip:bob@example.com, Bob's proxy will route it 541 to Bob at Request-URI sip:bob@bobphone.example.com. 543 If Bob wants to ensure that every request delivered to him always be 544 transported over TLS, Bob can use [I-D.ietf-sip-outbound] when 545 registering. 547 However, if Bob had registered with a SIP Contact header field 548 instead of a SIPS Contact header field (e.g., 549 sip:bob@bobphone.example.com), then a request to AOR 550 sips:bob@example.com would not be routed to Bob, since there is no 551 SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP 552 are not allowed. 554 See Section 6 for illustrative call flows. 556 5. Normative Requirements 558 This section describes all the normative requirements defined by this 559 specification. 561 5.1. General User Agent Behavior 563 5.1.1. UAC Behavior 565 When presented with a SIPS URI, a UAC MUST NOT change it to a SIP 566 URI. For example, if a directory entry includes a SIPS AOR, the UAC 567 is not expected to send requests to that AOR using a SIP Request-URI. 568 Similarly, if a user reads a business card with a SIPS URI, it is not 569 possible to infer a SIP URI. If a 3XX response includes a SIPS 570 Contact header field, the UAC does not replace it with a SIP Request- 571 URI (e.g., by replacing the SIPS scheme with a SIP scheme) when 572 sending a request as a result of the redirection. 574 As mandated by [RFC3261]/8.1.1.8, in a request, "If the Request-URI 575 or top Route header field value contains a SIPS URI, the Contact 576 header field MUST contain a SIPS URI as well". 578 Upon receiving a 416 response or a 480 (Temporarily Unavailable) 579 response with a Warning header with warn-code 380 "SIPS Not Allowed", 580 a UAC MUST NOT re-attempt the request by automatically replacing the 581 SIPS scheme with a SIP scheme as described in [RFC3261]/8.1.3.5 as it 582 would be a security vulnerability. If the UAC does re-attempt the 583 call with a SIP URI, the UAC SHOULD get a confirmation from the user 584 to authorize re-initiating the session with a SIP Request-URI instead 585 of a SIPS Request-URI. 587 When the route set is not empty (e.g., when a service route [RFC3608] 588 is returned by the registrar), it is the responsibility of the UAC to 589 use a Route header field consisting of all SIPS URIs when using a 590 SIPS Request-URI. Specifically, if the route set included any SIP 591 URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing 592 the scheme from "sip" to "sips" before sending the request. This 593 allows for configuring or discovering one service route with all SIP 594 URIs and allowing sending requests to both SIP and SIPS URIs. 596 When the UAC is using a SIP Request-URI, if the route set is not 597 empty and the topmost Route header field entry is a SIPS URI with the 598 lr parameter, the UAC MUST send the request over TLS (using a SIP 599 Request-URI). If the route is not empty and the Route header field 600 entry is a SIPS URI without the lr parameter, the UAC MUST send the 601 request over TLS using a SIPS Request-URI corresponding to the 602 topmost entry in the route set. 604 To emphasise what is already defined in [RFC3261], UAs MUST NOT use 605 the "transport=tls" parameter. 607 5.1.1.1. Registration 609 The UAC registers Contacts header fields to either a SIPS or a SIP 610 AOR. 612 If a UA wishes to be reachable with a SIPS URI, the UA MUST register 613 with a SIPS Contact header field. Requests addressed to that UA's 614 AOR using either a SIP or SIPS Request-URI will be routed to that UA. 615 This includes UAs that support both SIP and SIPS. This specification 616 does not provide any SIP-based mechanism for a UA to provision its 617 proxy to only forward requests using a SIPS Request-URI. A non-SIP 618 mechanism such as a web interface could be used to provision such a 619 preference. A SIP mechanism for provisioning such a preference is 620 outside the scope of this specification. 622 If a UA does not wish to be reached with a SIPS URI, it MUST register 623 with a SIP Contact header field. 625 Because registering with a SIPS Contact header field implies a 626 binding of both a SIPS Contact and a corresponding SIP Contact to the 627 AOR, a UA MUST NOT include both the SIPS and the SIP version of the 628 same Contact header field in a REGISTER request; the UA MUST only use 629 the SIPS version in this case. Similarly, a UA SHOULD NOT register 630 both a SIP Contact header field and a SIPS Contact header field in 631 separate registrations as the SIP Contact header field would be 632 superfluous. If it does, the second registration replaces the first 633 one (e.g., a UA could register first with a SIP Contact header field 634 - meaning it does not support SIPS- and later register with a SIPS 635 Contact header field (meaning it now supports SIPS). 637 [I-D.ietf-sip-outbound] can be used by a UA if it wants to ensure 638 that no requests are delivered to it without using the TLS connection 639 it used when registering. 641 If all the Contact header fields in a REGISTER request are SIPS, the 642 UAC MUST use SIPS AORs in the From and To header fields in the 643 REGISTER request. If at least one of the Contact header fields is 644 not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP 645 AORs in the From and To header fields in the REGISTER request. 647 To emphasise what is already defined in [RFC3261], UACs MUST NOT use 648 the "transport=tls" parameter. 650 5.1.1.2. SIPS in a Dialog 652 If the Request-URI in a request that initiates a dialog is a SIP URI, 653 then the UAC needs to be careful about what to use in the Contact 654 header field (in case Record-Route is not used for this hop). If the 655 Contact header field was a SIPS URI, it would mean that the UAS would 656 only accept mid-dialog requests that are sent over secure transport 657 on each hop. Since the Request-URI in this case is a SIP URI, it is 658 quite possible that the UA sending a request to that URI might not be 659 able to send requests to SIPS URIs. If the top Route header field 660 does not contain a SIPS URI, the UAC MUST use a SIP URI in the 661 Contact header field, even if the request is sent over a secure 662 transport (e.g., the first hop could be re-using a TLS connection to 663 the proxy as would be the case with [I-D.ietf-sip-outbound]). 665 When a target refresh occurs within a dialog (e.g., re-INVITE 666 request, UPDATE request), the UAC MUST include a Contact header field 667 with a SIPS URI if the original request used a SIPS Request-URI. 669 5.1.1.3. Derived Dialogs and Transactions 671 Sessions, dialogs and transactions can be "derived" from existing 672 ones. A good example of a derived dialog is one that was established 673 as a result of using the REFER method [RFC3515]. 675 As a general principle, derived dialogs and transactions cannot 676 result in an effective downgrading of SIPS to SIP, without the 677 explicit authorization of the entities involved. 679 For example, when a REFER request is used to perform a call transfer, 680 it results in an existing dialog being terminated and another one 681 being created based on the Refer-To URI. If that initial dialog was 682 established using SIPS, then the UAC MUST NOT establish a new one 683 using SIP, unless there is an explicit authorization given by the 684 recipient of the REFER request. This could be a warning provided to 685 the user. Having such a warning could be useful for example for a 686 secure directory service application, resulting in being routed to a 687 UA that does not support SIPS. 689 A REFER request can also be used for referring to resources that do 690 not result in dialogs being created. In fact, a REFER request can be 691 used to point to resources that are of a different type than the 692 original one (i.e., not SIP or SIPS). Please see [RFC3515]/5.2 for 693 security considerations related to this. 695 Other examples of derived dialogs and transactions include the use of 696 Third-Party Call Control [RFC3725], the Replaces header field 697 [RFC3891], and the Join header field [RFC3911]. Again, the general 698 principle is that these mechanism SHOULD NOT result in an effective 699 downgrading of SIPS to SIP, without the proper authorization. 701 5.1.1.4. GRUU 703 When a GRUU [I-D.ietf-sip-gruu] is assigned to an instance ID/AOR 704 pair, both SIP and SIPS GRUUs will be assigned. When a GRUU is 705 obtained through registration, if the Contact header field in the 706 REGISTER request contains a SIP URI, the SIP version of the GRUU is 707 returned. If the Contact header field in the REGISTER request 708 contains a SIPS URI, the SIPS version of the GRUU is returned. 710 If the wrong scheme is received in the GRUU (which would be an error 711 in the registrar), the UAC SHOULD treat it as if the proper scheme 712 was used (i.e., it SHOULD replace the scheme with the proper scheme 713 before using the GRUU). 715 5.1.2. UAS Behavior 717 When presented with a SIPS URI, a UAS MUST NOT change it to a SIP 718 URI. 720 As mandated by [RFC3261]/12.1.1, "If the request that initiated the 721 dialog contained a SIPS URI in the Request-URI or in the top Record- 722 Route header field value, if there was any, or the Contact header 723 field if there was no Record-Route header field, the Contact header 724 field in the response MUST be a SIPS URI". 726 If a UAS does not wish to be reached with a SIPS URI but only with a 727 SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable) 728 response. The UAS SHOULD include a Warning header with warn-code 380 729 "SIPS Not Allowed". [RFC3261]/8.2.2.1 states that UASs that do not 730 support the SIPS URI scheme at all "SHOULD reject the request with a 731 416 (Unsupported URI scheme) response". 733 If a UAS does not wish to be contacted with a SIP URI but instead by 734 a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480 735 (Temporarily Unavailable) response. The UAS SHOULD include a Warning 736 header with warn-code 381 "SIPS Required". 738 It is a matter of local policy for a UAS to accept incoming requests 739 addressed to a URI scheme that does not correspond to what it used 740 for registration. For example, a UA with a policy of "always SIPS" 741 would address the Registrar using a SIPS Request-URI over TLS, would 742 register with a SIPS Contact header field, and the UAS would reject 743 requests using the SIP scheme with a 480 (Temporarily Unavailable) 744 response with a Warning header with warn-code 381 "SIPS Required". A 745 UA with a policy of "best-effort SIPS" would address the Registrar 746 using a SIPS Request-URI over TLS, would register with a SIPS Contact 747 header field, and the UAS would accept requests addressed to either 748 SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" would 749 address the Registrar using a SIP Request-URI, could use TLS or not, 750 would register with a SIP AOR and a SIP Contact header field, and the 751 UAS would accept requests addressed to a SIP Request-URI. 753 If a UAS needs to reject a request because the URIs are used 754 inconsistenty (e.g,, the Request-URI is a SIPS URI, but the Contact 755 header field is a SIP URI), the UAS MUST reject the request with a 756 400 (Bad Request) response. 758 When a target refresh occurs within a dialog (e.g., re-INVITE 759 request, UPDATE request), the UAS MUST include a Contact header field 760 with a SIPS URI if the original request used a SIPS Request-URI. 762 To emphasise what is already defined in [RFC3261], UASa MUST NOT use 763 the "transport=tls" parameter. 765 5.2. Registrar Behavior 767 The UAC registers Contacts header fields to either a SIPS or a SIP 768 AOR. From a routing perspective, it does not matter which one is 769 used for registration as they identify the same resource. The 770 registrar MUST consider AORs that are identical except for one having 771 the SIP scheme and the other having the SIPS scheme to be equivalent. 773 A registrar MUST only accept a binding to a SIPS Contact header field 774 if all the appropriate URIs are of the SIPS scheme, otherwise there 775 could be an inadvertent binding of a secure resource (SIPS) to an 776 unsecured one (SIP). This includes the Request-URI, the Contacts and 777 all the Path header fields, but does not include the From and To 778 header fields. If the URIs are not of the proper SIPS scheme, the 779 registrar MUST reject the REGISTER with a 400 (Bad Request). 781 A registrar can return a service route [RFC3608] and impose some 782 constraints on whether TLS will be mandatory or not on specific hops. 783 For example, if the topmost entry in the Path header field returned 784 by the registrar is a SIPS URI, the registrar is telling the UAC that 785 TLS is to be be used for the first hop, even if the Request-URI is 786 SIP. 788 If a UA registered with a SIPS Contact header field, the registrar 789 returning a service route [RFC3608] MUST return a service route 790 consisting of SIP URIs if the intent of the registrar is to allow 791 both SIP and SIPS to be used in requests sent by that client. If a 792 UA registers with a SIPS Contact header field, the registrar 793 returning a service route MUST return a service route consisting of 794 SIPS URIs if the intent of the registrar is to allow only SIPS URIs 795 to be used in requests sent by that UA. 797 5.2.1. GRUU 799 When a GRUU [I-D.ietf-sip-gruu] is assigned to an instance ID/AOR 800 pair through registration, the registrar MUST assign both a SIP GRUU 801 and a SIPS GRUU. If the Contact header field in the REGISTER request 802 contains a SIP URI, the registrar MUST return the SIP version of the 803 GRUU. If the Contact header field in the REGISTER request contains a 804 SIPS URI, the registrar MUST return the SIPS version of the GRUU. 806 5.3. Proxy Behavior 808 Proxies MUST NOT use the last hop exception of [RFC3261] when 809 forwarding or retargeting a request to the last hop. Specifically, 810 when a proxy receives a request with a SIPS Request-URI, the proxy 811 MUST only forward or retarget the request to a SIPS Request-URI. If 812 the target UAS had registered previously using a SIP Contact header 813 field instead of a SIPS Contact header field, the proxy MUST NOT 814 forward the request to the URI indicated in the Contact header field. 815 If the proxy needs to reject the request for that reason, the proxy 816 MUST reject it with a 480 (Temporarily Unavailable) response. In 817 this case, the proxy SHOULD include a Warning header with warn-code 818 380 "SIPS Not Allowed". 820 Proxies SHOULD transport requests using a SIP URI over TLS when it is 821 possible to set up a TLS connection, or re-use an existing one. 822 [I-D.ietf-sip-outbound] for example, allows for re-using an existing 823 TLS connection. Some proxies could have policies that prohibit 824 sending any request over anything but TLS. 826 When a proxy receives a request with a SIP Request-URI, the proxy 827 MUST NOT forward the request to a SIPS Request-URI. If the target 828 UAS had registered previously using a SIPS Contact header field, and 829 the proxy decides to forward the request, the proxy MUST replace that 830 SIPS scheme with a SIP scheme while leaving the rest of the URI as 831 is, and use the resulting URI as the Request-URI of the forwarded 832 request. The proxy MUST use TLS to forward the request to the UAS. 833 Some proxies could have a policy of not forwarding at all requests 834 using a non-SIPS Request-URI if the UAS had registered using a SIPS 835 Contact header fields. If the proxy elects to reject the request 836 because it has such a policy or because it is not capable of 837 establishing a TLS connection, the proxy MAY reject it with a 480 838 (Temporarily Unavailable) response with a Warning header with warn- 839 code 381 "SIPS Required". 841 If a proxy needs to reject a request because the URIs are used 842 inconsistenty (e.g,, the Request-URI is a SIPS URI, but the Contact 843 header field is a SIP URI), the proxy SHOULD use response code 400 844 (Bad Request). 846 It is RECOMMENDED that the proxy use the outbound proxy procedures 847 defined in [I-D.ietf-sip-outbound] for supporting UACs that cannot 848 provide a certificate for establishing a TLS connection (i.e., when 849 server-side authentication is used). 851 When a proxy sends a request using a SIPS Request-URI and receives a 852 3XX response with a SIP Contact header field, or, a 416 response, or 853 a 480 (Temporarily Unavailable) response with a Warning header with 854 warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse 855 on the response. In this case, the proxy SHOULD forward the best 856 response instead of recursing, in order to allow for the UAC to take 857 the appropriate action. 859 When a proxy sends a request using a SIP Request-URI and receives a 860 3XX response with a SIPS Contact header field, or, a 480 (Temporarily 861 Unavailable) response with a Warning header with warn-code 381 "SIPS 862 Required", the proxy MUST NOT recurse on the response. In this case, 863 the proxy SHOULD forward the best response instead of recursing, in 864 order to allow for the UAC to take the appropriate action. 866 To emphasise what is already defined in [RFC3261], proxies MUST NOT 867 use the "transport=tls" parameter. 869 5.4. Redirect Server Behavior 871 Using a redirect server with TLS instead of using a proxy has some 872 limitations that have to be taken into account. Since there no pre- 873 established connection between the proxy and the UAS (such as with 874 [I-D.ietf-sip-outbound]), it is only appropriate for scenarios where 875 inbound connections are allowed. For example, it could be used in a 876 server to server environment (redirect server or proxy server) where 877 TLS mutual authentication is used, and where there are no NAT 878 traversal issues. A redirect server would not be able to redirect to 879 an entity that does not have a certificate. A redirect server might 880 not be usable if there is a NAT between the server and the UAS. 882 When a redirect server receives a request with a SIP Request-URI, the 883 redirect server MAY redirect with a 3XX response to either a SIP or a 884 SIPS Contact header field. If the target UAS had registered 885 previously using a SIPS Contact header field, the redirect server 886 SHOULD return a SIPS Contact header field if it is in an environment 887 where TLS is usable (as described in the previous paragraph). If the 888 target UAS had registered previously using a SIP Contact header 889 field, the redirect server MUST return a SIP Contact header field in 890 a 3XX response if it redirects the request. 892 When a redirect server receives a request with a SIPS Request-URI, 893 the redirect server MAY redirect with a 3XX response to a SIP or a 894 SIPS Contact header field. If the target UAS had registered 895 previously using a SIPS Contact header field, the redirect server 896 SHOULD return a SIPS Contact header field if it is in an environment 897 where TLS is usable. If the target UAS had registered previously 898 using a SIP Contact header field, the redirect server MUST return a 899 SIP Contact header field in a 3XX response if it chooses to redirect; 900 otherwise the UAS MAY reject the request with a 480 (Temporarily 901 Unavailable) response with a Warning header with warn-code 380 "SIPS 902 Not Allowed". If a redirect server redirects to a UAS that it has no 903 knowledge of (e.g., a AOR in a different domain), the Contact header 904 field could be of any scheme. 906 If a redirect server needs to reject a request because the URIs are 907 used inconsistenty (e.g,, the Request-URI is a SIPS URI, but the 908 Contact header field is a SIP URI), the redirect server SHOULD use 909 response code 400 (Bad Request). 911 To emphasise what is already defined in [RFC3261], redirect servers 912 MUST NOT use the "transport=tls" parameter. 914 6. Call Flows 916 The following diagram illustrates the topology used for the examples 917 in this section: 919 example.com . example.net 920 . 921 |-------------| . |------------| 922 | Registrar/ |__________| Proxy A | 923 | Auth. Proxy | . | (proxya) | 924 | (pb) | . |------------| 925 |-------------| . | 926 | . | 927 | . | 928 |-----------| . | 929 | Edge | . | 930 | Proxy B | . | 931 | (eb) | . | 932 |-----------| . | 933 / | . | 934 / | . | 935 / | . | 936 ______ | . | 937 | | _____ . _____ 938 |______| O / \ O . O / \ O 939 /_______/ /___\ . /___\ 940 . 941 bob@bobpc bob@bobphone . alice 943 Topology 945 In the following examples, Bob has two clients, one is a SIP PC 946 client running on his computer, and the other one is a SIP Phone. 947 The PC client does not support SIPS and consequently only registers 948 with a SIP Contact header field. The SIP phone however does support 949 SIPS and TLS, and consequently registers with a SIPS Contact header 950 field. Both of Bob's devices are going through Edge Proxy B, and 951 consequently, they include a Route header field indicating 952 eb.example.com. Edge Proxy B removes the Route header field 953 corresponding to itself, and adds itself in a Path header field. The 954 registration process call flow is illustrated in Section 6.1. 956 After registration, there are two Contact bindings associated with 957 Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and 958 sip:bob@bobpc.example.com. 960 Alice then calls Bob through her own Proxy A. Proxy A locates Bob's 961 domain example.com. In this example, that domain is owned by Bob's 962 Registrar/Authoritative Proxy B. Proxy A removes the Route header 963 field corresponding to itself, and inserts itself in the Record-Route 964 and forwards the request to Registrar/Authoritative Proxy B. 966 The following subsections illustrates registration and three 967 examples. In the first example (Section 6.2), Alice calls Bob using 968 Bob's SIPS URI. In the second example (Section 6.3), Alice calls 969 Bob's SIP AOR using TCP transport. In the third example 970 (Section 6.4), Alice calls Bob's SIP AOR using TLS transport. 972 6.1. Bob Registers his Contacts 974 This flow illustrates the registration process by which Bob's device 975 registers. His PC client (Bob@bobpc) registers with a SIP scheme and 976 his SIP Phone (Bob@phone) registers with a SIPS scheme. 978 (eb) (pb) 979 Edge Registrar/ 980 Bob@bobpc Proxy B Auth. Proxy B 981 | | | 982 | REGISTER F1 | | 983 |------------------>| REGISTER F2 | 984 | |-------------->| 985 | | 200 F3 | 986 | 200 F4 |<--------------| 987 |<------------------| | 988 | | | 989 | Bob@bobphone | | 990 | | | | 991 | |REGISTER F5 | | 992 | |----------->| REGISTER F6 | 993 | | |-------------->| 994 | | | 200 F7 | 995 | | 200 F8 |<--------------| 996 | |<-----------| | 997 | | | | 999 Bob Registers His Contacts 1001 Message details 1002 F1 REGISTER Bob's PC Client -> Edge Proxy B 1004 REGISTER sip:pb.example.com SIP/2.0 1005 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds 1006 Max-Forwards: 70 1007 To: Bob 1008 From: Bob ;tag=456248 1009 Call-ID: 843817637684230@998sdasdh09 1010 CSeq: 1826 REGISTER 1011 Supported: path, outbound 1012 Route: 1013 Contact: 1014 ;+sip.instance="" 1015 ;reg-id=1 1016 Content-Length: 0 1018 F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B 1020 REGISTER sip:pb.example.com SIP/2.0 1021 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7 1022 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds 1023 Max-Forwards: 69 1024 To: Bob 1025 From: Bob ;tag=456248 1026 Call-ID: 843817637684230@998sdasdh09 1027 CSeq: 1826 REGISTER 1028 Supported: path, outbound 1029 Path: 1030 Contact: 1031 ;+sip.instance="" 1032 ;reg-id=1 1033 Content-Length: 0 1034 F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B 1036 SIP/2.0 200 OK 1037 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7 1038 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds 1039 To: Bob ;tag=2493K59K9 1040 From: Bob ;tag=456248 1041 Call-ID: 843817637684230@998sdasdh09 1042 CSeq: 1826 REGISTER 1043 Require: outbound 1044 Supported: path, outbound 1045 Path: 1046 Contact: 1047 ;+sip.instance="" 1048 ;reg-id=1 1049 ;expires=3600 1050 Date: Mon, 12 Jun 2006 16:43:12 GMT 1051 Content-Length: 0 1053 F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client 1055 SIP/2.0 200 OK 1056 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds 1057 To: Bob ;tag=2493K59K9 1058 From: Bob ;tag=456248 1059 Call-ID: 843817637684230@998sdasdh09 1060 CSeq: 1826 REGISTER 1061 Require: outbound 1062 Supported: path, outbound 1063 Path: 1064 Contact: 1065 ;+sip.instance="" 1066 ;reg-id=1 1067 ;expires=3600 1068 Date: Thu, 09 Aug 2007 16:43:12 GMT 1069 Content-Length: 0 1070 F5 REGISTER Bob's Phone -> Edge Proxy B 1072 REGISTER sips:pb.example.com SIP/2.0 1073 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 1074 Max-Forwards: 70 1075 To: Bob 1076 From: Bob ;tag=90210 1077 Call-ID: faif9a@qwefnwdclk 1078 CSeq: 12 REGISTER 1079 Supported: path, outbound 1080 Route: 1081 Contact: 1082 ;+sip.instance="" 1083 ;reg-id=1 1084 Content-Length: 0 1086 F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B 1088 REGISTER sips:pb.example.com SIP/2.0 1089 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354 1090 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 1091 Max-Forwards: 69 1092 To: Bob 1093 From: Bob ;tag=90210 1094 Call-ID: faif9a@qwefnwdclk 1095 CSeq: 12 REGISTER 1096 Supported: path, outbound 1097 Path: 1098 Contact: 1099 ;+sip.instance="" 1100 ;reg-id=1 1101 Content-Length: 0 1102 F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B 1104 SIP/2.0 200 OK 1105 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354 1106 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 1107 To: Bob ;tag=5150 1108 From: Bob ;tag=90210 1109 Call-ID: faif9a@qwefnwdclk 1110 CSeq: 12 REGISTER 1111 Require: outbound 1112 Supported: path, outbound 1113 Path: 1114 Contact: 1115 ;+sip.instance="" 1116 ;reg-id=1 1117 ;expires=3600 1118 Date: Thu, 09 Aug 2007 16:43:50 GMT 1119 Content-Length: 0 1121 F8 200 (REGISTER) Edge Proxy B -> Bob's Phone 1123 SIP/2.0 200 OK 1124 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 1125 To: Bob ;tag=5150 1126 From: Bob ;tag=90210 1127 Call-ID: faif9a@qwefnwdclk 1128 CSeq: 12 REGISTER 1129 Require: outbound 1130 Supported: path, outbound 1131 Path: 1132 Contact: 1133 ;+sip.instance="" 1134 ;reg-id=1 1135 ;expires=3600 1136 Date: Thu, 09 Aug 2007 16:43:50 GMT 1137 Content-Length: 0 1139 6.2. Alice Calls Bob's SIPS AOR 1141 Bob's registration has already occurred as per Section 6.1. 1143 In this first example, Alice calls Bob's SIPS AOR 1144 (sips:bob@example.com). Registrar/Authoritative Proxy B consults the 1145 binding in the registration database, and finds the two Contact 1146 header field bindings. Alice had addressed Bob with a SIPS Request- 1147 URI (sips:bob@example.com), so Registrar/Authoritative Proxy B 1148 determines that the calls needs to be routed only to bobphone (which 1149 registered using a SIPS Contact header field), and therefore the 1150 request is only sent to sips:bob@bobphone.example.com, through Edge 1151 Proxy B. Both Registrar/Authoritative Proxy B and Edge Proxy B 1152 inserts themselves in the Record-Route. Bob answers at 1153 sips:bob@bobphone.example.com. 1155 (eb) (pb) 1156 Edge Registrar/ 1157 Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice 1158 | | | | | 1159 | | | | INVITE F9 | 1160 | Bob@bobphone | | INVITE F11 |<-----------| 1161 | | | INVITE F13 |<-----------| 100 F10 | 1162 | | INVITE F15 |<-----------| 100 F12 |----------->| 1163 | |<-----------| 100 F14 |----------->| | 1164 | | 180 F16 |----------->| | | 1165 | |----------->| 180 F17 | | | 1166 | | 200 F20 |----------->| 180 F18 | | 1167 | |----------->| 200 F21 |----------->| 180 F19 | 1168 | | |----------->| 200 F22 |----------->| 1169 | | | |----------->| 200 F23 | 1170 | | | | |----------->| 1171 | | | | | ACK F24 | 1172 | | | | ACK F25 |<-----------| 1173 | | | ACK F26 |<-----------| | 1174 | | ACK F27 |<-----------| | | 1175 | |<-----------| | | | 1176 | | | | | | 1178 Alice Calls Bob's SIPS AOR 1180 Message details 1181 F9 INVITE Alice -> Proxy A 1183 INVITE sips:bob@example.com SIP/2.0 1184 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1185 Max-Forwards: 70 1186 To: Bob 1187 From: Alice ;tag=8675309 1188 Call-ID: lzksjf8723k@sodk6587 1189 CSeq: 1 INVITE 1190 Route: 1191 Contact: 1192 Content-Type: application/sdp 1193 Content-Length: {as per SDP} 1194 {SDP not shown} 1196 F10 100 (INVITE) Proxy A -> Alice 1198 SIP/2.0 100 Trying 1199 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1200 To: Bob 1201 From: Alice ;tag=8675309 1202 Call-ID: lzksjf8723k@sodk6587 1203 CSeq: 1 INVITE 1204 Content-Length: 0 1206 F11 INVITE Proxy A -> Registrar/Authoritative Proxy B 1208 INVITE sips:bob@example.com SIP/2.0 1209 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1210 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1211 Max-Forwards: 69 1212 To: Bob 1213 From: Alice ;tag=8675309 1214 Call-ID: lzksjf8723k@sodk6587 1215 CSeq: 1 INVITE 1216 Record-Route: 1217 Contact: 1218 Content-Type: application/sdp 1219 Content-Length: {as per SDP} 1220 {SDP not shown} 1221 F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 1223 SIP/2.0 100 Trying 1224 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1225 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1226 To: Bob 1227 From: Alice ;tag=8675309 1228 Call-ID: lzksjf8723k@sodk6587 1229 CSeq: 1 INVITE 1230 Content-Length: 0 1232 F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 1234 INVITE sips:bob@bobphone.example.com SIP/2.0 1235 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1236 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1237 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1238 Max-Forwards: 68 1239 To: Bob 1240 From: Alice ;tag=8675309 1241 Call-ID: lzksjf8723k@sodk6587 1242 CSeq: 1 INVITE 1243 Route: 1244 1245 Record-Route: , 1246 Contact: 1247 Content-Type: application/sdp 1248 Content-Length: {as per SDP} 1249 {SDP not shown} 1251 F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1253 SIP/2.0 100 Trying 1254 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1255 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1256 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1257 To: Bob 1258 From: Alice ;tag=8675309 1259 Call-ID: lzksjf8723k@sodk6587 1260 CSeq: 1 INVITE 1261 Content-Length: 0 1262 F15 INVITE Edge Proxy B -> Bob's phone 1264 INVITE sips:bob@bobphone.example.com SIP/2.0 1265 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 1266 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1267 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1268 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1269 Max-Forwards: 67 1270 To: Bob 1271 From: Alice ;tag=8675309 1272 Call-ID: lzksjf8723k@sodk6587 1273 CSeq: 1 INVITE 1274 Record-Route: 1275 , 1276 , 1277 Contact: 1278 Content-Type: application/sdp 1279 Content-Length: {as per SDP} 1280 {SDP not shown} 1282 F16 180 (INVITE) Bob's Phone -> Edge Proxy B 1284 SIP/2.0 180 Ringing 1285 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 1286 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1287 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1288 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1289 To: Bob ;tag=5551212 1290 From: Alice ;tag=8675309 1291 Call-ID: lzksjf8723k@sodk6587 1292 CSeq: 1 INVITE 1293 Record-Route: 1294 , 1295 , 1296 Contact: 1297 Content-Length: 0 1298 F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1300 SIP/2.0 180 Ringing 1301 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1302 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1303 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1304 To: Bob ;tag=5551212 1305 From: Alice ;tag=8675309 1306 Call-ID: lzksjf8723k@sodk6587 1307 CSeq: 1 INVITE 1308 Record-Route: 1309 , 1310 , 1311 Contact: 1312 Content-Length: 0 1314 F18 180 Registrar/Authoritative Proxy B -> Proxy A 1316 SIP/2.0 180 Ringing 1317 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1318 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1319 To: Bob ;tag=5551212 1320 From: Alice ;tag=8675309 1321 Call-ID: lzksjf8723k@sodk6587 1322 CSeq: 1 INVITE 1323 Record-Route: 1324 , 1325 , 1326 Contact: 1327 Content-Length: 0 1328 F19 180 (INVITE) Proxy A -> Alice 1330 SIP/2.0 180 Ringing 1331 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1332 To: Bob ;tag=5551212 1333 From: Alice ;tag=8675309 1334 Call-ID: lzksjf8723k@sodk6587 1335 CSeq: 1 INVITE 1336 Record-Route: 1337 , 1338 , 1339 Contact: 1340 Content-Length: 0 1342 F20 200 (INVITE) Bob's Phone -> Edge Proxy B 1344 SIP/2.0 200 OK 1345 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 1346 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1347 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1348 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1349 To: Bob ;tag=5551212 1350 From: Alice ;tag=8675309 1351 Call-ID: lzksjf8723k@sodk6587 1352 CSeq: 1 INVITE 1353 Record-Route: 1354 , 1355 , 1356 Contact: 1357 Content-Length: 0 1358 F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1360 SIP/2.0 200 OK 1361 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 1362 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1363 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1364 To: Bob ;tag=5551212 1365 From: Alice ;tag=8675309 1366 Call-ID: lzksjf8723k@sodk6587 1367 CSeq: 1 INVITE 1368 Record-Route: 1369 , 1370 , 1371 Contact: 1372 Content-Length: 0 1374 F22 200 Registrar/Authoritative Proxy B -> Proxy A 1376 SIP/2.0 200 OK 1377 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 1378 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1379 To: Bob ;tag=5551212 1380 From: Alice ;tag=8675309 1381 Call-ID: lzksjf8723k@sodk6587 1382 CSeq: 1 INVITE 1383 Record-Route: 1384 , 1385 , 1386 Contact: 1387 Content-Length: 0 1388 F23 200 (INVITE) Proxy A -> Alice 1390 SIP/2.0 200 OK 1391 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 1392 To: Bob ;tag=5551212 1393 From: Alice ;tag=8675309 1394 Call-ID: lzksjf8723k@sodk6587 1395 CSeq: 1 INVITE 1396 Record-Route: 1397 , 1398 , 1399 Contact: 1400 Content-Length: 0 1402 F24 ACK Alice -> Proxy A 1404 ACK sips:bob@bobphone.example.com SIP/2.0 1405 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 1406 Max-Forwards: 70 1407 To: Bob ;tag=5551212 1408 From: Alice ;tag=8675309 1409 Call-ID: lzksjf8723k@sodk6587 1410 CSeq: 1 ACK 1411 Route: , , 1412 1413 Content-Length: 0 1415 F25 ACK Proxy A -> Registrar/Authoritative Proxy B 1417 ACK sips:bob@bobphone.example.com SIP/2.0 1418 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy 1419 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 1420 Max-Forwards: 69 1421 To: Bob ;tag=5551212 1422 From: Alice ;tag=8675309 1423 Call-ID: lzksjf8723k@sodk6587 1424 CSeq: 1 ACK 1425 Route: , 1426 1427 Content-Length: 0 1428 F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B 1430 ACK sips:bob@bobphone.example.com SIP/2.0 1431 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2 1432 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy 1433 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 1434 Max-Forwards: 69 1435 To: Bob ;tag=5551212 1436 From: Alice ;tag=8675309 1437 Call-ID: lzksjf8723k@sodk6587 1438 CSeq: 1 ACK 1439 Route: , 1440 1441 Content-Length: 0 1443 F27 ACK Proxy B -> Bob's Phone 1445 ACK sips:bob@bobphone.example.com SIP/2.0 1446 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk 1447 Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2 1448 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy 1449 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 1450 Max-Forwards: 68 1451 To: Bob ;tag=5551212 1452 From: Alice ;tag=8675309 1453 Call-ID: lzksjf8723k@sodk6587 1454 CSeq: 1 ACK 1455 Content-Length: 0 1457 6.3. Alice Calls Bob's SIP AOR using TCP 1459 Bob's registration has already occurred as per Section 6.1. 1461 In the second example, Alice calls Bob's SIP AOR instead 1462 (sip:bob@example.com), and she uses TCP as a transport. Registrar/ 1463 Authoritative Proxy B consults the binding in the registration 1464 database, and finds the two Contact header field bindings. Alice had 1465 addressed Bob with a SIP Request-URI (sip:bob@example.com), so 1466 Registrar/Authoritative Proxy B determines that the calls needs to be 1467 routed both to bobpc (which registered with a SIP Contact header 1468 field) and bobphone (which registered with a SIPS Contact header 1469 field), and therefore the request is forked to 1470 sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through 1471 Edge Proxy B. Note that Registar/Authoritative Proxy B preserved the 1472 SIP scheme of the Request-URI instead of replacing it with the SIPS 1473 scheme of the Contact header field that was used for registration. 1474 Both Registrar/Authoritative Proxy B and Edge Proxy B inserts 1475 themselves in the Record-Route. Bob's phone's policy is to accept 1476 calls to SIP and SIPS (i.e., "best effort") so both his PC Client and 1477 his SIP Phone ring simultaneously. Bob answers on his SIP phone, and 1478 the forked call leg to the PC client is canceled. 1480 (eb) (pb) 1481 Edge Registrar/ 1482 Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice 1483 | | | | | 1484 | | | | INVITE F9 | 1485 | | | INVITE F11 |<-----------| 1486 | | INVITE F13'|<-----------| 100 F10 | 1487 | INVITE F15' |<-----------| 100 F12 |----------->| 1488 |<------------------| 100 F14' |----------->| | 1489 | 180 F16' |----------->| | | 1490 |------------------>| 180 F17' | | | 1491 | |----------->| 180 F18' | | 1492 | Bob@bobphone | |----------->| 180 F19' | 1493 | | | INVITE F13 | |----------->| 1494 | | INVITE F15 |<-----------| | | 1495 | |<-----------| 100 F14 | | | 1496 | | 180 F16 |----------->| | | 1497 | |----------->| 180 F17 | | | 1498 | | 200 F20 |----------->| 180 F18 | | 1499 | |----------->| 200 F21 |----------->| 180 F19 | 1500 | | |----------->| 200 F22 |----------->| 1501 | | | |----------->| 200 F23 | 1502 | | | | |----------->| 1503 | | | | | ACK F24 | 1504 | | | | ACK F25 |<-----------| 1505 | | | ACK F26 |<-----------| | 1506 | | ACK F27 |<-----------| | | 1507 | |<-----------| | | | 1508 | | CANCEL F26'| | | 1509 | CANCEL F27' |<-----------| | | 1510 |<------------------| | | | 1511 | 200 F28' | | | | 1512 |------------------>| 200 F29' | | | 1513 | 487 F30' |----------->| | | 1514 |------------------>| 487 F31' | | | 1515 | |----------->| | | 1517 Alice Calls Bob's SIP AOR 1519 Message details 1520 F9 INVITE Alice -> Proxy A 1522 INVITE sip:bob@example.com SIP/2.0 1523 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1524 Max-Forwards: 70 1525 To: Bob 1526 From: Alice ;tag=8675309 1527 Call-ID: lzksjf8723k@sodk6587 1528 CSeq: 1 INVITE 1529 Route: 1530 Contact: 1531 Content-Type: application/sdp 1532 Content-Length: {as per SDP} 1533 {SDP not shown} 1535 F10 100 (INVITE) Proxy A -> Alice 1537 SIP/2.0 100 Trying 1538 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1539 To: Bob 1540 From: Alice ;tag=8675309 1541 Call-ID: lzksjf8723k@sodk6587 1542 CSeq: 1 INVITE 1543 Content-Length: 0 1545 F11 INVITE Proxy A -> Registrar/Authoritative Proxy B 1547 INVITE sip:bob@example.com SIP/2.0 1548 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1549 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1550 Max-Forwards: 69 1551 To: Bob 1552 From: Alice ;tag=8675309 1553 Call-ID: lzksjf8723k@sodk6587 1554 CSeq: 1 INVITE 1555 Record-Route: 1556 Contact: 1557 Content-Type: application/sdp 1558 Content-Length: {as per SDP} 1559 {SDP not shown} 1560 F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 1562 SIP/2.0 100 Trying 1563 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1564 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1565 To: Bob 1566 From: Alice ;tag=8675309 1567 Call-ID: lzksjf8723k@sodk6587 1568 CSeq: 1 INVITE 1569 Content-Length: 0 1571 F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 1573 INVITE sip:bob@bobpc.example.com SIP/2.0 1574 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1575 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1576 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1577 Max-Forwards: 68 1578 To: Bob 1579 From: Alice ;tag=8675309 1580 Call-ID: lzksjf8723k@sodk6587 1581 CSeq: 1 INVITE 1582 Route: 1583 Record-Route: , 1584 Contact: 1585 Content-Type: application/sdp 1586 Content-Length: {as per SDP} 1587 {SDP not shown} 1589 F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1591 SIP/2.0 100 Trying 1592 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1593 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1594 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1595 To: Bob 1596 From: Alice ;tag=8675309 1597 Call-ID: lzksjf8723k@sodk6587 1598 CSeq: 1 INVITE 1599 Content-Length: 0 1600 F15' INVITE Edge Proxy B -> Bob's PC Client 1602 INVITE sip:bob@bobpc.example.com SIP/2.0 1603 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba 1604 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1605 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1606 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1607 Max-Forwards: 67 1608 To: Bob 1609 From: Alice ;tag=8675309 1610 Call-ID: lzksjf8723k@sodk6587 1611 CSeq: 1 INVITE 1612 Record-Route: 1613 , 1614 , 1615 Contact: 1616 Content-Type: application/sdp 1617 Content-Length: {as per SDP} 1618 {SDP not shown} 1620 F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B 1622 SIP/2.0 180 Ringing 1623 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba 1624 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1625 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1626 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1627 To: Bob ;tag=963258 1628 From: Alice ;tag=8675309 1629 Call-ID: lzksjf8723k@sodk6587 1630 CSeq: 1 INVITE 1631 Record-Route: 1632 , 1633 , 1634 Contact: 1635 Content-Length: 0 1636 F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1638 SIP/2.0 180 Ringing 1639 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1640 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1641 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1642 To: Bob ;tag=963258 1643 From: Alice ;tag=8675309 1644 Call-ID: lzksjf8723k@sodk6587 1645 CSeq: 1 INVITE 1646 Record-Route: 1647 , 1648 , 1649 Contact: 1650 Content-Length: 0 1652 F18' 180 (INVITE) Registar/Authoritative Proxy B -> Proxy A 1654 SIP/2.0 180 Ringing 1655 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1656 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1657 To: Bob ;tag=963258 1658 From: Alice ;tag=8675309 1659 Call-ID: lzksjf8723k@sodk6587 1660 CSeq: 1 INVITE 1661 Record-Route: 1662 , 1663 , 1664 Contact: 1665 Content-Length: 0 1666 F19' 180 (INVITE) Proxy A -> Alice 1668 SIP/2.0 180 Ringing 1669 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1670 To: Bob ;tag=963258 1671 From: Alice ;tag=8675309 1672 Call-ID: lzksjf8723k@sodk6587 1673 CSeq: 1 INVITE 1674 Record-Route: 1675 , 1676 , 1677 Contact: 1678 Content-Length: 0 1680 F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 1682 INVITE sip:bob@bobphone.example.com SIP/2.0 1683 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1684 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1685 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1686 Max-Forwards: 68 1687 To: Bob 1688 From: Alice ;tag=8675309 1689 Call-ID: lzksjf8723k@sodk6587 1690 CSeq: 1 INVITE 1691 Route: 1692 Record-Route: , 1693 Contact: 1694 Content-Type: application/sdp 1695 Content-Length: {as per SDP} 1696 {SDP not shown} 1698 F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1700 SIP/2.0 100 Trying 1701 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1702 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1703 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1704 To: Bob 1705 From: Alice ;tag=8675309 1706 Call-ID: lzksjf8723k@sodk6587 1707 CSeq: 1 INVITE 1708 Content-Length: 0 1709 F15 INVITE Edge Proxy B -> Bob's Phone 1711 INVITE sip:bob@bobphone.example.com SIP/2.0 1712 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 1713 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1714 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1715 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1716 Max-Forwards: 68 1717 To: Bob 1718 From: Alice ;tag=8675309 1719 Call-ID: lzksjf8723k@sodk6587 1720 CSeq: 1 INVITE 1721 Record-Route: 1722 , 1723 , 1724 Contact: 1725 Content-Type: application/sdp 1726 Content-Length: {as per SDP} 1727 {SDP not shown} 1729 F16 180 (INVITE) Bob's Phone -> Edge Proxy B 1731 SIP/2.0 180 Ringing 1732 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 1733 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1734 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1735 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1736 To: Bob ;tag=5551212 1737 From: Alice ;tag=8675309 1738 Call-ID: lzksjf8723k@sodk6587 1739 CSeq: 1 INVITE 1740 Record-Route: 1741 , 1742 , 1743 Contact: 1744 Content-Length: 0 1745 F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1747 SIP/2.0 180 Ringing 1748 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1749 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1750 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1751 To: Bob ;tag=5551212 1752 From: Alice ;tag=8675309 1753 Call-ID: lzksjf8723k@sodk6587 1754 CSeq: 1 INVITE 1755 Record-Route: 1756 , 1757 , 1758 Contact: 1759 Content-Length: 0 1761 F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 1763 SIP/2.0 180 Ringing 1764 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1765 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1766 To: Bob ;tag=5551212 1767 From: Alice ;tag=8675309 1768 Call-ID: lzksjf8723k@sodk6587 1769 CSeq: 1 INVITE 1770 Record-Route: 1771 , 1772 , 1773 Contact: 1774 Content-Length: 0 1775 F19 180 (INVITE) Proxy A -> Alice 1777 SIP/2.0 180 Ringing 1778 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1779 To: Bob ;tag=5551212 1780 From: Alice ;tag=8675309 1781 Call-ID: lzksjf8723k@sodk6587 1782 CSeq: 1 INVITE 1783 Record-Route: 1784 , 1785 , 1786 Contact: 1787 Content-Length: 0 1789 F20 200 (INVITE) Bob's Phone -> Edge Proxy B 1791 SIP/2.0 200 OK 1792 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 1793 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1794 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1795 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1796 To: Bob ;tag=5551212 1797 From: Alice ;tag=8675309 1798 Call-ID: lzksjf8723k@sodk6587 1799 CSeq: 1 INVITE 1800 Record-Route: 1801 , 1802 , 1803 Contact: 1804 Content-Length: 0 1805 F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1807 SIP/2.0 200 OK 1808 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1809 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1810 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1811 To: Bob ;tag=5551212 1812 From: Alice ;tag=8675309 1813 Call-ID: lzksjf8723k@sodk6587 1814 CSeq: 1 INVITE 1815 Record-Route: 1816 , 1817 , 1818 Contact: 1819 Content-Length: 0 1821 F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 1823 SIP/2.0 200 OK 1824 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1825 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1826 To: Bob ;tag=5551212 1827 From: Alice ;tag=8675309 1828 Call-ID: lzksjf8723k@sodk6587 1829 CSeq: 1 INVITE 1830 Record-Route: 1831 , 1832 , 1833 Contact: 1834 Content-Length: 0 1835 F23 200 (INVITE) Proxy A -> Alice 1837 SIP/2.0 200 OK 1838 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1839 To: Bob ;tag=5551212 1840 From: Alice ;tag=8675309 1841 Call-ID: lzksjf8723k@sodk6587 1842 CSeq: 1 INVITE 1843 Record-Route: 1844 , 1845 , 1846 Contact: 1847 Content-Length: 0 1849 F24 ACK Alice -> Proxy A 1851 ACK sip:bob@bobphone.example.com SIP/2.0 1852 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1853 Max-Forwards: 70 1854 To: Bob ;tag=5551212 1855 From: Alice ;tag=8675309 1856 Call-ID: lzksjf8723k@sodk6587 1857 CSeq: 1 ACK 1858 Route: , , 1859 1860 Content-Length: 0 1862 F25 ACK Proxy A -> Registrar/Authoritative Proxy B 1864 ACK sip:bob@bobphone.example.com SIP/2.0 1865 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1866 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1867 Max-Forwards: 69 1868 To: Bob ;tag=5551212 1869 From: Alice ;tag=8675309 1870 Call-ID: lzksjf8723k@sodk6587 1871 CSeq: 1 ACK 1872 Route: , 1873 1874 Content-Length: 0 1876 F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B 1878 ACK sip:bob@bobphone.example.com SIP/2.0 1879 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1880 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1881 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1882 Max-Forwards: 69 1883 To: Bob ;tag=5551212 1884 From: Alice ;tag=8675309 1885 Call-ID: lzksjf8723k@sodk6587 1886 CSeq: 1 ACK 1887 Route: 1888 Content-Length: 0 1890 F27 ACK Proxy B -> Bob's Phone 1892 ACK sip:bob@bobphone.example.com SIP/2.0 1893 Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 1894 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1 1895 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1896 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1897 Max-Forwards: 68 1898 To: Bob ;tag=5551212 1899 From: Alice ;tag=8675309 1900 Call-ID: lzksjf8723k@sodk6587 1901 CSeq: 1 ACK 1902 Content-Length: 0 1904 F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B 1906 CANCEL sip:bob@bobpc.example.com SIP/2.0 1907 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1908 Max-Forwards: 70 1909 To: Bob 1910 From: Alice ;tag=8675309 1911 Call-ID: lzksjf8723k@sodk6587 1912 CSeq: 1 CANCEL 1913 Route: 1914 Content-Length: 0 1915 F27' CANCEL Edge Proxy B -> Bob's PC Client 1917 CANCEL sip:bob@bobpc.example.com SIP/2.0 1918 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba 1919 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1920 Max-Forwards: 69 1921 To: Bob 1922 From: Alice ;tag=8675309 1923 Call-ID: lzksjf8723k@sodk6587 1924 CSeq: 1 CANCEL 1925 Content-Length: 0 1927 F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B 1929 SIP/2.0 200 OK 1930 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba 1931 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1932 To: Bob 1933 From: Alice ;tag=8675309 1934 Call-ID: lzksjf8723k@sodk6587 1935 CSeq: 1 CANCEL 1936 Content-Length: 0 1938 F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B 1940 SIP/2.0 200 OK 1941 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1942 To: Bob 1943 From: Alice ;tag=8675309 1944 Call-ID: lzksjf8723k@sodk6587 1945 CSeq: 1 CANCEL 1946 Content-Length: 0 1947 F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B 1949 SIP/2.0 487 Request Terminated 1950 Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba 1951 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1952 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1953 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1954 To: Bob 1955 From: Alice ;tag=8675309 1956 Call-ID: lzksjf8723k@sodk6587 1957 CSeq: 1 INVITE 1958 Content-Length: 0 1960 F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 1962 SIP/2.0 487 Request Terminated 1963 Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 1964 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet 1965 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 1966 To: Bob 1967 From: Alice ;tag=8675309 1968 Call-ID: lzksjf8723k@sodk6587 1969 CSeq: 1 INVITE 1970 Content-Length: 0 1972 6.4. Alice Calls Bob's SIP AOR using TLS 1974 Bob's registration has already occurred as per Section 6.1. 1976 The third example is identical to the second one, except that Alice 1977 uses TLS as the transport for her connection to her proxy. Such an 1978 arrangement would be common if Alice's UA supported TLS and wanted to 1979 use a single connection to the proxy (as would be the case when using 1980 [I-D.ietf-sip-outbound]). In the example below, Proxy A is also 1981 using TLS as a transport to communicate with Outbound proxy B, but it 1982 is not necessarily the case. 1984 When using a SIP URI in the Request-URI, but TLS as a transport for 1985 sending the request, the Via field indicates TLS. The Route header 1986 field (if present) typically would use a SIP URI (but it could also 1987 be a SIPS URI). The Contact header fields, To and From however would 1988 also normally indicate a SIP URI. 1990 The call flow would be exactly as per the second example 1991 (Section 6.3). The only difference would be that all the Via header 1992 fields would use TLS Via parameters. The URIs would remain SIP URIs 1993 and not SIPS URIs. 1995 7. Further Considerations 1997 SIP [RFC3261] itself introduces some complications with using SIPS, 1998 for example when Record-Route is not used. When a SIPS URI is used 1999 in a Contact header field in a dialog-initiating request and Record- 2000 Route is not used, that SIPS URI might not be usable by the other 2001 end. If the other end does not support SIPS and/or TLS, it will not 2002 be able to use it. The "last-hop exception" is an example of when 2003 this can occur. In this case, using Record-Route so that the 2004 requests are sent through proxies can help in making it work. 2005 Another example is that even in a case where the Contact header field 2006 is a SIPS URI, no Record-Route is used, and the far end supports SIPS 2007 and TLS, it might still not be possible for the far end to establish 2008 a TLS connection with the SIP originating end if the certificate 2009 cannot be validated by the far end. This could typically be the case 2010 if the originating end was using server-side authentication as 2011 described below, or if the originating end is not using a certificate 2012 that can be validated. 2014 TLS itself has a significant impact on how SIPS can be used. 2015 "Server-side authentication" (where the server side provides its 2016 certificate but the client side does not) is typically used between a 2017 SIP end-user device acting as the TLS client side (e.g., a phone or a 2018 personal computer), and its SIP server (proxy or registrar) acting as 2019 the TLS server side. TLS mutual authentication (where both the 2020 client and the server side provide their respective certificates) is 2021 typically used between SIP servers (proxies, registrars), or 2022 statically configured devices such as PSTN gateways or media servers. 2023 In the mutual authentication model, for two entities to be able to 2024 establish a TLS connection, it is required that both sides be able to 2025 validate each other's certificates, either by static configuration or 2026 by being able to recurse to a valid root certificate. With server- 2027 side authentication, only the client side is capable of validating 2028 the server side's certificate, as the client side does not provide a 2029 certificate. The consequences of all this are that whenever a SIPS 2030 URI is used to establish a TLS connection, it is expected to be 2031 possible for the entity establishing the connection (the client) to 2032 validate the certificate from the server side. For server-side 2033 authentication, [I-D.ietf-sip-outbound] is the recommended approach. 2034 For mutual authentication, one needs to ensure that the architecture 2035 of the network is such that connections are made between entities 2036 that have access to each other's certificates. Record-Route 2037 [RFC3261] and Path [RFC3327] are very useful in ensuring that 2038 previously established TLS connections can be re-used. Other 2039 mechanisms might also be used in certain circumstances: for example, 2040 using root certificates that are widely recognized allows for more 2041 easily created TLS connections. 2043 The "last hop exception" introduces significant potential 2044 vulnerabilities in SIP and it has therefore been deprecated by this 2045 specification. 2047 8. Security Considerations 2049 Most of this document can be considered to be security considerations 2050 since it applies to the usage of the SIPS URI. 2052 9. IANA Considerations 2054 This specification registers two new warning codes, namely 380 "No 2055 SIPS Contacts Registered" and 381 "SIPS Required". The warning codes 2056 are defined by the following information, to be included in the Warn- 2057 codes sub-registry under 2058 http://www.iana.org/assignments/sip-parameters. 2060 380 SIPS Not Allowed: The UAS or proxy cannot process the request 2061 because the SIPS scheme is not allowed (e.g., because there are 2062 currently no registered SIPS Contacts). 2064 381 SIPS Required: The UAS or proxy cannot process the request 2065 because the SIPS scheme is required. 2067 Reference: RFC XXX [Note to IANA Editor, please replace with RFC 2068 number of this document] 2070 The note in the Registry name entry for Warning codes on 2071 http://www.iana.org/assignments/sip-parameters should be: 2073 Warning codes provide information supplemental to the status code 2074 in SIP response messages. 2076 10. IAB Considerations 2078 There are no IAB considerations. 2080 11. Acknowledgments 2082 The author would like to thank Jon Peterson, Cullen Jennings, 2083 Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert 2084 Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage, 2085 Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham 2086 Karthabil, Dean Willis, Eric Tremblay, Hans Persson and Ben Campbell 2087 for their careful review and input. Many thanks to Rohan Mahy for 2088 helping me with the subtleties of [I-D.ietf-sip-outbound]. 2090 12. References 2092 12.1. Normative References 2094 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2095 Requirement Levels", BCP 14, RFC 2119, March 1997. 2097 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2098 A., Peterson, J., Sparks, R., Handley, M., and E. 2099 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2100 June 2002. 2102 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2103 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2105 [I-D.ietf-sip-outbound] 2106 Jennings, C. and R. Mahy, "Managing Client Initiated 2107 Connections in the Session Initiation Protocol (SIP)", 2108 draft-ietf-sip-outbound-11 (work in progress), 2109 November 2007. 2111 12.2. Informational References 2113 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 2114 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 2115 March 1999. 2117 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 2118 (SIP) Extension Header Field for Registering Non-Adjacent 2119 Contacts", RFC 3327, December 2002. 2121 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2122 Method", RFC 3515, April 2003. 2124 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 2125 (SIP) Extension Header Field for Service Route Discovery 2126 During Registration", RFC 3608, October 2003. 2128 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 2129 Camarillo, "Best Current Practices for Third Party Call 2130 Control (3pcc) in the Session Initiation Protocol (SIP)", 2131 BCP 85, RFC 3725, April 2004. 2133 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2134 Protocol (SIP) "Replaces" Header", RFC 3891, 2135 September 2004. 2137 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 2138 Authenticated Identity Body (AIB) Format", RFC 3893, 2139 September 2004. 2141 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2142 (SIP) "Join" Header", RFC 3911, October 2004. 2144 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 2145 Stream Control Transmission Protocol (SCTP) as a Transport 2146 for the Session Initiation Protocol (SIP)", RFC 4168, 2147 October 2005. 2149 [RFC4244] Barnes, M., "An Extension to the Session Initiation 2150 Protocol (SIP) for Request History Information", RFC 4244, 2151 November 2005. 2153 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 2154 Authenticated Identity Management in the Session 2155 Initiation Protocol (SIP)", RFC 4474, August 2006. 2157 [I-D.ietf-sip-gruu] 2158 Rosenberg, J., "Obtaining and Using Globally Routable User 2159 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 2160 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 2161 October 2007. 2163 [I-D.gurbani-sip-sipsec] 2164 Gurbani, V., "The SIPSEC Uniform Resource Identifier 2165 (URI)", draft-gurbani-sip-sipsec-01 (work in progress), 2166 June 2007. 2168 Appendix A. Future Steps in Specification 2170 This section is a placeholder for a discussion of possible future 2171 steps in specification, and the pros and cons of making such changes. 2172 Protocol and normative changes to any specifications (such as RFC 2173 3261) resulting from this discussion would be specified in further 2174 documents. 2176 A.1. Indication of Validity of SIPS 2178 Since the presence of a SIPS URI in a Request-URI in an incoming 2179 request currently does not guarantee that SIPS and TLS was indeed 2180 used on every hop along the path, it has been suggested that it would 2181 be useful to define a mechanism for a verifiable assertion that TLS 2182 and SIPS were used on every hop. 2184 A.2. True End-to-End Encryption of SIP 2186 Another suggestion has been to define a mechanism to encrypt SIP end- 2187 to-end. This would require either an peer-to-peer SIP model, or 2188 alternatively a mechanism that allows the encrypted SIP signalling to 2189 be tunnelled through proxies. [I-D.gurbani-sip-sipsec] is an example 2190 of such a mechanism. 2192 A.3. Use of the transport parameter for TLS on a single hop 2194 A way to describe in a URI that TLS is intended to be used on a 2195 specific hop (similar to what transport=tls used to mean) has been 2196 suggested as a possible area for future steps in specification. See 2197 discussion in Section 3.1.4. 2199 Appendix B. Bug Fixes for RFC 3261 2201 The last sentence of the fifth paragraph of 8.1.3.5 is replaced by: 2203 The client SHOULD retry the request, this time, using a SIP URI 2204 unless the original Request-URI used a SIPS scheme, in which case 2205 the client MUST NOT retry the request automatically. 2207 The fifth paragraph of section 10.2.1 is replaced by: 2209 If the address-of-record in the To header field of a REGISTER 2210 request is a SIPS URI, then the UAC MUST also include only SIPS 2211 URIs in any Contact header field value in the requests. 2213 In section 16.7 on p. 112 describing Record-Route, the second 2214 paragraph is deleted. 2216 The last paragraph of section 19.1 is reworded as follows: 2218 A SIPS URI specifies that the resource be contacted securely. 2219 This means, in particular, that TLS is to be used on each hop 2220 between the UAC and the resource identified by the target SIPS 2221 URI. Any resources described by a SIP URI (...) 2223 In the third paragraph of section 20.43, the words "the session 2224 description" in the first sentence are replaced with "SIP". Later in 2225 the paragraph, "390" is replaced with "380", and "miscellaneous 2226 warnings" is replaced with "miscellaneous SIP-related warnings". 2228 The second paragraph of section 26.2.2 is reworded as follows: 2230 (...) When used as the Request-URI of a request, the SIPS scheme 2231 signifies that each hop over which the request is forwarded, until 2232 the request reaches the resource identified by the Request-URI, is 2233 secured with TLS. When used by the originator of a request (as 2234 would be the case if they employed a SIPS URI as the address-of- 2235 record of the target), SIPS dictates that the entire request path 2236 to the target domain be so secured. 2238 The first paragraph of section 26.4.4 is replaced by the following: 2240 Actually using TLS on every segment of a request path entails that 2241 the terminating UAS is reachable over TLS (by registering with a 2242 SIPS URI as a contact address). The SIPS scheme implies 2243 transitive trust. Obviously, there is nothing that prevents 2244 proxies from cheating. Thus SIPS cannot guarantee that TLS usage 2245 will be truly respected end-to-end on each segment of a request 2246 path. Note that since many UAs will not accept incoming TLS 2247 connections, even those UAs that do support TLS will be required 2248 to maintain persistent TLS connections as described in the TLS 2249 limitations section above in order to receive requests over TLS as 2250 a UAS. 2252 The fourth paragraph of section 26.4.4 is deleted. 2254 The last sentence of the fifth paragraph of section 26.4.5 is 2255 reworded as follows: 2257 (...) S/MIME or, preferably, [RFC4474] may also be used (...) 2259 In the third paragraph of section 27.2, the phrase "when the failure 2260 of the transaction results from a Session Description Protocol (SDP) 2261 (RFC 2327 [1]) problem" is deleted. 2263 In the fifth paragraph of section 20.43, "390" is replaced with 2264 "380", and "miscellaneous warnings" is replaced with "miscellaneous 2265 SIP-related warnings". 2267 Author's Address 2269 Francois Audet 2270 Nortel 2271 4655 Great America Parkway 2272 Santa Clara, CA 95054 2273 US 2275 Phone: +1 408 495 2456 2276 Email: audet@nortel.com 2278 Full Copyright Statement 2280 Copyright (C) The IETF Trust (2008). 2282 This document is subject to the rights, licenses and restrictions 2283 contained in BCP 78, and except as set forth therein, the authors 2284 retain all their rights. 2286 This document and the information contained herein are provided on an 2287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2289 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2290 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2291 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2294 Intellectual Property 2296 The IETF takes no position regarding the validity or scope of any 2297 Intellectual Property Rights or other rights that might be claimed to 2298 pertain to the implementation or use of the technology described in 2299 this document or the extent to which any license under such rights 2300 might or might not be available; nor does it represent that it has 2301 made any independent effort to identify any such rights. Information 2302 on the procedures with respect to rights in RFC documents can be 2303 found in BCP 78 and BCP 79. 2305 Copies of IPR disclosures made to the IETF Secretariat and any 2306 assurances of licenses to be made available, or the result of an 2307 attempt made to obtain a general license or permission for the use of 2308 such proprietary rights by implementers or users of this 2309 specification can be obtained from the IETF on-line IPR repository at 2310 http://www.ietf.org/ipr. 2312 The IETF invites any interested party to bring to its attention any 2313 copyrights, patents or patent applications, or other proprietary 2314 rights that may cover technology that may be required to implement 2315 this standard. Please address the information to the IETF at 2316 ietf-ipr@ietf.org. 2318 Acknowledgment 2320 Funding for the RFC Editor function is provided by the IETF 2321 Administrative Support Activity (IASA).