idnits 2.17.1 draft-vanelburg-sipping-served-user-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 657. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 18, 2008) is 5637 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3427 (ref. '5') (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 4244 (ref. '7') (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. van Elburg 3 Internet-Draft Ericsson Telecommunicatie B.V. 4 Intended status: Informational November 18, 2008 5 Expires: May 22, 2009 7 The Session Initiation Protocol (SIP) P-Served-User Private-Header 8 (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem 9 draft-vanelburg-sipping-served-user-08.txt 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 May 22, 2009. 36 Abstract 38 This document specifies the SIP P-Served-User P-header. This header 39 field addresses an issue that was found in the 3rd-Generation 40 Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an 41 S-CSCF (Serving Call Session Control Function) and an AS (Application 42 Server) on the ISC (IMS Subsystem Service Control) interface. This 43 header field conveys the identity of the served user and the session 44 case that applies to this particular communication session and 45 application invocation. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Identity, Network Asserted Identity, Trust Domain and 53 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Served User . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Diversion; continue on terminating leg, but finish 58 subsequent terminating iFC first . . . . . . . . . . . . . 5 59 4.3. Diversion; create new originating leg and provide 60 originating iFC processing . . . . . . . . . . . . . . . . 6 61 4.4. Call out of the blue; on behalf of user B, but service 62 profile of service identity C . . . . . . . . . . . . . . 8 63 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. P-Served-User header field Definition . . . . . . . . . . . . 8 65 7. Proxy behaviour . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Generating the P-Served-User header . . . . . . . . . . . 9 67 7.2. Consuming the P-Served-User header . . . . . . . . . . . . 9 68 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Why the History-Info header is not suitable to 76 convey the served user information on the ISC 77 interface . . . . . . . . . . . . . . . . . . . . . . 13 78 A.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 13 79 A.2. Additional Observations . . . . . . . . . . . . . . . . . 13 80 A.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Intellectual Property and Copyright Statements . . . . . . . . . . 15 84 1. Introduction 86 The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia 87 Subsystem) uses SIP (RFC 3261 [2]) as its main signaling protocol. 88 (For more information on the IMS, a detailed description can be found 89 in 3GPP TS 23.228 [9] and 3GPP TS 24.229 [11].) 3GPP has identified 90 issues with the linking in of a SIP application server that are most 91 appropriately resolved by defining a new SIP P-header, according to 92 the procedures in RFC 3427 [5]. 94 The remainder of this document is organized as follows. Section 4 95 outlines the problem using particular service scenarios and Section 5 96 discusses the requirements derived from these scenarios. Section 6 97 defines the P-Served-User header field, which meets those 98 requirements, and Section 8 discusses the applicability and scope of 99 this new header field. Section 9 registers the P-Served-User header 100 field with the IANA and Section 10 discusses the security properties 101 of the environment where this header field is intended to be used. 103 2. Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 109 3. Definitions 111 3.1. Identity, Network Asserted Identity, Trust Domain and Spec(T) 113 The terms Identity, Network Asserted Identity, Trust Domain and 114 Spec(T) in this document are specified in RFC 3324 [3]. 116 3.2. Served User 118 The served user to an S-CSCF (Serving Call Session Control Function) 119 or AS (Application Server) is the user whose service profile is 120 accessed by that S-CSCF or AS when an initial request is received 121 originated by, originated on behalf of or terminated to that user; 122 this profile in turn provides some useful information (preferences or 123 permissions) for processing at an S-CSCF and potentially at an AS. 125 4. Scenarios 126 4.1. General 128 In the 3GPP IMS (IP Multimedia Subsystem) the S-CSCF (Serving CSCF) 129 is a SIP proxy that serves as a registrar and handles originating and 130 terminating session states for users allocated to it. This means 131 that any call that is originated by a specific user or any call that 132 is terminated to that specific user will pass through the S-CSCF that 133 is allocated to that user. 135 At the moment that an S-CSCF is allocated for a specific user, a user 136 profile is downloaded to the S-CSCF from the HSS (Home Subscriber 137 Server) over the Cx interface. This user profile tells the S-CSCF 138 whether the user is allowed to originate or terminate calls or 139 whether an AS needs to be linked in over the ISC interface. The user 140 profile information that determines whether a particular initial 141 request needs to be sent to a particular AS is called initial Filter 142 Criteria (iFC), see for example 3GPP TS 23.218 [8]. 144 For an S-CSCF to be able to meet its responsibilities, it needs to 145 determine on which user's behalf it is performing its tasks and which 146 session case is applicable for the particular request. (For a 147 definition of session case see 3GPP TS 29.228 [12]) The session case 148 distinguishes the originating and terminating call cases and whether 149 the particular user is registered or not. 151 When the S-CSCF determines that for an incoming initial request the 152 originating call case applies, it determines the served user by 153 looking at the P-Asserted-Identity header field (RFC 3325 [4]) which 154 carries the network asserted identity of the originating user. When 155 after processing the iFC for this initial request, the S-CSCF decides 156 to forward the request to an AS, the AS has to go through a similar 157 process of determining the session case and the served user. Since 158 it should come to the same conclusion that this is an originating 159 session case, it also has to look at the P-Asserted-Identity header 160 field to determine the served user 162 When the S-CSCF determines that for an incoming initial request the 163 terminating call case applies, it determines the served user by 164 looking at the Request-URI (RFC 3261 [2]) which carries the identity 165 of the intended terminating user. When after processing the iFC for 166 this initial request, the S-CSCF decides to forward the request to an 167 AS, the AS has to go through a similar process of determining the 168 session case and the served user. Since it should come to the same 169 conclusion that this is a terminating session case, it also has to 170 look at the Request-URI to determine the served user. 172 In the originating case it can be observed that while the P-Asserted- 173 Identity header field just represents the originating user when it 174 enters the S-CSCF, it is overloaded with another meaning when it is 175 sent to an AS over the ISC interface. This other meaning is that it 176 serves as a representation of the served user. 178 In the terminating case a similar overloading happens to the Request- 179 URI, while it first only represented the identity of the intended 180 terminating user, it is overloaded with another meaning when it is 181 sent to an AS over the ISC interface. This other meaning is that it 182 serves as a representation of the served user. 184 In basic call scenarios this does not show up as a problem, but once 185 more complicated service scenarios (notably forwarding services) 186 needs to be realized, it poses severe limitations. Such scenarios 187 are brought forward in the following sub sections. 189 4.2. Diversion; continue on terminating leg, but finish subsequent 190 terminating iFC first 192 Imagine a service scenario where a user B has a terminating service 193 that diverts the call to a different destination, but it is required 194 that subsequent terminating services for the same user are still 195 executed. This means that this particular user has multiple iFC 196 configured that are applicable for an incoming initial request. When 197 the S-CSCF receives an initial INVITE request it analyses the request 198 and determines that the session case is for a terminating registered 199 user, then it determines the served user to be user B by looking at 200 the Request-URI. 202 Now the S-CSCF starts the iFC processing, the first iFC that matches 203 the INVITE request causes the INVITE to be forwarded over the ISC 204 interface to an AS that hosts user B's diversion service, by adding 205 the AS and S-CSCF's own hostnames to the Route header. The S-CSCF 206 adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname 207 on the Route header. This allows the S-CSCF to correlate an INVITE 208 coming from an AS over the ISC interface to the existing session that 209 forwarded the INVITE to the AS in the first place. 211 When the AS receives the initial INVITE request it analyses the 212 request and determines that the session case is for a terminating 213 registered user, then it determines the served user to be user B by 214 looking at the Request-URI. Based on some criteria, the diversion 215 service concludes that the request needs to be diverted to another 216 user or application C. It does this by changing the Request-URI to C. 217 Optionally it records the Request-URI history by using the History- 218 Info header field (RFC 4244 [7]). Then the AS removes itself from 219 the Route header and routes the INVITE request back to the S-CSCF by 220 using the topmost Route header field. 222 When the S-CSCF receives the INVITE over the ISC interface it can see 223 that the Route header contains its own hostname and an ODI that 224 correlates to an existing terminating session for user B. This can be 225 used by the S-CSCF to analyze whether there are still unexecuted iFC. 226 (Note that the current behavior of the S-CSCF on receiving an INVITE 227 with a changed Request-URI is to terminate the iFC processing and to 228 route the request based on the new Request-URI value.) 230 The process repeats itself, the INVITE is forwarded to the AS that is 231 associated with this particular iFC. When the AS receives the 232 initial INVITE request it analyses the request and determines that 233 the session case is for a terminating registered user, then it 234 determines the served user to be user C by looking at the Request- 235 URI. This is clearly wrong as the user being served is still user B. 237 This scenario clearly shows the problem that occurs when the Request- 238 URI is overloaded with the meanings "intended target identity" and 239 "served user" with the operation as described in Section 4.1. And it 240 shows that this use case can not be realized without introducing a 241 mechanism that conveys information about the served user from the 242 S-CSCF to the AS. Use of the History-Info element does not solve 243 this problem as it does not tell the AS which user is being served, 244 but just presents a history of diversions that might not be even 245 caused by the systems serving this particular user. A more detailed 246 analysis on why the History-Info header field can't be used is 247 provided in Appendix A. 249 4.3. Diversion; create new originating leg and provide originating iFC 250 processing 252 Imagine a service scenario where a user B has a terminating service 253 that diverts the call to a different destination. It is required 254 that forwarded call leg is handled as an originating call leg and 255 that originating services for user B are executed. This means that 256 this particular user has one or more iFC configured that are 257 applicable for an outgoing initial request. 259 When the S-CSCF receives an initial INVITE request, it analyses the 260 request and determines that the session case is for a terminating 261 registered user, then it determines the served user to be user B by 262 looking at the Request-URI. 264 Now the S-CSCF starts the iFC processing, the first iFC that matches 265 the INVITE request causes the INVITE to be forwarded over the ISC 266 interface to an AS that hosts user B's diversion service, by adding 267 the AS and S-CSCF's own hostnames to the Route header. The S-CSCF 268 adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname 269 on the Route header, this allows the S-CSCF to correlate an INVITE 270 coming from an AS over the ISC interface to the existing session that 271 forwarded the INVITE to the AS in the first place. 273 When the AS receives the initial INVITE request, it analyses the 274 request and determines that the session case is for a terminating 275 registered user, then it determines the served user to be user B by 276 looking at the Request-URI. Based on some criteria the diversion 277 service concludes that the request needs to be diverted to another 278 user or application C. It does this by changing the Request-URI to C. 279 Optionally it records the Request-URI history by using the History- 280 Info header field (RFC 4244 [7]). Then the AS removes itself from 281 the Route header. To make sure that the request is handled as a new 282 originating call on behalf of user B, the AS adds the "orig" 283 parameter to the topmost route header. Then it routes the INVITE 284 request back to the S-CSCF by using this topmost Route header field. 286 When the S-CSCF receives the INVITE over the ISC interface, it can 287 see that the topmost Route header contains its own hostname and an 288 "orig" parameter. Because the topmost Route header contains the 289 "orig" parameter, the S-CSCF concludes that the INVITE should be 290 handled as if a call is originated by the served user. The served 291 user is determined from the P-Asserted-Identity header to be user A. 292 This is clearly wrong as the user being served is and should be user 293 B. 295 For the sake of discussion lets assume that the S-CSCF can determine 296 that the served user is user B. Then the procedure would continue as 297 follows: The S-CSCF starts the originating iFC processing, the first 298 iFC that matches the INVITE request causes the INVITE to be forwarded 299 over the ISC interface to an AS that hosts an originating service of 300 user B, by adding the AS and S-CSCF's own hostnames to the Route 301 header. The S-CSCF adds an Original Dialog Identifier (ODI) to the 302 S-CSCF's own hostname on the Route header. 304 The INVITE is forwarded to the AS that is associated with this 305 particular iFC. When the AS receives the initial INVITE request it 306 analyses the request and determines that the session case is for an 307 originating registered user, then it determines the served user to be 308 user A by looking at the P-Asserted-Identity. This is clearly wrong 309 as the user being served is and should be user B. 311 This scenario clearly shows the problem that occurs when the 312 P-Asserted-Identity is overloaded with the meanings "call originator" 313 and "served user" with the operation as described in chapter 314 Section 4.1. And it shows that this use case can not be realized 315 without introducing a mechanism that conveys information about the 316 served user from the S-CSCF to the AS and from the AS to the S-CSCF. 317 Use of the History-Info element does not solve this problem as it 318 does not tell the AS which user is being served, but just presents a 319 history of diversions that might not be even caused by the systems 320 serving this particular user. A more detailed analysis on why the 321 History-Info header field can't be used is provided in Appendix A. 323 4.4. Call out of the blue; on behalf of user B, but service profile of 324 service identity C 326 There are services that need to be able to initiate a call, whereby 327 the call appears to be coming from a user B, but service profile on 328 behalf of service identity C needs to be executed in the S-CSCF. 330 When a call needs to appear as coming from user B, that means that 331 the P-Asserted-Identity needs to contain B's identity. This is 332 because the Originating Identity Presentation (OIP) service as 333 defined in 3GPP TS 24.173 [10] uses the P-Asserted-Identity to 334 present the call originator. Which makes sense because that is the 335 main meaning expressed by the P-Asserted-Identity header field. 337 It is clear that no INVITE request can be constructed currently that 338 would achieve both requirements expressed in the first paragraph, 339 because the P-Asserted-Identity is overloaded with two meanings on 340 the ISC interface. When the S-CSCF will receive this request it will 341 determine that the served user is user B, which is not what we want 342 to achieve. 344 5. Requirements 346 This section lists the requirements derived from the previous 347 scenarios: 349 1. To be able to offer real world application services it is 350 required that the identity of the served user can be conveyed on 351 the ISC interface (see 3GPP TS 23.218 [8]). 352 2. To be able to offer appropriate services to the served user it is 353 required that in addition to the served user identity the session 354 case is conveyed. 356 6. P-Served-User header field Definition 358 This document defines the SIP P-Served-User P-header. This header 359 field can be added to initial requests for a dialog or standalone 360 requests routed from a node in a Trust Domain for served user like 361 for example between an S-CSCF and an AS. The P-Served-User P-header 362 contains an identity of the user that is (to be) served by the 363 S-CSCF. The sescase parameter may be used to convey whether the 364 initial request is originated by or destined for the served user. 365 The regstate parameter may be used by the S-CSCF towards an AS to 366 indicate whether the initial request is for a registered or an 367 unregistered user. 369 The augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the 370 P-Served-User header field is the following: 372 P-Served-User = "P-Served-User" HCOLON PServedUser-value 373 *(SEMI served-user-param) 374 served-user-param = sessioncase-param 375 / registration-state-param 376 / generic-param 377 PServedUser-value = name-addr / addr-spec 378 sessioncase-param = "sescase" EQUAL "orig" / "term" 379 registration-state-param = "regstate" EQUAL "unreg" / "reg" 381 EQUAL, HCOLON, SEMI, name-addr, addr-spec and generic-param are 382 defined in RFC 3261 [2]. 384 The following is an example of a P-Served-User header field: 386 P-Served-User: ; sescase=orig; regstate=reg 388 7. Proxy behaviour 390 7.1. Generating the P-Served-User header 392 Proxies that support the header MUST only insert the header in 393 initial requests for a dialog or standalone requests when the 394 following conditions hold: 395 o The proxy has the capability to determine the served user for the 396 current request. 397 o The next hop is part of the same Trust Domain for P-Served-User. 399 When the above conditions do not hold the proxy MUST NOT insert the 400 header. 402 7.2. Consuming the P-Served-User header 404 A proxy that supports the header, MUST upon receiving from a trusted 405 node the P-Served-User header in initial requests for a dialog or 406 standalone requests take the value of the P-Served-User header to 407 represent the served user in operations that require such 408 information. 410 A proxy that supports the header, MUST remove the header from 411 requests or responses when the header was received from a node 412 outside the Trust Domain for P-Served-User before further forwarding 413 the message. 415 A proxy that supports the header, MUST remove the header from 416 requests or responses when the next hop is a node outside the Trust 417 Domain for P-Served-User before further forwarding the message. 419 8. Applicability 421 According to RFC 3427 [5], P-headers have a limited applicability. 422 Specifications of P-headers such as this RFC need to clearly document 423 the useful scope of the proposal, and explain its limitations and why 424 it is not suitable for the general use of SIP on the Internet. 426 The use of the P-Served-User header field extensions is only 427 applicable inside a Trust Domain for served user. Nodes in such a 428 Trust Domain explicitly trust each other to convey the served user, 429 and to be responsible for withholding that information outside of the 430 Trust Domain. The means by which the network determines the served 431 user and the policies that are executed for a specific served user is 432 outside the scope of this document. 434 The served user information lacks an indication of who or what 435 specifically determined the served user, and so it must be assumed 436 that the Trust Domain determined the served user. Therefore, the 437 information is only meaningful when securely received from a node 438 known to be a member of the Trust Domain. 440 Because the served user typically only has validity in one 441 administrative domain it is in general not suitable for inter-domain 442 use or use in the Internet at large. 444 Despite these limitations, there are sufficiently useful specialized 445 deployments that meet the assumptions described above, and can accept 446 the limitations that result, to warrant informational publication of 447 this mechanism. An example deployment would be a closed network like 448 3GPP IMS. 450 9. IANA Considerations 452 This document defines a new SIP header field: P-Served-User. This 453 header field needs to be registered by the IANA in the SIP Parameters 454 registry under the Header Fields subregistry. 456 10. Security Considerations 458 The P-Served-User header field defined in this document is to be used 459 in an environment where elements are trusted and where attackers are 460 not supposed to have access to the protocol messages between those 461 elements. Traffic protection between network elements is sometimes 462 achieved by using IPsec and sometimes by physically protecting the 463 network. In any case, the environment where the P-Served-User header 464 field will be used ensures the integrity and the confidentiality of 465 the contents of this header field. 467 The Spec(T) that defines the Trust Domain for P-Served-User MUST 468 require that member nodes understand the P-Served-User header 469 extension. 471 There is a security risk if a P-Served-User header field is allowed 472 to propagate out of the Trust Domain where it was generated. In that 473 case user-sensitive information would be revealed by such a breach. 474 To prevent such a breach from happening: Proxies MUST NOT insert the 475 header when forwarding requests to a next hop located outside the 476 Trust Domain. When forwarding the request to a node in the Trust 477 Domain, proxies MUST NOT insert the header unless they have 478 sufficient knowledge that the route set includes another proxy in the 479 Trust Domain that understands the header, such as the home proxy. 480 There is no automatic mechanism to learn the support for this 481 specification. Proxies MUST remove the header when forwarding 482 requests to nodes that are not in the Trust Domain or when the proxy 483 does not have knowledge of any other proxy included in the route set 484 that will remove it before it is routed to any node that is not in 485 the Trust Domain. 487 11. Acknowledgments 489 Alf Heidermark, Hubert Przybysz and Erik Rolin for the discussion 490 that led to the solution written down in this document. Spencer 491 Dawkins for performing the expert review. Jon Peterson for 492 performing the AD review. Gonzalo Camarillo, Paul Kyzivat, Nils 493 Haenstroem, Arunachalam Venkatraman, Mikael Forsberg, Miguel Garcia, 494 Jozsef Varga, Keith Drage, Tim Polk and Cullen Jennings for providing 495 improvements. Francis Dupont for performing the general area review. 496 Sandy Murphy for performing the security area review. 498 12. References 499 12.1. Normative References 501 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 502 Levels", BCP 14, RFC 2119, March 1997. 504 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 505 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 506 Session Initiation Protocol", RFC 3261, June 2002. 508 [3] Watson, M., "Short Term Requirements for Network Asserted 509 Identity", RFC 3324, November 2002. 511 [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 512 to the Session Initiation Protocol (SIP) for Asserted Identity 513 within Trusted Networks", RFC 3325, November 2002. 515 [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 516 Rosen, "Change Process for the Session Initiation Protocol 517 (SIP)", BCP 67, RFC 3427, December 2002. 519 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 520 Specifications: ABNF", STD 68, RFC 5234, January 2008. 522 12.2. Informative References 524 [7] Barnes, M., "An Extension to the Session Initiation Protocol 525 (SIP) for Request History Information", RFC 4244, 526 November 2005. 528 [8] 3GPP, "IP Multimedia (IM) session handling; IM call model; 529 Stage 2", 3GPP TS 23.218 V7. 531 [9] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 532 V7. 534 [10] 3GPP, "IMS multimedia telephony communication service and 535 supplementary services; Stage 3", 3GPP TS 24.173 V7. 537 [11] 3GPP, "Internet Protocol (IP) multimedia call control protocol 538 based on Session Initiation Protocol (SIP) and Session 539 Description Protocol (SDP); Stage 3", 3GPP TS 24.229 V7. 541 [12] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 542 Signalling flows and message contents", 3GPP TS 29.228 V7. 544 Appendix A. Why the History-Info header is not suitable to convey the 545 served user information on the ISC interface 547 A.1. Semantics 549 The History-Info as specified in (RFC 4244 [7]) holds a record of 550 Request-URI's that are put on an initial request during its 551 processing in the network and then particularly when the request is 552 retargeted or forwarded. 554 If it would be possible at all to use the History-Info header for the 555 purpose of communicating the served user, then again the same 556 overloading would occur as the one that we are trying to get rid of 557 (Section 4.2). Because in that case we overload the particular 558 History-Info header field's hi-entry with the meaning "historic 559 target identity" and "served user". 561 Another reason that the History-Info header can not solve the 562 requirements as expressed in this draft is that in originating 563 session case scenarios the served user is currently determined from 564 the P-Asserted-Identity as that header field contains the asserted 565 originating user's identity. The History-Info header being a record 566 of Request-URI's can never be a solution for this case. 568 Looking at the call out of the blue scenario (Section 4.4) it is 569 impossible to construct a History-Info header for an INVITE request 570 on behalf of user C appearing to come from user B and targeting user 571 D that would express the served user C without violating the original 572 semantics of the History-Info header according to (RFC 4244 [7]). 574 A.2. Additional Observations 576 The purpose of the History-Info header is a header that has an end to 577 end application. For the purpose of informing an AS on the ISC 578 interface this is overkill. 580 At the moment that the AS receives an initial INVITE over the ISC 581 interface, this INVITE may have passed a vast number of proxies that 582 may either have added history information or not. On top of that, 583 the request may have traversed several AS instances for the same 584 served user. In case several subsequent iFC are active all these AS 585 instances may perform a forwarding. This means that it is not 586 possible to define an algorithm that points out which hi-entry of a 587 History-Info header should represent the served user. In other words 588 a History-Info header field with n entries expresses a branch of 589 depth n. Any or none of these elements could be the served user 590 identity. 592 The History-Info header does not comply with the second requirement 593 as expressed in Section 5, as it does not have a means to express the 594 session case in a natural way. 596 A.3. Conclusion 598 Each of the observations in the previous subsections in isolation is 599 enough to disregard the History-Info header as an information element 600 that is suitable for transporting the served user information over 601 the ISC interface. 603 Note that this does not prohibit the use of the P-Served-User header 604 and the History-Info header in the same request. In fact that will 605 be a quite likely scenario for network based diversion services like 606 for example the Communication Diversion service as specified in (3GPP 607 TS 24.173 [10]). 609 Author's Address 611 Hans Erik van Elburg 612 Ericsson Telecommunicatie B.V. 613 Ericssonstraat 2 614 Rijen 5121 ML 615 The Netherlands 617 Email: HansErik.van.Elburg@ericsson.com 619 Full Copyright Statement 621 Copyright (C) The IETF Trust (2008). 623 This document is subject to the rights, licenses and restrictions 624 contained in BCP 78, and except as set forth therein, the authors 625 retain all their rights. 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 630 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 631 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 632 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Intellectual Property 637 The IETF takes no position regarding the validity or scope of any 638 Intellectual Property Rights or other rights that might be claimed to 639 pertain to the implementation or use of the technology described in 640 this document or the extent to which any license under such rights 641 might or might not be available; nor does it represent that it has 642 made any independent effort to identify any such rights. Information 643 on the procedures with respect to rights in RFC documents can be 644 found in BCP 78 and BCP 79. 646 Copies of IPR disclosures made to the IETF Secretariat and any 647 assurances of licenses to be made available, or the result of an 648 attempt made to obtain a general license or permission for the use of 649 such proprietary rights by implementers or users of this 650 specification can be obtained from the IETF on-line IPR repository at 651 http://www.ietf.org/ipr. 653 The IETF invites any interested party to bring to its attention any 654 copyrights, patents or patent applications, or other proprietary 655 rights that may cover technology that may be required to implement 656 this standard. Please address the information to the IETF at 657 ietf-ipr@ietf.org.