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