idnits 2.17.1 draft-rosenberg-sip-ua-loose-route-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 849. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 591: '...ases, the home proxy SHOULD treat such...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 25, 2008) is 5936 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) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-10 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-03 == Outdated reference: A later version (-08) exists of draft-ietf-enum-cnam-07 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- 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 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track January 25, 2008 5 Expires: July 28, 2008 7 Applying Loose Routing to Session Initiation Protocol (SIP) User Agents 8 (UA) 9 draft-rosenberg-sip-ua-loose-route-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A key part of the behavior of the Session Initiation Protocol (SIP) 43 is that SIP proxies rewrite the Request-URI as a request moves 44 throughout the network. Over the years, experience has shown this to 45 be problematic. It makes it difficult to use Request URI for service 46 invocation, complicates emergency services, makes it more complex to 47 support aliases, and so on. Architecturally, it confounds the 48 concepts of address and route. This document proposes to change this 49 through a new mechanism called UA loose routing. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 4 58 2.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5 59 2.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 6 60 2.6. Emergency Services . . . . . . . . . . . . . . . . . . . . 6 61 2.7. Freephone Numbers . . . . . . . . . . . . . . . . . . . . 6 62 3. Architectural Roots of the Problem . . . . . . . . . . . . . . 7 63 4. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 8 64 4.1. What about the To header field? . . . . . . . . . . . . . 9 65 4.2. History Info . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Backwards Compatibility Considerations . . . . . . . . . . . . 12 68 7. Minting AORs and GRUU . . . . . . . . . . . . . . . . . . . . 13 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction 80 A key part of the behavior of proxy servers in the Session Initiation 81 Protocol (SIP) [RFC3261] is that they rewrite the Request-URI of 82 requests as the request moves from the User Agent Client (UAC) to the 83 User Agent Server (UAS). This is particularly true for requests 84 outside of a dialog; requests within a dialog have their path 85 dictated primarily by the Route header fields established by the 86 Record-Routes when the dialog was initiated. 88 The most basic instance of this behavior is the processing executed 89 by the "home proxy" within a domain. The home proxy is the proxy 90 server within a domain which accesses the location information 91 generated by REGISTER messages, and uses it to forward a request 92 towards a UAC. Based on the rules in RFC 3261, when a home proxy 93 receives a SIP request, it looks up the Request-URI in the location 94 database, and translates it to the contact(s) that were registered by 95 the UA. This new contact URI replaces the existing Request URI, and 96 causes the request to be forwarded towards the target UA. 97 Consequently, the original contents of the Request URI are lost. 99 In addition to routing of SIP requests based on the contents of the 100 location database, proxies can employ other techniques. It is common 101 in practice to have proxies which perform prefix and number analysis 102 on the Request URI against configured tables in order to do routing. 103 It is also common practice to rewrite the Request-URI to point to an 104 application server, again based on configured mappings. 106 Over the years, this practice of rewriting the Request-URI has proven 107 problematic. Section 2 describes the problems with this mechanism. 108 Section 3 analyzes the architectural issues which drive these 109 problems. Section 4 discusses alternative solutions. Section 5 110 describes a proposed solution to this problem, a technique coined 'UA 111 loose routing'. [[OPEN ISSUE: A better name is needed here, since 112 the mechanism applies equally well to targeting proxies.]] 114 2. Problem Statement 116 Several problems arise from the practice of rewriting the request 117 URI. 119 2.1. Unknown Aliases 121 SIP user agents are associated with an address-of-record (AOR). It 122 is possible for a single UA to actually have multiple AOR associated 123 with it. One common usage for this is aliases. For example, a user 124 might have an AOR of sip:john@example.com but also have the AORs 125 sip:john.smith@example.com and sip:jsmith@example.com. Rather than 126 registering against each of these AORs individually, the user would 127 register against just one of them, and the home proxy would 128 automatically accept incoming calls for any of the aliases, treating 129 them identically and ultimately forwarding them towards the UA. This 130 is common practice in the Internet Multimedia Subsystem (IMS), where 131 it is called implicit registrations and each alias is called a public 132 identity. 134 It is a common requirement for a UAS, on receipt of a call, to desire 135 to know which of its aliases was used to reach it. This knowledge 136 can be used to choose ringtones to play, determine call treatment, 137 and so on. For example, a user might give out one alias to friends 138 and family only, resulting in a special ring that alerts the user to 139 the importance of the call. 141 However, based on the procedures in RFC 3261, when an incoming call 142 hits the home proxy, the request URI (which contains the alias) is 143 rewritten to the registered contact(s). Consequently, the alias that 144 was used is lost, and cannot be known to the UAS. 146 2.2. Unknown GRUU 148 A variation on the problem in Section 2.1 occurs with Globally 149 Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu]. A GRUU is a URI 150 assigned to a UA instance which has many of the same properties as 151 the AOR, but causes requests to be routed only to that specific 152 instance. It is desirable for a UA to know whether it was reached 153 because a correspondent sent a request to its GRUU or to its AOR. 154 This can be used to drive differing authorization policies on whether 155 the request should be accepted or rejected, for example. However, 156 like the AOR itself, the GRUU is lost in translation at the home 157 proxy. Thus, the UAS cannot know whether it was contacted via the 158 GRUU or its AOR. 160 2.3. Limited Use Addresses 162 A limited use address is an SIP URI that is minted on-demand, and 163 passed out to a small number (usually one) remote correspondent. 164 Incoming calls targeted to that limited use address are accepted as 165 long as the UA still desires communications from the remote target. 166 Should they no longer wish to be bothered by that remote 167 correspondent, the URI is invalidated so that future requests 168 targeted to it are rejected. 170 Limited use addresses are used in battling voice spam 171 [I-D.ietf-sipping-spam]. The easiest way to provide them would be 172 for a UA to be able to take its AOR, and "mint" a limited use address 173 by appending additional parameters to the URI. It could then give 174 out the URI to a particular correspondent, and remember that URI 175 locally. When an incoming call arrives, the UAS would examine the 176 parameter in the URI and determine whether or not the call should be 177 accepted. Alternatively, the UA could push authorization rules into 178 the network, so that it need not even see incoming requests that are 179 to be rejected. 181 This approach, especially when executed on the UA, requires that 182 parameters attached to the AOR, but not used by the home proxy in 183 processing the request, will survive the translation at the home 184 proxy and be presented to the UA. This will not be the case with the 185 logic in RFC 3261, since the Request-URI is replaced by the 186 registered contact, and any such parameters are lost. 188 2.4. Sub-Addressing 190 Sub-Addressing is very similar to limited use addresses. Sub- 191 addresses are addresses within a subdomain that are multiplexed into 192 a single address within a parent domain. The concept is best 193 illustrated by example. Consider a VoIP service provided to 194 consumers. A consumer obtains a single address from its provider, 195 say sip:family@example.com. However, Joe is the patriarch of a 196 family with four members, and would like to be able to have a 197 separate identifier for each member of his family. One way to do 198 that, without requiring Joe to purchase new addresses for each member 199 from the provider, is for Joe to mint additional URI by adding a 200 parameter to the AOR. For example, his wife Judy with have the URI 201 sip:family@example.com;member=judy, and Joe himself would have the 202 URI sip:family@example.com;member=joe. The SIP server provider would 203 receive requests to these URI, and ignoring the unknown parameters 204 (as required by RFC 3261) route the request to the registered 205 contact, which corresponds to a SIP server in Joes home. That 206 server, in turn, can examine the URI parameters and determine which 207 phone in the home to route the call to. 209 This feature is not specific to VoIP, and has existing in Integrated 210 Services Digital Networking (ISDN) for some time. It is particularly 211 useful for small enterprises, in addition to families. It is also 212 similar in spirit (though not mechanism) to the ubiquitous home 213 routers used by consumers, which allow multiple computers in the home 214 to "hide" behind the single IP address provided by the service 215 provider, by using the TCP and UDP port as a sub-address. 217 The sub-addressing feature is not currently feasible in SIP because 218 of the fact that any SIP URI parameter used to convey the sub-address 219 would be lost at the home proxy, due to the fact that the Request-URI 220 is rewritten there. 222 2.5. Service Invocation 224 Several SIP specifications have been developed which make use of 225 complex URIs to address services within the network rather than 226 subscribers. The URIs are complex because they contain numerous 227 parameters that control the behavior of the service. Examples of 228 this include the specification which first introduced the concept, 229 RFC 3087 [RFC3087], control of network announcements and IVR with SIP 230 URI [RFC4240], and control of voicemail access with SIP URI 231 [RFC4458]. 233 A common problem with all of these mechanisms is that once a proxy 234 has decided to rewrite the Request-URI to point to the service, it 235 cannot be sure that the Request-URI will not be destroyed by a 236 downstream proxy which decides to forward the request in some way, 237 and does so by rewriting the Request-URI. 239 2.6. Emergency Services 241 Another problem that arises from Request-URI rewriting is with 242 emergency services for VoIP. A key requirement of systems supporting 243 emergency calling is that the SIP INVITE request for an emergency 244 call be 'marked' in some way that makes it clear that it is an 245 emergency call, so that it can receive priority treatment 246 [I-D.ietf-ecrit-requirements]. However, such a marking needs to be 247 done in a way that it cannot be abused by attackers seeking to get 248 special treatment for non-emergency calls. The solution for this is 249 that the marking needs to be the target address of the request 250 itself, which would unambiguously identify an emergency services 251 calltaker as the target. The solution that has been agreed upon is 252 the SOS URN [I-D.ietf-ecrit-service-urn] which takes the form 253 urn:service:sos. This URI appears the in the Request-URI of the 254 request emitted by the UA making the emergency services call, and 255 needs to remain in the Request-URI as the request is routed towards 256 the correct emergency services center (ESC) and eventually the target 257 call taker [I-D.ietf-ecrit-framework]. 259 This mechanism will not work if any of the proxies along the way try 260 to rewrite the Request-URI for the purposes of directing the call to 261 a proxy or UA that will handle the call. 263 2.7. Freephone Numbers 265 Freephone numbers, also known as 800 or 8xx numbers in the United 266 States, are telephone numbers that are free for users to call 267 (although the author will note that such notions are becoming less 268 important as billing models evolve, and harken back to an era where 269 phone service depended on global agreement on such billing concepts). 271 In the telephone network, freephone numbers are just aliases to 272 actual numbers which are used for routing of the call. In order to 273 process the call in the PSTN, a switch will perform a query (using a 274 protocol called TCAP), which will return either a phone number or the 275 identity of a carrier which can handle the call. 277 There has been recent work on allowing such PSTN translation services 278 to be accessed by SIP proxy servers through IP querying mechanisms. 279 ENUM, for example [RFC3761] has already been proposed as a mechanism 280 for performing Local Number Portability (LNP) queries [RFC4769], and 281 recently been proposed for performing calling name queries 282 [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a 283 logical next-step. 285 Once such a translation has been performed, the call needs to be 286 routed towards the target of the request. Normally, this would 287 happen by selecting a PSTN gateway which is a good route towards the 288 translated number. However, one can imagine all-IP systems where the 289 8xx numbers are SIP endpoints on an IP network, in which case the 290 translation of the 8xx number would actually be a SIP URI and not a 291 phone number. Assuming for the moment it is a PSTN connected entity, 292 the call would be routed towards a PSTN gateway. Proper treatment of 293 the call in the PSTN (and in particular, correct reconciliation of 294 billing records) requires that the call be marked with both the 295 original 8xx number AND the target number for the call. However, in 296 our example here, since the translation was performed by a SIP proxy 297 upstream from the gateway, the original 8xx number would have been 298 lost, and the call will not interwork properly with the PSTN. 300 Similar problems arise with other "special" numbers and services used 301 in the PSTN, such as operator services, pay numbers (9xx numbers in 302 the U.S), and short service codes such as 311. 304 3. Architectural Roots of the Problem 306 There is a common theme across all of the problems in Section 2, and 307 this theme is the confounding of names, routes, and addresses. 309 A name is a moniker for an entity which refers to it in a way which 310 reveals nothing about where it is in a network. On the Internet, 311 names are ideally provided through Universal Resource Names (URNs). 312 In the problem cases above, the SOS URN and 8xx numbers are examples 313 of names. An address is an identifier for an entity which describes 314 it by its location on the network. In SIP, the SIP URI itself is a 315 form of address because the host part of the URI, the only mandatory 316 part of the URI besides the scheme itself, indicates the location of 317 a SIP server that can be used to handle the request. Finally, a 318 route is a sequence of SIP entities (including the UA itself!) which 319 are traversed in order to forward a request to an address or name. 321 SIP, unfortunately, uses the Request-URI as a mechanism for routing 322 of the request in addition to using it as the mechanism for 323 identifying the name or address to which the request was targeted. A 324 home proxy rewrites the Request-URI because that rewriting is the 325 vehicle by which the request is forwarded to the target of the 326 request. However, this rewritten URI (the contact from the 327 register), is not in any way a meaningful name or address for the UA. 328 Indeed, with specifications like SIP outbound 329 [I-D.ietf-sip-outbound], even the IP address within the registered 330 contact is meaningless since the flow on which the REGISTER is sent 331 is used rather than the IP address. Consequently, the home proxy is 332 fundamentally replacing the address in the Request-URI with a route 333 to reach that UA. This architectural mistake is the cause of the 334 problems described above. 336 Interestingly, this same mistake was present in RFC 2543 [RFC2543] 337 for the handling of mid-dialog requests. It was fixed through the 338 loose routing mechanism in RFC 3261, which used Route header fields 339 to identify each hop to visit for a mid-dialog request, and separated 340 this from the Request-URI, which identified the ultimate target of 341 the request (the remote UA), and remained unmodified in the 342 processing of the request. It is also interesting to note that in 343 RFC 3261, the Request-URI in a mid-dialog request is the contact 344 provided in the INVITE or 2xx, and identifies the UA itself. This is 345 typically a SIP URI containing an IP address and, as has been argued 346 above, its not an address per se, but a SIP hop. That too has proven 347 to be an error, and has been fixed by the GRUU specification 348 [I-D.ietf-sip-gruu], which will cause the Contact in INVITE and 2xx 349 to be the GRUU instead. This, in turn, means that mid-dialog 350 requests will contain the GRUU in the request-URI. The GRUU is, in 351 fact, an address. 353 However, the loose routing fix made in RFC 3261 was not extended to 354 the handling of requests outside of a dialog. There, proxies retain 355 the practice of rewriting the Request-URI when accessing the location 356 service. 358 4. Alternative Solutions 360 There are several existing mechanisms which might be employed to 361 solve this problem. 363 4.1. What about the To header field? 365 When a UA sends a request, it typically populates the To header field 366 and the Request-URI with the target URI. Consequently, when the 367 request arrives at the terminating network, the Request-URI will be 368 rewritten, but the To header field is retained. Thus, when the 369 request arrives at the UA, the To header field identifies the 370 original target. Could that serve as the obvious solution to the 371 problem? 373 Unfortunately, it cannot. When a SIP call is forwarded (also known 374 as retargeting), the actual target of the address changes completely, 375 but the To field does not. When a retargeting operation happens, the 376 URI that needs to be delivered to the UAS is the SIP address or name 377 after the most recent retargeting operation. Consider the case of 378 Alice making a call to Bob (sip:bob@example.com). This arrives at 379 Bob's proxy, which has logic programmed in it to forward the call to 380 Jane, a user in a completely different network 381 (sip:jane@example.edu). When this arrive at Jane's proxy, the 382 Request URI is rewritten to her registered contact. In this case, 383 the To header field contains the original target of the request 384 (sip:bob@example.com), but this is not an identifier for Jane. Thus, 385 the SIP URI for which she was targeted (sip:jane@example.edu). Is 386 lost. Another example of this would be a call to one address or 387 number which is later forwarded to an 8xx number. 389 4.2. History Info 391 Another candidate solution is the History Info specification 392 [RFC4244]. This specification defines a new header field, History- 393 Info, which records a history of redirection and retargeting 394 operations. One solution to this problem is to require every proxy 395 that rewrites the request URI to implement this specification. As a 396 consequence of that, a UAS could examine the History-Info header 397 field and determine the URI used to reach it. 399 Functionally, this can work. However, we would argue that there are 400 some major architectural problems with it. 402 Firstly, it would cause the Request-URI to be relegated to nothing 403 more than an indicator of the next hop for the request, identical 404 exactly to the purpose of the Route header field. This results in 405 two things in the SIP specification which do exactly the same thing. 406 Worse still, this is not just for some small feature of SIP (where 407 such duplication might not be a big deal), but rather, it would be a 408 duplication of SIP's primary function - routing of a call towards a 409 target. 411 Secondly, it would require the UA to look through the history info 412 and figure out which of the URI in there represent the target by 413 which it was reached, and which represent hops that were used along 414 the way. The UA may have no easy way to know this, especially if 415 there were many hops within the domain in which the UA resides. 417 5. Proposed Solution 419 The proposed solution is simple. When handling a request, a proxy 420 only rewrites the Request-URI when performing a retargeting 421 operation. If, instead, the proxy is trying to route the request via 422 some entity (whether its a proxy or UA) to reach the target, the 423 Request-URI is retained, and Route header fields are pushed into the 424 request to reach the target. 426 This introduces an important question: what is a retargeting 427 operation compared to a routing operation? Is a translation of a 428 name (such as an SOS URN) to an address (like a SIP AOR) a 429 retargeting or a routing operation? We propose that the distinction 430 be determined by means of identity, and in particular the type of 431 assertions provided by [RFC4474]. An operation is considered to be a 432 retargeting operation if the entity to which the request is 433 ultimately delivered could not, based on the policies of the domain 434 of that entity, place the URI prior to translation in the From header 435 field, and have an identity service in its domain sign it. The 436 inverse is not true however. If an entity can legitimately claim the 437 identity prior to the translation operation, it may still be a 438 retargeting. In this case, it is a matter of domain policy about 439 whether it is or not. 441 From this basic rule, several sub-cases can be derived: 443 1. When a home proxy receives a request and accesses a location 444 service, the resulting contact(s) obtained from the location 445 service are considered the last hop in the route towards the 446 entity addressed by the Request-URI. Since that target, almost 447 by definition, can claim the identity of the URI prior to 448 translation, the operation is one of routing and not retargeting. 449 Consequently, the home proxy would retain the Request-URI, place 450 the contents of any Path headers from the registration into the 451 request as Route header field values [RFC3327], and insert the 452 registered contact as the last Route header field value. 454 2. When a proxy receives a request whose contents are a name and not 455 an address (for example, a tel URI or an SOS URN), and the proxy 456 determines through some means an address for that name, this 457 operation is not retargeting. The presumption is that the entity 458 managing the database that provides the translation will only 459 translation the name to an address if the SIP resource identified 460 by that address could claim the name as an identity. 461 Consequently, the proxy would push that address as a Route header 462 field value and retain the Request-URI. 464 3. When a proxy receiving a request identifies a next hop server 465 that is needed to process the request, that next hop server is a 466 route. A next hop server is not a UA and would never be able to 467 claim its identity. Its URI is pushed into a Route header field 468 and the Request-URI is retained. An important use case for this 469 are proxies that select PSTN gateways for call egress to the 470 PSTN. Such selection would place the SIP URI of the gateway into 471 the topmost Route header field value and retain the Request-URI. 473 4. When a proxy receives a request whose Request-URI is a SIP URI 474 matching the domain of the proxy, and the proxy decides that the 475 call needs to be terminated at a resource in another domain, this 476 is fundamentally a retargeting operation, and the Request-URI is 477 rewritten. It is fundamentally retargeting because an entity in 478 one domain couldn't claim the identity of an entity in another 479 based on the procedures in [RFC4474] 481 This definition also lends clarity to how and when History-Info gets 482 used. In particular, a History-Info header field would get added 483 when a request is retargeted, but not when it is routed. That is, 484 only operations which would cause a Request-URI to be rewritten would 485 cause a History-Info header field to be added. 487 Redirection can then have several different meanings. Consider a 488 client X which sends a request to server Y. Server Y redirects the 489 request. The redirection could have three meanings: 491 1. The server is asking the client to retarget, so that the recursed 492 request generated by the client replaces the Request-URI with the 493 contents of the redirection. 495 2. The server is asking the client to route through a different 496 server instead, so that the recursed request generated by the 497 client replaces the topmost Route header with the contents of the 498 redirection. 500 3. The server is asking the client to route through an additional 501 proxy prior to visiting it, so that the recursed request 502 generated by the client pushes an additional Route onto the Route 503 set. 505 Today, a 3xx always has the first semantic. To allow redirects to 506 result in a change in the route header field, an additional mechanism 507 is needed. A client which is capable of supporting this mechanism 508 (whether its a proxy or UA), adds a field to the Via header field 509 which indicates that this hop supports the mechanism. With that in 510 place, the three different redirect behaviors can be achieved. If a 511 server redirects, and the contact in the redirect contains the ;lr 512 parameter, this is a request for the previous hop to ovveride, for 513 this transaction only, the topmost Route header field value with the 514 value of the contact. If the redirect omits the ;lr parameter, it is 515 a normal redirect that replaces the Request-URI (a retarget). A new 516 response code can be defined, used only when the previous hop 517 supports this specification, for telling the upstream client to 518 append the contact to the existing route set (again for this 519 transaction only). 521 It is important to note that this mechanism will allow for a mid- 522 dialog request to be redirected to a different hop (i.e., a redirect 523 with an ;lr parameter in the contact), and that this will persist 524 just for the duration of the transaction. This mechanism is used in 525 the failover techniques described in 526 [I-D.rosenberg-sip-outbound-discovery-mid-dialog]. 528 6. Backwards Compatibility Considerations 530 The principal problem to be resolved is how to make this mechanism 531 backwards compatible. There are several solutions that can be used. 533 The simplest case is the location service case. When a UA registers, 534 it places the "ua-loose" option tag into the Supported header field 535 of its REGISTER request. If the registrar and home proxy support the 536 UA loose routing procedure described here, it adds a Require header 537 field to the response, indicating to the UA that loose routing 538 procedures will be used. This mechanism would permit different UA 539 for the same AOR to be a mix of ua-loose capable and ua-loose 540 incapable. 542 There are additional complications with the REGISTER case, however. 543 It is possible that the outbound proxy between the UA and the home 544 proxy will be confused by a new request towards the UA. It will now 545 have a Route header field in it pointing to the UA. Based on the 546 procedures in RFC 3261 and RFC 3263 [RFC3263], it should work fine, 547 and even an outbound proxy implementing [I-D.ietf-sip-outbound] will 548 properly route the request towards the UA (that routing being based 549 on the received Route header field, in fact). There is some question 550 about whether a P-CSCF based on the IMS specifications will properly 551 work in this case. Being RFC 3261 compliant it ought to; but it 552 requires further investigation. 554 The more troubling cases are for translations not based on the 555 registration operation, such as name to address or gateway routing 556 operations. One idea is to use the existing ;lr URI parameter to 557 indicate that a URI is a loose route, and needs to be placed into a 558 Route header field and not cause replacement of the Request-URI. 559 This would work well when configuring proxies compliant with this 560 specification. A URI with the ;lr parameter indicates a routing next 561 hop, and without indicates a retargeting. 563 For external services that provide next hops, such as ENUM [RFC3761], 564 implementations would assume that any contents received are not loose 565 routes, but rather retargets. Such services would need to define new 566 fields specifically for loose routes. 568 7. Minting AORs and GRUU 570 With loose routing in place, a UA can mint additional URI that are 571 processed by the SIP proxies identically to their AOR or GRUU. This 572 is done by adding a URI parameter, chosen by the UA, to the AOR or 573 GRUU, and handing that out to UA to use. 575 Strictly speaking, there is no need to even standardize a specific 576 URI parameter. The parameter is inserted by the UA, and used only by 577 the UA. However, it does need to avoid conflicting with any other 578 URI parameters which might have other meaning by the home proxy, 579 unbeknownst to the UA. This would argue for either one or more IANA 580 registered parameters, use of a vendor namespace, or 581 cryptographically random URI parameter names. It does make sense to 582 allow for more than one URI parameter however. This would allow for 583 infinitely nested sub-addressing capabilities, which is highly 584 desirable. 586 8. Security Considerations 588 The UA loose routing mechanism reveals to the UA the address by which 589 it was contacted. Previously, this was hidden from the UA. It may 590 be possible that a UA is not permitted to know the address at which 591 it was contacted. In such cases, the home proxy SHOULD treat such 592 calls as retargets and rewrite the Request-URI. 594 9. IANA Considerations 596 TODO. 598 10. Example 600 Consider the most basic case of a single proxy P and two user agents, 601 UA1 and UA2. A basic flow for registration and call setup is shown 602 in Figure 1. 604 UA 1 Proxy UA 2 605 | |(1) REGISTER | 606 | |<-------------| 607 | |(2) 200 OK | 608 | |------------->| 609 |(3) INVITE | | 610 |------------->| | 611 | |(4) INVITE | 612 | |------------->| 613 | |(5) 200 OK | 614 | |<-------------| 615 |(6) 200 OK | | 616 |<-------------| | 617 |(7) ACK | | 618 |------------->| | 619 | |(8) ACK | 620 | |------------->| 621 |(9) BYE | | 622 |------------->| | 623 | |(10) BYE | 624 | |------------->| 625 | |(11) 200 OK | 626 | |<-------------| 627 |(12) 200 OK | | 628 |<-------------| | 630 Figure 1 632 First, UA registers (message 1). It indicates support for loose 633 routing via a Supported header field parameter and also includes an 634 ;lr parameter in its Contact header field. This message would look 635 like, in part (note the usage of both GRUU and sip-outbound; they are 636 not required with UA loose routing but is illustrative of a likely 637 use case): 639 REGISTER sip:example.com SIP/2.0 640 From: sip:user2@example.com;tag=9asd7d 641 To: sip:user2@example.com 642 Supported: gruu, ua-loose 643 Contact: 644 ;+sip.instance="" 645 ;reg-id=1 647 The response to the REGISTER (message 2) provides a GRUU to the UA 648 and also indicates that loose routing is to be used: 650 REGISTER sip:example.com SIP/2.0 651 From: sip:user2@example.com;tag=9asd7d 652 To: sip:user2@example.com 653 Require: ua-loose 654 Contact: 655 ;+sip.instance="" 656 ;reg-id=1 657 ;expires=3600 658 ;pub-gruu="sip:user2@example.com;gr; 659 aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 661 Next, UA1 generates an INVITE towards UA2 (message 3): 663 INVITE sip:user2@example.com SIP/2.0 664 From: sip:user1@example.com;tag=555af9g7 665 To: sip:user2@example.com 667 This arrives at the proxy, which looks up the Request-URI. It finds 668 a single registered contact which is marked as loose routing. 669 Therefore, the request it generates towards UA2 looks like (message 670 4): 672 INVITE sip:user2@example.com SIP/2.0 673 Route: 674 From: sip:user1@example.com;tag=555af9g7 675 To: sip:user2@example.com 677 Note that the Request-URI is unmodified and a Route header field has 678 been pushed. The UAS generates a 200 OK (message 5): 680 SIP/2.0 200 OK 681 From: sip:user1@example.com;tag=555af9g7 682 To: sip:user2@example.com;tag=6566565 683 Contact: 686 Note the presence of the GRUU in the 200 OK. When the BYE comes 687 later on (message 9), it is sent to the GRUU: 689 BYE sip:user2@example.com;gr; 690 aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 691 From: sip:user1@example.com;tag=555af9g7 692 To: sip:user2@example.com;tag=6566565 694 When this arrives at the home proxy, the same thing happens as 695 before. The registered contact bound to the GRUU is a loose route, 696 and so the BYE sent to the UAS would look like (message 10): 698 BYE sip:user2@example.com;gr; 699 aor-qual=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 700 Route: 701 From: sip:user1@example.com;tag=555af9g7 702 To: sip:user2@example.com;tag=6566565 704 11. References 706 11.1. Normative References 708 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 709 A., Peterson, J., Sparks, R., Handley, M., and E. 710 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 711 June 2002. 713 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 714 Protocol (SIP): Locating SIP Servers", RFC 3263, 715 June 2002. 717 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 718 (SIP) Extension Header Field for Registering Non-Adjacent 719 Contacts", RFC 3327, December 2002. 721 11.2. Informative References 723 [I-D.ietf-sip-outbound] 724 Jennings, C. and R. Mahy, "Managing Client Initiated 725 Connections in the Session Initiation Protocol (SIP)", 726 draft-ietf-sip-outbound-10 (work in progress), July 2007. 728 [I-D.ietf-sip-gruu] 729 Rosenberg, J., "Obtaining and Using Globally Routable User 730 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 731 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 732 October 2007. 734 [I-D.ietf-sipping-spam] 735 Rosenberg, J. and C. Jennings, "The Session Initiation 736 Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work 737 in progress), July 2007. 739 [I-D.ietf-ecrit-requirements] 740 Schulzrinne, H. and R. Marshall, "Requirements for 741 Emergency Context Resolution with Internet Technologies", 742 draft-ietf-ecrit-requirements-13 (work in progress), 743 March 2007. 745 [I-D.ietf-ecrit-service-urn] 746 Schulzrinne, H., "A Uniform Resource Name (URN) for 747 Emergency and Other Well-Known Services", 748 draft-ietf-ecrit-service-urn-07 (work in progress), 749 August 2007. 751 [I-D.ietf-ecrit-framework] 752 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 753 "Framework for Emergency Calling using Internet 754 Multimedia", draft-ietf-ecrit-framework-03 (work in 755 progress), September 2007. 757 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 758 Enumservice Containing Public Switched Telephone Network 759 (PSTN) Signaling Information", RFC 4769, November 2006. 761 [I-D.ietf-enum-cnam] 762 Shockey, R., "IANA Registration for an Enumservice Calling 763 Name Delivery (CNAM) Information and IANA Registration 764 for URI type 'pstndata' URI type 'pstn'", 765 draft-ietf-enum-cnam-07 (work in progress), October 2007. 767 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 768 Authenticated Identity Management in the Session 769 Initiation Protocol (SIP)", RFC 4474, August 2006. 771 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 772 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 773 March 1999. 775 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 776 Resource Identifiers (URI) Dynamic Delegation Discovery 777 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 779 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 780 using SIP Request-URI", RFC 3087, April 2001. 782 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 783 Media Services with SIP", RFC 4240, December 2005. 785 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 786 Initiation Protocol (SIP) URIs for Applications such as 787 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 788 April 2006. 790 [RFC4244] Barnes, M., "An Extension to the Session Initiation 791 Protocol (SIP) for Request History Information", RFC 4244, 792 November 2005. 794 [I-D.rosenberg-sip-outbound-discovery-mid-dialog] 795 Rosenberg, J., "Discovering Outbound Proxies and Providing 796 High Availability with Client Initiated Connections in 797 the Session Initiation Protocol (SIP)", 798 draft-rosenberg-sip-outbound-discovery-mid-dialog-00 (work 799 in progress), October 2006. 801 Author's Address 803 Jonathan Rosenberg 804 Cisco 805 Edison, NJ 806 US 808 Email: jdrosen@cisco.com 809 URI: http://www.jdrosen.net 811 Full Copyright Statement 813 Copyright (C) The IETF Trust (2008). 815 This document is subject to the rights, licenses and restrictions 816 contained in BCP 78, and except as set forth therein, the authors 817 retain all their rights. 819 This document and the information contained herein are provided on an 820 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 821 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 822 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 823 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 824 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Intellectual Property 829 The IETF takes no position regarding the validity or scope of any 830 Intellectual Property Rights or other rights that might be claimed to 831 pertain to the implementation or use of the technology described in 832 this document or the extent to which any license under such rights 833 might or might not be available; nor does it represent that it has 834 made any independent effort to identify any such rights. Information 835 on the procedures with respect to rights in RFC documents can be 836 found in BCP 78 and BCP 79. 838 Copies of IPR disclosures made to the IETF Secretariat and any 839 assurances of licenses to be made available, or the result of an 840 attempt made to obtain a general license or permission for the use of 841 such proprietary rights by implementers or users of this 842 specification can be obtained from the IETF on-line IPR repository at 843 http://www.ietf.org/ipr. 845 The IETF invites any interested party to bring to its attention any 846 copyrights, patents or patent applications, or other proprietary 847 rights that may cover technology that may be required to implement 848 this standard. Please address the information to the IETF at 849 ietf-ipr@ietf.org. 851 Acknowledgment 853 Funding for the RFC Editor function is provided by the IETF 854 Administrative Support Activity (IASA).