idnits 2.17.00 (12 Aug 2021) /tmp/idnits57810/draft-rosenberg-sip-target-uri-delivery-01.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (March 08, 2009) is 4821 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) == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 -- 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: draft-ietf-sip-outbound has been published as RFC 5626 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track J. van Elburg 5 Expires: September 9, 2009 C. Holmberg 6 Ericsson 7 F. Francois 8 Nortel 9 S. Schubert (Ed.) 10 NTT 11 March 08, 2009 13 Delivery of Request-URI Targets to User Agents 14 draft-rosenberg-sip-target-uri-delivery-01 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. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 9, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 When a Session Initiation Protocol (SIP) proxy receives a request 53 targeted at a URI identifying a user or resource it is responsible 54 for, the proxy translates the URI to a registered or configured 55 contact URI of an agent representing that user or resource. In the 56 process, the original URI is removed from the request. Numerous use 57 cases have arisen which require this information to be delivered to 58 the user agent. This document describes these use cases and defines 59 an extension to the History-Info header field which allows it to be 60 used to support those cases. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. retarget . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 4 70 4.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 5 72 4.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 5 73 4.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 6 74 4.6. Freephone Numbers . . . . . . . . . . . . . . . . . . . . 6 75 5. Architectural Roots of the Problem . . . . . . . . . . . . . . 7 76 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 77 7. Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 11 79 7.2. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. The difference to P-Called-Party-Id . . . . . . . . . . . . . 12 81 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 A key part of the behavior of proxy servers and B2BUA in the Session 91 Initiation Protocol (SIP) [RFC3261] is that they rewrite the Request- 92 URI of requests as the request moves from the User Agent Client (UAC) 93 to the User Agent Server (UAS). This is particularly true for 94 requests outside of a dialog; requests within a dialog have their 95 path dictated primarily by the Route header fields established by the 96 Record-Routes when the dialog was initiated. 98 The most basic instance of this behavior is the processing executed 99 by the "home proxy" within a domain. The home proxy is the proxy 100 server within a domain which accesses the location information 101 generated by REGISTER messages, and uses it to forward a request 102 towards a UAC. Based on the rules in [RFC3261], when a home proxy 103 receives a SIP request, it looks up the Request-URI in the location 104 database or mapping table, and translates it to the contact(s) that 105 were registered by the UA or configured in the mapping table. This 106 new contact URI replaces the existing Request URI, and causes the 107 request to be forwarded towards the target UA. Consequently, the 108 original contents of the Request URI are lost. 110 Over the years, this practice of rewriting the Request-URI has proven 111 problematic. Section 4 describes the problems with this mechanism. 112 Section 5 analyzes the architectural issues which drive these 113 problems. Section 6 overviews a mechanism to solve this problem by 114 extending the History-Info header field. Section 7 describes 115 detailed procedures for user agents and proxies. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Definitions 125 3.1. retarget 127 A Request-URI rewrite operation is considered to be a retargeting 128 operation if the entity to which the request is ultimately delivered 129 could not, based on the policies of the domain of that entity, place 130 the URI prior to translation in the From header field, and have an 131 identity service in its domain sign it. The inverse is not true 132 however. If an entity can legitimately claim the identity prior to 133 the translation operation, it may still be a retargeting. In this 134 case, it is a matter of domain policy about whether it is or not. 136 4. Problem Statement 138 Several problems arise from the practice of rewriting the request 139 URI. 141 4.1. Unknown Aliases 143 SIP user agents are associated with an address-of-record (AOR). It 144 is possible for a single UA to actually have multiple AOR associated 145 with it. One common usage for this is aliases. For example, a user 146 might have an AOR of sip:john@example.com but also have the AORs 147 sip:john.smith@example.com and sip:jsmith@example.com. Rather than 148 registering against each of these AORs individually, the user would 149 register against just one of them, and the home proxy would 150 automatically accept incoming calls for any of the aliases, treating 151 them identically and ultimately forwarding them towards the UA. This 152 is common practice in the Internet Multimedia Subsystem (IMS), where 153 it is called implicit registrations and each alias is called a public 154 identity. 156 It is a common requirement for a UAS, on receipt of a call, to know 157 which of its aliases was used to reach it. This knowledge can be 158 used to choose ringtones to play, determine call treatment, and so 159 on. For example, a user might give out one alias to friends and 160 family only, resulting in a special ring that alerts the user to the 161 importance of the call. 163 However, based on the procedures in [RFC3261], when an incoming call 164 hits the home proxy, the request URI (which contains the alias) is 165 rewritten to the registered contact(s). Consequently, the alias that 166 was used is lost, and cannot be known to the UAS. 168 4.2. Unknown GRUU 170 A variation on the problem in Section 4.1 occurs with Globally 171 Routable User Agent URI (GRUU) [I-D.ietf-sip-gruu]. A GRUU is a URI 172 assigned to a UA instance which has many of the same properties as 173 the AOR, but causes requests to be routed only to that specific 174 instance. It is desirable for a UA to know whether it was reached 175 because a correspondent sent a request to its GRUU or to its AOR. 176 This can be used to drive differing authorization policies on whether 177 the request should be accepted or rejected, for example. However, 178 like the AOR itself, the GRUU is lost in translation at the home 179 proxy. Thus, the UAS cannot know whether it was contacted via the 180 GRUU or its AOR. 182 4.3. Limited Use Addresses 184 A limited use address is an SIP URI that is minted on-demand, and 185 passed out to a small number (usually one) remote correspondent. 186 Incoming calls targeted to that limited use address are accepted as 187 long as the UA still desires communications from the remote target. 188 Should they no longer wish to be bothered by that remote 189 correspondent, the URI is invalidated so that future requests 190 targeted to it are rejected. 192 Limited use addresses are used in battling voice spam [RFC5039]. The 193 easiest way to provide them would be for a UA to be able to take its 194 AOR, and "mint" a limited use address by appending additional 195 parameters to the URI. It could then give out the URI to a 196 particular correspondent, and remember that URI locally. When an 197 incoming call arrives, the UAS would examine the parameter in the URI 198 and determine whether or not the call should be accepted. 199 Alternatively, the UA could push authorization rules into the 200 network, so that it need not even see incoming requests that are to 201 be rejected. 203 This approach, especially when executed on the UA, requires that 204 parameters attached to the AOR, but not used by the home proxy in 205 processing the request, will survive the translation at the home 206 proxy and be presented to the UA. This will not be the case with the 207 logic in RFC 3261, since the Request-URI is replaced by the 208 registered contact, and any such parameters are lost. 210 4.4. Sub-Addressing 212 Sub-Addressing is very similar to limited use addresses. Sub- 213 addresses are addresses within a subdomain that are multiplexed into 214 a single address within a parent domain. The concept is best 215 illustrated by example. Consider a VoIP service provided to 216 consumers. A consumer obtains a single address from its provider, 217 say sip:family@example.com. However, Joe is the patriarch of a 218 family with four members, and would like to be able to have a 219 separate identifier for each member of his family. One way to do 220 that, without requiring Joe to purchase new addresses for each member 221 from the provider, is for Joe to mint additional URI by adding a 222 parameter to the AOR. For example, his wife Judy with have the URI 223 sip:family@example.com;member=judy, and Joe himself would have the 224 URI sip:family@example.com;member=joe. The SIP server provider would 225 receive requests to these URI, and ignoring the unknown parameters 226 (as required by [RFC3261]) route the request to the registered 227 contact, which corresponds to a SIP server in Joes home. That 228 server, in turn, can examine the URI parameters and determine which 229 phone in the home to route the call to. 231 This feature is not specific to VoIP, and has existing in Integrated 232 Services Digital Networking (ISDN) for some time. It is particularly 233 useful for small enterprises, in addition to families. It is also 234 similar in spirit (though not mechanism) to the ubiquitous home 235 routers used by consumers, which allow multiple computers in the home 236 to "hide" behind the single IP address provided by the service 237 provider, by using the TCP and UDP port as a sub-address. 239 The sub-addressing feature is not currently feasible in SIP because 240 of the fact that any SIP URI parameter used to convey the sub-address 241 would be lost at the home proxy, due to the fact that the Request-URI 242 is rewritten there. 244 4.5. Service Invocation 246 Several SIP specifications have been developed which make use of 247 complex URIs to address services within the network rather than 248 subscribers. The URIs are complex because they contain numerous 249 parameters that control the behavior of the service. Examples of 250 this include the specification which first introduced the concept, 251 [RFC3087], control of network announcements and IVR with SIP URI 252 [RFC4240], and control of voicemail access with SIP URI [RFC4458]. 254 A common problem with all of these mechanisms is that once a proxy 255 has decided to rewrite the Request-URI to point to the service, it 256 cannot be sure that the Request-URI will not be destroyed by a 257 downstream proxy which decides to forward the request in some way, 258 and does so by rewriting the Request-URI. 260 4.6. Freephone Numbers 262 Freephone numbers, also known as 800 or 8xx numbers in the United 263 States, are telephone numbers that are free for users to call 264 (although the author will note that such notions are becoming less 265 important as billing models evolve, and harken back to an era where 266 phone service depended on global agreement on such billing concepts). 268 In the telephone network, freephone numbers are just aliases to 269 actual numbers which are used for routing of the call. In order to 270 process the call in the PSTN, a switch will perform a query (using a 271 protocol called TCAP), which will return either a phone number or the 272 identity of a carrier which can handle the call. 274 There has been recent work on allowing such PSTN translation services 275 to be accessed by SIP proxy servers through IP querying mechanisms. 276 ENUM, for example [RFC3761] has already been proposed as a mechanism 277 for performing Local Number Portability (LNP) queries [RFC4769], and 278 recently been proposed for performing calling name queries 280 [I-D.ietf-enum-cnam]. Using it for 8xx number translations is a 281 logical next-step. 283 Once such a translation has been performed, the call needs to be 284 routed towards the target of the request. Normally, this would 285 happen by selecting a PSTN gateway which is a good route towards the 286 translated number. However, one can imagine all-IP systems where the 287 8xx numbers are SIP endpoints on an IP network, in which case the 288 translation of the 8xx number would actually be a SIP URI and not a 289 phone number. Assuming for the moment it is a PSTN connected entity, 290 the call would be routed towards a PSTN gateway. Proper treatment of 291 the call in the PSTN (and in particular, correct reconciliation of 292 billing records) requires that the call be marked with both the 293 original 8xx number AND the target number for the call. However, in 294 our example here, since the translation was performed by a SIP proxy 295 upstream from the gateway, the original 8xx number would have been 296 lost, and the call will not interwork properly with the PSTN. 298 Similar problems arise with other "special" numbers and services used 299 in the PSTN, such as operator services, pay numbers (9xx numbers in 300 the U.S), and short service codes such as 311. 302 5. Architectural Roots of the Problem 304 There is a common theme across all of the problems in Section 4, and 305 this theme is the confounding of names, routes, and addresses. 307 A name is a moniker for an entity which refers to it in a way which 308 reveals nothing about where it is in a network. In SIP, tel URI 309 which doesn't represent the location of the entity is a name. An 310 address is an identifier for an entity which describes it by its 311 location on the network. In SIP, the SIP URI itself is a form of 312 address because the host part of the URI, the only mandatory part of 313 the URI besides the scheme itself, indicates the location of a SIP 314 server that can be used to handle the request. Finally, a route is a 315 sequence of SIP entities (including the UA itself!) which are 316 traversed in order to forward a request to an address or name. 318 SIP, unfortunately, uses the Request-URI as a mechanism for routing 319 of the request in addition to using it as the mechanism for 320 identifying the name or address to which the request was targeted. A 321 home proxy rewrites the Request-URI because that rewriting is the 322 vehicle by which the request is forwarded to the target of the 323 request. However, this rewritten URI (the contact from the 324 register), is not in any way a meaningful name or address for the UA. 325 Indeed, with specifications like SIP outbound 326 [I-D.ietf-sip-outbound], even the IP address within the registered 327 contact is meaningless since the flow on which the REGISTER is sent 328 is used rather than the IP address. Consequently, the home proxy is 329 fundamentally replacing the *address* in the Request-URI with a 330 *route* to reach that UA. This architectural mistake is the cause of 331 the problems described above. 333 Interestingly, this same mistake was present in [RFC2543] for the 334 handling of mid-dialog requests. It was fixed through the loose 335 routing mechanism in RFC 3261, which used Route header fields to 336 identify each hop to visit for a mid-dialog request, and separated 337 this from the Request-URI, which identified the ultimate target of 338 the request (the remote UA), and remained unmodified in the 339 processing of the request. 341 Unfortunately, application of this same technique to address the 342 problem at hand cannot be done in a backwards compatible manner. 343 Consequently, some other means is needed to clearly identify which 344 URIs are addresses, and which are routes. To avoid confusion, we 345 refer to a SIP URI that is an address for a user or resource as a 346 "target" and a SIP URI that is a hop for reaching that user as a 347 "hop". 349 6. Solution Overview 351 The History-Info header field, defined in [RFC4244], defines a 352 mechanism by which an enumeration of the URIs traversed can be passed 353 to both the UAC and UAS. History-Info was designed to provide a 354 general purpose mechanism which can support the needs of many 355 applications, including diagnostics and traditional telephony 356 features like voicemail. Were a home proxy to implement History- 357 Info, it would provide a means for that proxy to deliver the target 358 URI to the UAS. 360 Unfortunately, History-Info makes no distinction between URIs that 361 are targets and URIs that are hops. Consequently, if there were 362 additional proxies downstream of the home proxy which modified the 363 Request-URI in any way, the UA would have no way to know which URI in 364 the list of History-Info values was actually the target. To remedy 365 that, this document defines an extension to the History-Info header 366 field which indicates whether the URI is a target or not. 368 When a home proxy receives a request for a user or resource for which 369 it has a registration, the proxy adds two History-Info header field 370 values. The first is the incoming request URI. Since the Request- 371 URI identifies a user or resource for which it has a registration, 372 the Request-URI is an AOR and thus an address for the user. The 373 proxy adds a History-Info header field parameter, "istarget", which 374 indicates this. Next, the proxy inserts the contact URI it used in 375 the outgoing Request-URI. No "istarget" parameter is included in 376 this History-Info value. 378 For a UA to determine the URI target, it need only walk backwards 379 through the list of HI values, and take the first one containing the 380 "istarget" parameter. 382 For example, consider the architecture in Figure 1. In the example 383 user A calls user B. User B is in example.com. The call from A to B 384 passes through A's outbound proxy, their home proxy, B's home proxy, 385 and B's outbound proxy, prior to reaching B. B's home proxy, H-B, 386 performs the translation of the R-URI to the registered contact based 387 on the registration database. Consequently, it adds two History-Info 388 header fields, the first of which represents the incoming R-URI and 389 includes the "istarget" parameter. 391 +-------+ +-------+ +-------+ +-------+ 393 //--\\ | | | | | | | | //--\\ 395 | A |--- | OB-A |----| H-A |---| H-B |---| OB-B |--| B | 397 | | | | | | | | | | | | 399 \\--// +-------+ +-------+ +-------+ +-------+ \\--// 401 INVITE 403 sip:B@example.com 405 ------------> 407 INVITE 409 sip:B@example.com 411 ------------> 413 INVITE 415 sip:B@example.com 417 ------------> 419 INVITE 421 sip:B@example.com 423 HI: index=1;istarget, 425 ;index=1.1 427 ------------> 429 Figure 1: Target URI Example 431 7. Detailed Semantics 433 The "istarget" parameter in the History-Info header field indicates 434 that the URI that it parameterizes was either subject to a lookup in 435 a location service created through the registration process of the UA 436 or was available through configured mapping. Furthermore, if that 437 URI had an 'index' of N, the URIs with indices N.M for all M, are the 438 registered contacts to that URI. 440 7.1. Proxy Behavior 442 A proxy compliant to this specification SHOULD add a History-Info 443 header field value to a request under the following conditions: 445 o The proxy is responsible for the domain in AOR in the Request-URI 447 o The proxy will be translating the contents of the Request-URI to 448 one or more contacts either based on a location database populated 449 through REGISTER requests from user agents or based on configured 450 mapping. 452 o The R-URI exists in the location database. 454 The proxy SHOULD populate the History-Info header field regardless of 455 whether there is a Supported header field with value 'histinfo'. If 456 the incoming request already contains a History-Info header field, 457 and the last value of that header field is identical to the Request- 458 URI of the received request, the proxy MUST add a "istarget" 459 attribute to that History-Info value. If the request did not contain 460 a History-Info header field, or if it did, but the last value is not 461 identical to the Request-URI of the received request, the proxy MUST 462 add another History-Info header field value. The URI MUST be equal 463 to the incoming Request-URI, and MUST contain a "istarget" attribute. 464 The index is set as defined in [RFC4244]. 466 Once the proxy has translated the Request-URI into a registered 467 contact or configured contact, it MUST add an additional History-Info 468 header field value containing the Contact URI for each request to be 469 forwarded. The "istarget" attribute MUST NOT be present. The index 470 is set as defined in [RFC4244]. 472 Since the principal purpose of the "istarget" parameter is to 473 indicate, to a UAS, the target URI by which it was reached, there is 474 no need for the History-Info header field values to be passed outside 475 of the domain which inserted them, unless there is an apparent need 476 for passing on the value downstream (e.g. freephone number). 478 If the proxy is actually redirecting and not forwarding the request, 479 it SHOULD include a History-Info URI in the response for the target. 480 That URI, if present, MUST contain the "istarget" attribute. It 481 SHOULD NOT add a History-Info URI for the registered contact; the 482 previous hop proxy will do that. Note that, this rule violates a 483 SHOULD-strength rule in Section 4.3.4 of [RFC4244]. That section 484 indicates that redirections "SHOULD NOT" contain any new History-Info 485 header fields, as those will be added by the upstream server. For 486 this application however, only the downstream server knows that the 487 R-URI was a target, and thus the History-Info header field and the 488 "istarget" attribute must be added by the downstream server. 490 7.2. UA Behavior 492 A UAS receiving a request, and wishing to determine the original 493 target dialog, takes the values in the History-Info header field, and 494 traverses through them in reverse order. Note that, the value of the 495 "index" attribute is not relevant; the traversal is in order of the 496 header fields values themselves. The UAS finds the first header 497 field value containing the "istarget" parameter. If such a value 498 does not exist, the target URI cannot be reliably determined. If it 499 does exist, the URI is examined. If the domain of the URI matches 500 the domain of the UA, based on the UA's configured awareness of its 501 own domain, that URI is the target URI. If the domains do not match, 502 the target URI cannot be reliably determined. This domain check is 503 present to handle cases where a request is forwarded through two 504 separate domains, and the domain of the actual UAS didn't support 505 this specification, but the previous domain did. If there are more 506 than one header field value containing "istarget" parameter, handling 507 of second and latter value with "istarget" parameter is up to local 508 policy and is outside the scope of this document. For example, if 509 freephone number was invoked, there may be two header field value 510 with "istarget" parameter;one indicating the retargeting of freepone 511 number to a corporate address and another indicating the retargeting 512 of corporate address to a registered contact. 514 NOTE: Do we want to introduce another parameter to indicated the 515 difference between retargeting based on location lookup and 516 configured mapping? 518 Beyond this, there is no special UA processing associated with the 519 "istarget" parameter. 521 8. The difference to P-Called-Party-Id 523 As defined in [RFC3455], if a SIP entity, which acts as registrar/ 524 home proxy for the terminating user, re-writes the Request-URI with 525 the contact address of the registered UA it may insert a P-Called- 526 Party-ID header field with the previous value of the Request-URI. 528 The last hi-entry in History-Info minted with an "istarget" attribute 529 and P-Called-Party-ID header field have different semantics. The 530 last hi-entry in History-Info minted with an "istarget" attribute 531 represents the current target identity, while the P-Called-Party-ID 532 represents the last Request-URI value used to reach the user before 533 the Request-URI value was re-written with the Contact address of the 534 UAS. In some cases the P-Called-Party-ID may be the same as the 535 current target but, it may also be the last route taken (not equal to 536 the current target) to deliver the request. Therefore the P-Called- 537 Party-ID can not be used in a generic SIP environment to represent 538 the current target. 540 3GPP has defined procedures for the usage of P-Called-Party-ID, so 541 3GPP would need to continue to use the header, in addition to the new 542 Target header. However, both mechanisms can exist in parallel. 544 9. Syntax 546 This specification extends the syntax of hi-param in Section 4.1 of 547 RFC 4244: 549 hi-param = hi-index / hi-target / hi-extension 551 hi-target = "istarget" 553 10. Security Considerations 555 The "istarget" parameter indicates that a URI was subject to 556 translation by a home proxy, and consequently, acts as an explicit 557 indicator that a particular URI was an AOR for a user. This might be 558 useful for attackers wishing to farm requests for targettable URIs 559 for purposes of spamming. Of course, such attackers can utilize URIs 560 in History-Info even if they lack the "istarget" attribute, so 561 "istarget" does not really exacerbate this. Nonetheless, since the 562 princpal application of the "istarget" parameter is delivery of a URI 563 to a UAS within the same domain, History-Info values inserted solely 564 for this purpose SHOULD be removed at the domain boundary. 566 11. References 567 11.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 573 A., Peterson, J., Sparks, R., Handley, M., and E. 574 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 575 June 2002. 577 [RFC4244] Barnes, M., "An Extension to the Session Initiation 578 Protocol (SIP) for Request History Information", RFC 4244, 579 November 2005. 581 11.2. Informative References 583 [I-D.ietf-sip-gruu] 584 Rosenberg, J., "Obtaining and Using Globally Routable User 585 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 586 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 587 October 2007. 589 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 590 Protocol (SIP) and Spam", RFC 5039, January 2008. 592 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 593 using SIP Request-URI", RFC 3087, April 2001. 595 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 596 Media Services with SIP", RFC 4240, December 2005. 598 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 599 Initiation Protocol (SIP) URIs for Applications such as 600 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 601 April 2006. 603 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 604 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 605 March 1999. 607 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 608 Header (P-Header) Extensions to the Session Initiation 609 Protocol (SIP) for the 3rd-Generation Partnership Project 610 (3GPP)", RFC 3455, January 2003. 612 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 613 Resource Identifiers (URI) Dynamic Delegation Discovery 614 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 616 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 617 Enumservice Containing Public Switched Telephone Network 618 (PSTN) Signaling Information", RFC 4769, November 2006. 620 [I-D.ietf-sip-outbound] 621 Jennings, C. and R. Mahy, "Managing Client Initiated 622 Connections in the Session Initiation Protocol (SIP)", 623 draft-ietf-sip-outbound-16 (work in progress), 624 October 2008. 626 [I-D.ietf-enum-cnam] 627 Shockey, R., "IANA Registration for an Enumservice Calling 628 Name Delivery (CNAM) Information and IANA Registration 629 for URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in 630 progress), September 2008. 632 Authors' Addresses 634 Jonathan Rosenberg 635 Cisco 636 Edison, NJ 637 US 639 Email: jdrosen@cisco.com 640 URI: http://www.jdrosen.net 642 Hans Erik van Elburg 643 Ericsson 644 Ericssonstraat 2 645 Rijen 5121 ML 646 The Netherlands 648 Email: HansErik.van.Elburg@ericsson.com 650 Christer Holmberg 651 Ericsson 652 Hirsalantie 11, Jorvas 653 Finland 655 Email: christer.holmberg@ericsson.com 656 Francois Audet 657 Nortel 659 Email: audet@nortel.com 661 Shida Schubert (editor) 662 NTT 664 Email: shida at ntt-at.com