idnits 2.17.1 draft-rosenberg-sipcore-target-uri-delivery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2009) is 5434 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) ** Obsolete normative reference: RFC 4244 (Obsoleted by RFC 7044) -- 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 3455 (Obsoleted by RFC 7315) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-19 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track J. van Elburg 5 Expires: December 11, 2009 C. Holmberg 6 Ericsson 7 F. Francois 8 Nortel 9 S. Schubert (Ed.) 10 NTT 11 June 9, 2009 13 Delivery of Request-URI Targets to User Agents 14 draft-rosenberg-sipcore-target-uri-delivery-00 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on December 11, 2009. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 When a Session Initiation Protocol (SIP) proxy receives a request 63 targeted at a URI identifying a user or resource it is responsible 64 for, the proxy translates the URI to a configured URI, or to a 65 registered contact URI, of an agent representing that user or 66 resource. In the process, the original URI is removed from the 67 request. Numerous use cases have arisen which require this 68 information to be delivered to the user agent. This document 69 describes these use cases and defines an extension to the History- 70 Info header field which allows it to be used to support those cases. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. mapping translation . . . . . . . . . . . . . . . . . . . 4 78 3.2. routing translation . . . . . . . . . . . . . . . . . . . 5 79 3.3. addressed target . . . . . . . . . . . . . . . . . . . . . 5 80 3.4. address-of-record (AOR) . . . . . . . . . . . . . . . . . 5 81 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 82 4.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 5 83 4.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 6 84 4.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 6 85 4.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 6 86 4.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 7 87 4.6. Toll Free Numbers . . . . . . . . . . . . . . . . . . . . 8 88 5. Architectural Roots of the Problem . . . . . . . . . . . . . . 8 89 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10 90 7. Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 13 92 7.2. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 93 7.2.1. Determining the addressed target . . . . . . . . . . . 14 94 7.2.2. Determining the last AOR used to reach it . . . . . . 14 95 8. The difference to P-Called-Party-Id . . . . . . . . . . . . . 15 96 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 A key part of the behavior of proxy servers and B2BUA in the Session 106 Initiation Protocol (SIP) [RFC3261] is that they rewrite the Request- 107 URI of requests as the request moves from the User Agent Client (UAC) 108 to the User Agent Server (UAS). This is particularly true for 109 requests outside of a dialog; requests within a dialog have their 110 path dictated primarily by the Route header fields established by the 111 Record-Routes when the dialog was initiated. 113 The most basic instance of this behavior is the processing executed 114 by the "home proxy" within a domain. The home proxy is the proxy 115 server within a domain which accesses the location information 116 typically generated by REGISTER messages, and uses it to forward a 117 request towards a UA. Based on the rules in [RFC3261], when a home 118 proxy receives a SIP request, it looks up the Request-URI in the 119 location database or mapping table, and translates it to configured 120 URI(s), or to registered contact(s). This new contact URI replaces 121 the existing Request URI, and causes the request to be forwarded 122 towards the target UA. Consequently, the original contents of the 123 Request URI are lost. 125 Over the years, this practice of rewriting the Request-URI has proven 126 problematic. Section 4 describes the problems with this mechanism. 127 Section 5 analyzes the architectural issues which drive these 128 problems. Section 6 overviews a mechanism to solve this problem by 129 extending the History-Info header field. Section 7 describes 130 detailed procedures for user agents and proxies. 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Definitions 140 3.1. mapping translation 142 A Request-URI rewrite operation is considered to be a mapping 143 translation if the name or address of a user or resource is 144 translated to a name or address belonging to a different user or 145 resource. 147 3.2. routing translation 149 A Request-URI rewrite operation is considered to be a routing 150 translation if the name or address of a user or resource is 151 translated to an address that is a hop for reaching that user. 153 3.3. addressed target 155 The addressed target is the address or name that was used by the 156 initiator of an initial request, except when it is changed by one or 157 more mapping translations. As by definition mapping translations 158 change the addressed target. 160 3.4. address-of-record (AOR) 162 See [RFC3261]. 164 4. Problem Statement 166 Several problems arise from the practice of rewriting the request 167 URI. 169 4.1. Unknown Aliases 171 SIP user agents are associated with an address-of-record (AOR). It 172 is possible for a single UA to actually have multiple AOR associated 173 with it. One common usage for this is aliases. For example, a user 174 might have an AOR of sip:john@example.com but also have the AORs 175 sip:john.smith@example.com and sip:jsmith@example.com. Rather than 176 registering against each of these AORs individually, the user would 177 register against just one of them, and the home proxy would 178 automatically accept incoming calls for any of the aliases, treating 179 them identically and ultimately forwarding them towards the UA. This 180 is common practice in the Internet Multimedia Subsystem (IMS), where 181 it is called implicit registrations and each alias is called a public 182 identity. 184 It is a common requirement for a UAS, on receipt of a call, to know 185 which of its aliases was used to reach it. This knowledge can be 186 used to choose ringtones to play, determine call treatment, and so 187 on. For example, a user might give out one alias to friends and 188 family only, resulting in a special ring that alerts the user to the 189 importance of the call. 191 However, based on the procedures in [RFC3261], when an incoming call 192 hits the home proxy, the request URI (which contains the alias) is 193 rewritten to the registered contact(s). Consequently, the alias that 194 was used is lost, and cannot be known to the UAS. 196 4.2. Unknown GRUU 198 A variation on the problem in Section 4.1 occurs with Globally 199 Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu]. A GRUU is a URI 200 assigned to a UA instance which has many of the same properties as 201 the AOR, but causes requests to be routed only to that specific 202 instance. It is desirable for a UA to know whether it was reached 203 because a correspondent sent a request to its GRUU or to its AOR. 204 This can be used to drive differing authorization policies on whether 205 the request should be accepted or rejected, for example. However, 206 like the AOR itself, the GRUU is lost in translation at the home 207 proxy. Thus, the UAS cannot know whether it was contacted via the 208 GRUU or its AOR. 210 4.3. Limited Use Addresses 212 A limited use address is a SIP URI that is minted on-demand, and 213 passed out to a small number (usually one) remote correspondent. 214 Incoming calls targeted to that limited use address are accepted as 215 long as the UA still desires communications from the remote target. 216 Should they no longer wish to be bothered by that remote 217 correspondent, the URI is invalidated so that future requests 218 targeted to it are rejected. 220 Limited use addresses are used in battling voice spam [RFC5039]. The 221 easiest way to provide them would be for a UA to be able to take its 222 AOR, and "mint" a limited use address by appending additional 223 parameters to the URI. It could then give out the URI to a 224 particular correspondent, and remember that URI locally. When an 225 incoming call arrives, the UAS would examine the parameter in the URI 226 and determine whether or not the call should be accepted. 227 Alternatively, the UA could push authorization rules into the 228 network, so that it need not even see incoming requests that are to 229 be rejected. 231 This approach, especially when executed on the UA, requires that 232 parameters attached to the AOR, but not used by the home proxy in 233 processing the request, will survive the translation at the home 234 proxy and be presented to the UA. This will not be the case with the 235 logic in RFC 3261, since the Request-URI is replaced by the 236 registered contact, and any such parameters are lost. 238 4.4. Sub-Addressing 240 Sub-Addressing is very similar to limited use addresses. Sub- 241 addresses are addresses within a subdomain that are multiplexed into 242 a single address within a parent domain. The concept is best 243 illustrated by example. Consider a VoIP service provided to 244 consumers. A consumer obtains a single address from its provider, 245 say sip:family@example.com. However, Joe is the patriarch of a 246 family with four members, and would like to be able to have a 247 separate identifier for each member of his family. One way to do 248 that, without requiring Joe to purchase new addresses for each member 249 from the provider, is for Joe to mint additional URI by adding a 250 parameter to the AOR. For example, his wife Judy with have the URI 251 sip:family@example.com;member=judy, and Joe himself would have the 252 URI sip:family@example.com;member=joe. The SIP server provider would 253 receive requests to these URI, and ignoring the unknown parameters 254 (as required by [RFC3261]) route the request to the registered 255 contact, which corresponds to a SIP server in Joes home. That 256 server, in turn, can examine the URI parameters and determine which 257 phone in the home to route the call to. 259 This feature is not specific to VoIP, and has existing in Integrated 260 Services Digital Networking (ISDN) for some time. It is particularly 261 useful for small enterprises, in addition to families. It is also 262 similar in spirit (though not mechanism) to the ubiquitous home 263 routers used by consumers, which allow multiple computers in the home 264 to "hide" behind the single IP address provided by the service 265 provider, by using the TCP and UDP port as a sub-address. 267 The sub-addressing feature is not currently feasible in SIP because 268 of the fact that any SIP URI parameter used to convey the sub-address 269 would be lost at the home proxy, due to the fact that the Request-URI 270 is rewritten there. 272 4.5. Service Invocation 274 Several SIP specifications have been developed which make use of 275 complex URIs to address services within the network rather than 276 subscribers. The URIs are complex because they contain numerous 277 parameters that control the behavior of the service. Examples of 278 this include the specification which first introduced the concept, 279 [RFC3087], control of network announcements and IVR with SIP URI 280 [RFC4240], and control of voicemail access with SIP URI [RFC4458]. 282 A common problem with all of these mechanisms is that once a proxy 283 has decided to rewrite the Request-URI to point to the service, it 284 cannot be sure that the Request-URI will not be destroyed by a 285 downstream proxy which decides to forward the request in some way, 286 and does so by rewriting the Request-URI. 288 4.6. Toll Free Numbers 290 Toll free numbers, also known as 800 or 8xx numbers in the United 291 States, are telephone numbers that are free for users to call 292 (although the author will note that such notions are becoming less 293 important as billing models evolve, and harken back to an era where 294 phone service depended on global agreement on such billing concepts). 296 In the telephone network, toll free numbers are just aliases to 297 actual numbers which are used for routing of the call. In order to 298 process the call in the PSTN, a switch will perform a query (using a 299 protocol called TCAP), which will return either a phone number or the 300 identity of a carrier which can handle the call. 302 There has been recent work on allowing such PSTN translation services 303 to be accessed by SIP proxy servers through IP querying mechanisms. 304 ENUM, for example [RFC3761] has already been proposed as a mechanism 305 for performing Local Number Portability (LNP) queries [RFC4769], and 306 recently been proposed for performing calling name queries 307 [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a 308 logical next-step. 310 Once such a translation has been performed, the call needs to be 311 routed towards the target of the request. Normally, this would 312 happen by selecting a PSTN gateway which is a good route towards the 313 translated number. However, one can imagine all-IP systems where the 314 8xx numbers are SIP endpoints on an IP network, in which case the 315 translation of the 8xx number would actually be a SIP URI and not a 316 phone number. Assuming for the moment it is a PSTN connected entity, 317 the call would be routed towards a PSTN gateway. Proper treatment of 318 the call in the PSTN (and in particular, correct reconciliation of 319 billing records) requires that the call be marked with both the 320 original 8xx number AND the target number for the call. However, in 321 our example here, since the translation was performed by a SIP proxy 322 upstream from the gateway, the original 8xx number would have been 323 lost, and the call will not interwork properly with the PSTN. 325 Similar problems arise with other "special" numbers and services used 326 in the PSTN, such as operator services, pay numbers (9xx numbers in 327 the U.S), and short service codes such as 311. 329 5. Architectural Roots of the Problem 331 There is a common theme across all of the problems in Section 4, and 332 this theme is the confounding of names, routes, and addresses. 334 A name is a moniker for an entity which refers to it in a way which 335 reveals nothing about where it is in a network. In SIP, tel URI 336 which doesn't represent the location of the entity is a name. An 337 address is an identifier for an entity which describes it by its 338 location on the network. In SIP, the SIP URI itself is a form of 339 address because the host part of the URI, the only mandatory part of 340 the URI besides the scheme itself, indicates the location of a SIP 341 server that can be used to handle the request. Finally, a route is a 342 sequence of SIP entities (including the UA itself!) which are 343 traversed in order to forward a request to an address or name. 345 SIP, unfortunately, uses the Request-URI as a mechanism for routing 346 of the request in addition to using it as the mechanism for 347 identifying the name or address to which the request was targeted. A 348 home proxy rewrites the Request-URI because that rewriting is the 349 vehicle by which the request is forwarded to the target of the 350 request. However, this rewritten URI (a configured URI or a 351 registered contact), is not in any way a meaningful name or address 352 for the UA. Indeed, with specifications like SIP outbound 353 [I-D.ietf-sip-outbound], even the IP address within the registered 354 contact is meaningless since the flow on which the REGISTER is sent 355 is used rather than the IP address. Consequently, the home proxy is 356 fundamentally replacing the *address* in the Request-URI with a 357 *route* to reach that UA. This architectural mistake is the cause of 358 the problems described above. 360 Interestingly, this same mistake was present in [RFC2543] for the 361 handling of mid-dialog requests. It was fixed through the loose 362 routing mechanism in RFC 3261, which used Route header fields to 363 identify each hop to visit for a mid-dialog request, and separated 364 this from the Request-URI, which identified the ultimate target of 365 the request (the remote UA), and remained unmodified in the 366 processing of the request. 368 Unfortunately, application of this same technique to address the 369 problem at hand cannot be done in a backwards compatible manner. 370 Consequently, some other means is needed to allow the UAS to deduct 371 by which name or address its user has been addressed by an upstream 372 entity. 374 An address itself has not the inherent property of being an addressed 375 target, that depends on the history and nature of Request-URI 376 rewrites for a particular call. For example if a user A calls a user 377 B, but the B has a forwarding service active that forwards the call 378 to user C, then clearly the Request-URI translation peformed on 379 behalf of B affects the addressed target. On the other hand when a 380 user A calls a special address Bservice of user B, where Bservice is 381 hosted in a dedicated proxy offering such services and for actual 382 delivery of the request forwards the request to address of user B, 383 then clearly the Request-URI translation does not affect the 384 addressed target. To distinguish these type of address translations 385 we refer to the first one as a mapping translation and to the second 386 one as a routing translation. For a definition see also the 387 Section 3. 389 6. Solution Overview 391 The History-Info header field, defined in [RFC4244], defines a 392 mechanism by which an enumeration of the URIs traversed can be passed 393 to both the UAC and UAS. History-Info was designed to provide a 394 general purpose mechanism which can support the needs of many 395 applications, including diagnostics and traditional telephony 396 features like voicemail. Were a home proxy to implement History- 397 Info, it would provide a means for that proxy to deliver the target 398 URI to the UAS. 400 Unfortunately, History-Info makes no distinction between hi-entries 401 that record a URI that are addressed targets and URIs that are merely 402 hops. Consequently, if there were additional proxies downstream of 403 the home proxy which modified the Request-URI in any way, the UA 404 would have no way to know which URI in the list of History-Info 405 values was actually the addressed target. To remedy that, this 406 document defines extensions to the History-Info header field that 407 allows the UAS to extract the addressed target. 409 When a home proxy receives a request for a user or resource for which 410 is abstract location function returns registered contacts or 411 configured URIs, the proxy adds two History-Info header field values. 412 The first is the incoming request URI. Since the Request-URI 413 identifies a user or resource for which it has a registration or 414 configuration, the Request-URI is an AOR and thus an address for the 415 user. The proxy adds a History-Info header field parameter, "aor", 416 which indicates this. Next, the proxy inserts the contact URI which 417 will be contained in the outgoing Request-URI. 419 For a UAS to determine the last AOR used to reach it, it need only 420 walk backwards through the list of HI values, and take the first one 421 containing the "aor" parameter. 423 However this is not enough to determine the addressed target as an 424 AOR may well be an intermediary routing step in particular scenarios. 425 The problem arising from this is that a users service number that is 426 forwarded to the users regular AOR would all be tagged "aor". It 427 could for example be used to determine the last AOR before the UAS 428 was reached. (Same semantics as P-Called-Party-ID, [RFC3455]). 430 So additionally to determine the addressed target we need to be able 431 to distinguish, which translations (Request URI rewrites) do change 432 addressed target and which do not. 434 When a proxy receives a request for a user or resource for which it 435 is responsible, then when a request URI rewrite occurs that is a 436 routing translation, then add a History-Info header field parameter 437 "routed" to the hi-entry recording the incoming request URI. 438 Otherwise when a request URI rewrite occurs that is a mapping 439 translation, then add a History-Info header field parameter "mapped" 440 to the hi-entry recording the incoming request URI. In case a proxy 441 does not have knowledge if the nature of the translation being a 442 mapping or a routing translation it shall assume a routing 443 translation and add a "routed" parameter. 445 Combining both mechanisms gives hi-entries with the following 446 parameter combinations: 448 o aor, mapped: AOR that was translated (using an abstract location 449 service) to an AOR belonging to a different user or resource 451 o aor, routed: AOR that was translated (using an abstract location 452 service) to a different AOR or contact address belonging to the 453 same user or resource 455 o routed: Request URI was rewritten for routing purposes (including 456 strict routing, no-op/loose-routing, maddr) 458 For a UAS to determine the addressed target, traverse History-Info 459 backward until an entry is found that is marked with the parameters 460 "aor, mapped", take the entry after that to represent the actual 461 target. If no such entry is found then take the first hi-entry. 463 Example case B diverts to freephone, freephone translates to C, C 464 translates to a registered contact would give: 466 History-Info: ;index=1;aor;mapped 467 History-Info: ;index=1.1;aor;routed 468 History-Info: ;index=1.1.1;aor;routed 469 History-Info: ;index=1.1.1.1 471 Figure 1: Determine addressed target URI Example 473 Another example, consider the architecture in Figure 2. In the 474 example user A calls user B. User B is in example.com. The call from 475 A to B passes through A's outbound proxy, their home proxy, B's home 476 proxy, and B's outbound proxy, prior to reaching B. B's home proxy, 477 H-B, performs the translation of the R-URI to the registered contact 478 based on the registration database. Consequently, it adds two 479 History-Info header fields, the first of which represents the 480 incoming R-URI and includes the "aor" parameter. 482 +-------+ +-------+ +-------+ +-------+ 483 //--\\ | | | | | | | | //--\\ 484 | A |--- | OB-A |----| H-A |---| H-B |---| OB-B |--| B | 485 | | | | | | | | | | | | 486 \\--// +-------+ +-------+ +-------+ +-------+ \\--// 488 INVITE 489 sip:B@example.com 490 ------------> 491 INVITE 492 sip:B@example.com 493 ------------> 494 INVITE 495 sip:B@example.com 496 ------------> 498 INVITE 499 sip:B@example.com 500 HI: index=1;aor,routed, 501 ;index=1.1 502 ------------> 504 Figure 2: Target URI Example 506 7. Detailed Semantics 508 The "aor" parameter in the History-Info header field indicates that 509 the URI that it parameterizes was either subject to a lookup in a 510 location service created through the registration process of the UA 511 or was available through configuration. Furthermore, if that URI had 512 an 'index' of N, the URIs with indices N.M for all M, are registered 513 contacts/configured URIs to that URI. 515 The "mapped" parameter in the History-Info header field indicates 516 that the URI that it parameterizes was subject to a mapping 517 translation. 519 The "routed" parameter in the History-Info header field indicates 520 that the URI that it parameterizes was subject to a routing 521 translation. 523 7.1. Proxy Behavior 525 A proxy compliant to this specification SHOULD add a History-Info 526 header field value to a request under the following conditions: 528 o The proxy is responsible for the domain in the Request-URI 530 o The proxy will be translating the contents of the Request-URI to 531 one or more contacts or URIs either based on a location database 532 populated through REGISTER requests from user agents or based on 533 configurion. 535 o The Request-URI exists in the location database. 537 The proxy SHOULD populate the History-Info header field regardless of 538 whether there is a Supported header field with value 'histinfo'. If 539 the incoming request already contains a History-Info header field, 540 and the last value of that header field is identical to the Request- 541 URI of the received request, the proxy MUST add an "aor" attribute to 542 that History-Info value. If the request did not contain a History- 543 Info header field, or if it did, but the last value is not identical 544 to the Request-URI of the received request, the proxy MUST add 545 another History-Info header field value. The URI MUST be equal to 546 the incoming Request-URI, and MUST contain an "aor" attribute. The 547 index is set as defined in [RFC4244]. 549 Once the proxy has translated the Request-URI into a registered 550 contact or configured URI, it SHOULD determine whether the 551 translation is a mapping translation or a routing translation. The 552 proxy that is responsible for the domain of the incoming request URI 553 is best equipped to make this distinction, either by configured 554 policies or by additional support from the abstract location service. 555 A Request-URI rewrite operation is considered to be a mapping 556 translation if the name or address of a user or resource is 557 translated to a name or address belonging to a different user or 558 resource. A Request-URI rewrite operation is considered to be a 559 routing translation if the name or address of a user or resource is 560 translated to an address that is a hop for reaching that user. If 561 the proxy determines the request URI translation to be a mapping 562 translation, then it MUST add a "mapped" attribute to the History- 563 Info value that records the request URI of the incoming request; in 564 all other cases it MUST add a "routed" attribute to the History-Info 565 value that records the request URI of the incoming request. Note 566 that if the proxy can not determine whether a mapping translation or 567 a routing translation takes place that it always defaults to adding a 568 "routed" attribute. 570 Once the proxy has translated the Request-URI into a registered 571 contact or configured URI, it MUST add an additional History-Info 572 header field value containing the Contact/URI for each request to be 573 forwarded. The index is set as defined in [RFC4244]. 575 If the proxy is actually redirecting and not forwarding the request, 576 it SHOULD include a History-Info URI in the response for the target. 577 That URI, if present, MUST contain the "aor" attribute. It SHOULD 578 NOT add a History-Info URI for the registered contact; the previous 579 hop proxy will do that. Note that, this rule violates a SHOULD- 580 strength rule in Section 4.3.4 of [RFC4244]. That section indicates 581 that redirections "SHOULD NOT" contain any new History-Info header 582 fields, as those will be added by the upstream server. For this 583 application however, only the downstream server knows that the 584 request URI was an AOR, and thus the History-Info header field and 585 the "aor" attribute must be added by the downstream server. 587 7.2. UA Behavior 589 7.2.1. Determining the addressed target 591 A UAS receiving a request, and wishing to determine the addressed 592 target, takes the values in the History-Info header field, and 593 traverses through them in reverse order. Note that, the value of the 594 "index" attribute is not relevant; the traversal is in order of the 595 header fields values themselves. The UAS finds the first header 596 field value containing both an "aor" parameter and a "mapped" 597 parameter, then takes the value following that hi-entry. If there is 598 no entry with a "mapped" parameter, then it takes the first History- 599 Info value. If there is no History-Info header field in the request 600 the UAS takes the addressed target from the request URI. 602 7.2.2. Determining the last AOR used to reach it 604 A UAS receiving a request, and wishing to determine the last AOR used 605 to reach it, takes the values in the History-Info header field, and 606 traverses through them in reverse order. Note that, the value of the 607 "index" attribute is not relevant; the traversal is in order of the 608 header fields values themselves. The UAS finds the first header 609 field value containing an "aor". If this header also contains a 610 "mapped" parameter then the last AOR of the user can not be 611 determined reliably, but this can be considered an fault situation 612 which should never occur. 614 Note: This is the same value that the P-Called-Party-ID header field 615 extension [RFC3455] would deliver. 617 8. The difference to P-Called-Party-Id 619 As defined in [RFC3455], if a SIP entity, which acts as registrar/ 620 home proxy for the terminating user, re-writes the Request-URI with 621 the contact address of the registered UA it may insert a P-Called- 622 Party-ID header field with the previous value of the Request-URI. 624 The last hi-entry in History-Info minted with an "aor" attribute and 625 P-Called-Party-ID header field have the same semantics. The last hi- 626 entry in History-Info minted with an "aor" attribute represents the 627 current target identity, while the P-Called-Party-ID represents the 628 last Request-URI value used to reach the user before the Request-URI 629 value was re-written with the Contact address of the UAS. In some 630 cases the P-Called-Party-ID may be the same as the addressed target 631 but, it may also be the last route taken (not equal to the current 632 target) to deliver the request. Therefore the P-Called-Party-ID can 633 not be used in a generic SIP environment to represent the current 634 target. 636 3GPP has defined procedures for the usage of P-Called-Party-ID, so 637 3GPP would need to continue to use the header, in addition to the new 638 History-Info header mechanism. However, both mechanisms can exist in 639 parallel. 641 9. Syntax 643 This specification extends the syntax of hi-param in Section 4.1 of 644 RFC 4244: 646 hi-param = hi-index / hi-aor / hi-mapped / hi-routed / hi-extension 648 hi-aor = "aor" 649 hi-mapped = "mapped" 650 hi-routed = "routed" 652 10. Security Considerations 654 The "aor" parameter indicates that a URI was subject to translation 655 by a home proxy, and consequently, acts as an explicit indicator that 656 a particular URI was an AOR for a user. This might be useful for 657 attackers wishing to farm requests for targettable URIs for purposes 658 of spamming. Of course, such attackers can utilize URIs in History- 659 Info even if they lack the "aor" attribute, so "aor" does not really 660 exacerbate this. Nonetheless, since the princpal application of the 661 "aor" parameter is delivery of a URI to a UAS within the same domain, 662 History-Info values inserted solely for this purpose SHOULD be 663 removed at the domain boundary. 665 11. References 667 11.1. Normative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, March 1997. 672 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 673 A., Peterson, J., Sparks, R., Handley, M., and E. 674 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 675 June 2002. 677 [RFC4244] Barnes, M., "An Extension to the Session Initiation 678 Protocol (SIP) for Request History Information", RFC 4244, 679 November 2005. 681 11.2. Informative References 683 [I-D.ietf-sip-gruu] 684 Rosenberg, J., "Obtaining and Using Globally Routable User 685 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 686 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 687 October 2007. 689 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 690 Protocol (SIP) and Spam", RFC 5039, January 2008. 692 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 693 using SIP Request-URI", RFC 3087, April 2001. 695 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 696 Media Services with SIP", RFC 4240, December 2005. 698 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 699 Initiation Protocol (SIP) URIs for Applications such as 700 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 701 April 2006. 703 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 704 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 705 March 1999. 707 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 708 Header (P-Header) Extensions to the Session Initiation 709 Protocol (SIP) for the 3rd-Generation Partnership Project 710 (3GPP)", RFC 3455, January 2003. 712 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 713 Resource Identifiers (URI) Dynamic Delegation Discovery 714 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 716 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 717 Enumservice Containing Public Switched Telephone Network 718 (PSTN) Signaling Information", RFC 4769, November 2006. 720 [I-D.ietf-sip-outbound] 721 Jennings, C., "Managing Client Initiated Connections in 722 the Session Initiation Protocol (SIP)", 723 draft-ietf-sip-outbound-19 (work in progress), June 2009. 725 [I-D.ietf-enum-cnam] 726 Shockey, R., "IANA Registration for an Enumservice Calling 727 Name Delivery (CNAM) Information and IANA Registration 728 for URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in 729 progress), September 2008. 731 Authors' Addresses 733 Jonathan Rosenberg 734 Cisco 735 Edison, NJ 736 US 738 Email: jdrosen@cisco.com 739 URI: http://www.jdrosen.net 741 Hans Erik van Elburg 742 Ericsson 743 Ericssonstraat 2 744 Rijen 5121 ML 745 The Netherlands 747 Email: ietf.hanserik@gmail.com 748 Christer Holmberg 749 Ericsson 750 Hirsalantie 11, Jorvas 751 Finland 753 Email: christer.holmberg@ericsson.com 755 Francois Audet 756 Nortel 758 Email: audet@nortel.com 760 Shida Schubert (editor) 761 NTT 763 Email: shida at ntt-at.com