diff options
Diffstat (limited to 'doc/rfc/rfc5502.txt')
| -rw-r--r-- | doc/rfc/rfc5502.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5502.txt b/doc/rfc/rfc5502.txt new file mode 100644 index 0000000..0075a5c --- /dev/null +++ b/doc/rfc/rfc5502.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group J. van Elburg +Request for Comments: 5502 Ericsson Telecommunicatie B.V. +Category: Informational April 2009 + + + The SIP P-Served-User Private-Header (P-Header) + for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Abstract + + This document specifies the SIP P-Served-User P-header. This header + field addresses an issue that was found in the 3rd Generation + Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an + S-CSCF (Serving Call Session Control Function) and an AS (Application + Server) on the ISC (IMS Service Control) interface. This header + field conveys the identity of the served user and the session case + that applies to this particular communication session and application + invocation. + + + + +van Elburg Informational [Page 1] + +RFC 5502 The P-Served-User P-Header April 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions .....................................................3 + 3. Definitions .....................................................3 + 3.1. Identity, Network Asserted Identity, Trust Domain, + and Spec(T) ................................................3 + 3.2. Served User ................................................3 + 4. Scenarios .......................................................4 + 4.1. General ....................................................4 + 4.2. Diversion: Continue on Terminating Leg, but Finish + Subsequent Terminating iFC First ...........................5 + 4.3. Diversion: Create New Originating Leg and Provide + Originating iFC Processing .................................6 + 4.4. Call Out of the Blue: on Behalf of User B, but + Service Profile of Service Identity C.......................8 + 5. Requirements ....................................................8 + 6. P-Served-User Header Field Definition ...........................9 + 7. Proxy Behavior ..................................................9 + 7.1. Generating the P-Served-User Header ........................9 + 7.2. Consuming the P-Served-User Header ........................10 + 8. Applicability ..................................................10 + 9. IANA Considerations ............................................11 + 10. Security Considerations .......................................11 + 11. Acknowledgments ...............................................11 + 12. References ....................................................12 + 12.1. Normative References .....................................12 + 12.2. Informative References ...................................12 + Appendix A. Why the History-Info Header Is Not Suitable to + Convey the Served User Information on the ISC + Interface ............................................13 + A.1. Semantics ................................................13 + A.2. Additional Observations ..................................13 + A.3. Conclusion ................................................14 + + + + + + + + + + + + + + + + + +van Elburg Informational [Page 2] + +RFC 5502 The P-Served-User P-Header April 2009 + + +1. Introduction + + The 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia + Subsystem) uses SIP (RFC 3261 [2]) as its main signaling protocol. + (For more information on the IMS, a detailed description can be found + in 3GPP TS 23.228 [9] and 3GPP TS 24.229 [11].) 3GPP has identified + issues with the linking in of a SIP application server that are most + appropriately resolved by defining a new SIP P-header, according to + the procedures in RFC 3427 [5]. + + The remainder of this document is organized as follows. Section 4 + outlines the problem by using particular service scenarios, and + Section 5 discusses the requirements derived from these scenarios. + Section 6 defines the P-Served-User header field, which meets those + requirements, Section 7 specifies the proxy behavior for the new + header field, and Section 8 discusses the applicability and scope of + this new header field. Section 9 registers the P-Served-User header + field with the IANA, and Section 10 discusses the security properties + of the environment where this header field is intended to be used. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [1]. + +3. Definitions + +3.1. Identity, Network Asserted Identity, Trust Domain, and Spec(T) + + The terms Identity, Network Asserted Identity, Trust Domain, and + Spec(T) in this document are specified in RFC 3324 [3]. + +3.2. Served User + + The served user to a proxy or AS (Application Server) is the user + whose service profile is accessed by that proxy or AS when an initial + request is received that is originated by, originated on behalf of, + or terminated to that user. This profile in turn provides some + useful information (preferences or permissions) for processing at a + proxy and, potentially, at an AS. + + + + + + + + + + +van Elburg Informational [Page 3] + +RFC 5502 The P-Served-User P-Header April 2009 + + +4. Scenarios + +4.1. General + + In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) + is a SIP proxy that serves as a registrar and handles originating and + terminating session states for users allocated to it. This means + that any call that is originated by a specific user or any call that + is terminated to that specific user will pass through the S-CSCF that + is allocated to that user. + + At the moment that an S-CSCF is allocated for a specific user, a user + profile is downloaded to the S-CSCF from the HSS (Home Subscriber + Server) over the Cx interface, see 3GPP TS 29.228 [12]. This user + profile tells the S-CSCF whether the user is allowed to originate or + terminate calls or whether an AS needs to be linked in over the ISC + interface. The user profile information that determines whether a + particular initial request needs to be sent to a particular AS is + called the initial Filter Criteria (iFC), see for example 3GPP TS + 23.218 [8]. + + For an S-CSCF to be able to meet its responsibilities, it needs to + determine on which user's behalf it is performing its tasks and which + session case is applicable for the particular request. (For a + definition of session case, see 3GPP TS 29.228 [12]). The session + case distinguishes the originating and terminating call cases and + determines whether or not the particular user is registered. + + When the S-CSCF determines that for an incoming initial request the + originating call case applies, it determines the served user by + looking at the P-Asserted-Identity header field (RFC 3325 [4]), which + carries the network asserted identity of the originating user. When, + after processing the iFC for this initial request, the S-CSCF decides + to forward the request to an AS, the AS has to go through a similar + process of determining the session case and the served user. Since + it should come to the same conclusion that this is an originating + session case, it also has to look at the P-Asserted-Identity header + field to determine the served user. + + When the S-CSCF determines that for an incoming initial request the + terminating call case applies, it determines the served user by + looking at the Request-URI (RFC 3261 [2]), which carries the identity + of the intended terminating user. When, after processing the iFC for + this initial request, the S-CSCF decides to forward the request to an + AS, the AS has to go through a similar process of determining the + session case and the served user. Since it should come to the same + conclusion that this is a terminating session case, it also has to + look at the Request-URI to determine the served user. + + + +van Elburg Informational [Page 4] + +RFC 5502 The P-Served-User P-Header April 2009 + + + In the originating case, it can be observed that while the + P-Asserted-Identity header field just represents the originating user + when it enters the S-CSCF, it is overloaded with another meaning when + it is sent to an AS over the ISC interface. This other meaning is + that it serves as a representation of the served user. + + In the terminating case, a similar overloading happens to the + Request-URI; while it first only represented the identity of the + intended terminating user, it is overloaded with another meaning when + it is sent to an AS over the ISC interface. This other meaning is + that it serves as a representation of the served user. + + In basic call scenarios, this does not show up as a problem, but once + more complicated service scenarios (notably forwarding services) need + to be realized, it poses severe limitations. Such scenarios are + brought forward in the following subsections. + +4.2. Diversion: Continue on Terminating Leg, but Finish Subsequent + Terminating iFC First + + Imagine a service scenario where a user B has a terminating service + that diverts the call to a different destination but is required to + still execute subsequent terminating services for the same user. + This means that this particular user has multiple iFC configured that + are applicable for an incoming initial request. When the S-CSCF + receives an initial INVITE request, it analyzes the request and + determines that the session case is for a terminating registered + user, then it determines the served user to be user B by looking at + the Request-URI. + + Now the S-CSCF starts the iFC processing. The first iFC that matches + the INVITE request causes the INVITE to be forwarded over the ISC + interface to an AS that hosts user B's diversion service by adding + the AS and S-CSCF's own hostnames to the Route header. The S-CSCF + adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname + on the Route header. This allows the S-CSCF to correlate an INVITE + coming from an AS over the ISC interface to the existing session that + forwarded the INVITE to the AS in the first place. + + When the AS receives the initial INVITE request, it analyzes the + request and determines that the session case is for a terminating + registered user, then it determines the served user to be user B by + looking at the Request-URI. Based on some criteria, the diversion + service concludes that the request needs to be diverted to another + user or application C. It does this by changing the Request-URI to + C. Optionally, it records the Request-URI history by using the + History- Info header field (RFC 4244 [7]). Then the AS removes + + + + +van Elburg Informational [Page 5] + +RFC 5502 The P-Served-User P-Header April 2009 + + + itself from the Route header and routes the INVITE request back to + the S-CSCF by using the topmost Route header field. + + When the S-CSCF receives the INVITE over the ISC interface, it can + see that the Route header contains its own hostname and an ODI that + correlates to an existing terminating session for user B. This can + be used by the S-CSCF to analyze whether there are still unexecuted + iFC. (Note that the current behavior of the S-CSCF on receiving an + INVITE with a changed Request-URI is to terminate the iFC processing + and to route the request based on the new Request-URI value.) + + The process repeats itself. The INVITE is forwarded to the AS that + is associated with this particular iFC. When the AS receives the + initial INVITE request, it analyzes the request and determines that + the session case is for a terminating registered user, then it + determines the served user to be user C by looking at the Request- + URI. This is clearly wrong, as the user being served is still user + B. + + This scenario clearly shows the problem that occurs when the Request- + URI is overloaded with the meanings "intended target identity" and + "served user" with the operation as described in Section 4.1. And it + shows that this use case can not be realized without introducing a + mechanism that conveys information about the served user from the + S-CSCF to the AS. Use of the History-Info element does not solve + this problem as it does not tell the AS which user is being served; + it just presents a history of diversions that might not be even + caused by the systems serving this particular user. A more detailed + analysis on why the History-Info header field can't be used is + provided in Appendix A. + +4.3. Diversion: Create New Originating Leg and Provide Originating iFC + Processing + + Imagine a service scenario where a user B has a terminating service + that diverts the call to a different destination. It is required + that a forwarded call leg is handled as an originating call leg and + that originating services for user B are executed. This means that + this particular user has one or more iFC configured that are + applicable for an outgoing initial request. + + When the S-CSCF receives an initial INVITE request, it analyzes the + request and determines that the session case is for a terminating + registered user, then it determines the served user to be user B by + looking at the Request-URI. + + + + + + +van Elburg Informational [Page 6] + +RFC 5502 The P-Served-User P-Header April 2009 + + + Now the S-CSCF starts the iFC processing. The first iFC that matches + the INVITE request causes the INVITE to be forwarded over the ISC + interface to an AS that hosts user B's diversion service by adding + the AS and S-CSCF's own hostnames to the Route header. The S-CSCF + adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname + on the Route header. This allows the S-CSCF to correlate an INVITE + coming from an AS over the ISC interface to the existing session that + forwarded the INVITE to the AS in the first place. + + When the AS receives the initial INVITE request, it analyzes the + request and determines that the session case is for a terminating + registered user, then it determines the served user to be user B by + looking at the Request-URI. Based on some criteria, the diversion + service concludes that the request needs to be diverted to another + user or application C. It does this by changing the Request-URI to + C. Optionally, it records the Request-URI history by using the + History-Info header field (RFC 4244 [7]). Then the AS removes itself + from the Route header. To make sure that the request is handled as a + new originating call on behalf of user B, the AS adds the "orig" + parameter to the topmost route header. Then it routes the INVITE + request back to the S-CSCF by using this topmost Route header field. + + When the S-CSCF receives the INVITE over the ISC interface, it can + see that the topmost Route header contains its own hostname and an + "orig" parameter. Because the topmost Route header contains the + "orig" parameter, the S-CSCF concludes that the INVITE should be + handled as if a call is originated by the served user. The served + user is determined from the P-Asserted-Identity header to be user A. + This is clearly wrong, as the user being served is and should be + user B. + + For the sake of discussion, let's assume that the S-CSCF can + determine that the served user is user B. Then the procedure would + continue as follows: The S-CSCF starts the originating iFC + processing, the first iFC that matches the INVITE request causes the + INVITE to be forwarded over the ISC interface to an AS that hosts an + originating service of user B by adding the AS and S-CSCF's own + hostnames to the Route header. The S-CSCF adds an Original Dialog + Identifier (ODI) to the S-CSCF's own hostname on the Route header. + + The INVITE is forwarded to the AS that is associated with this + particular iFC. When the AS receives the initial INVITE request, it + analyzes the request and determines that the session case is for an + originating registered user, then it determines the served user to be + user A by looking at the P-Asserted-Identity. This is clearly wrong, + as the user being served is and should be user B. + + + + + +van Elburg Informational [Page 7] + +RFC 5502 The P-Served-User P-Header April 2009 + + + This scenario clearly shows the problem that occurs when the + P-Asserted-Identity is overloaded with the meanings "call originator" + and "served user" with the operation as described in Section 4.1. + And it shows that this use case can not be realized without + introducing a mechanism that conveys information about the served + user from the S-CSCF to the AS and from the AS to the S-CSCF. Use of + the History-Info element does not solve this problem as it does not + tell the AS which user is being served, but just presents a history + of diversions that might not be even caused by the systems serving + this particular user. A more detailed analysis on why the History- + Info header field can't be used is provided in Appendix A. + +4.4. Call Out of the Blue: on Behalf of User B, but Service Profile of + Service Identity C + + There are services that need to be able to initiate a call, whereby + the call appears to be coming from a user B but the service profile + on behalf of service identity C needs to be executed in the S-CSCF. + + When a call needs to appear as coming from user B, that means that + the P-Asserted-Identity needs to contain B's identity. This is + because the Originating Identity Presentation (OIP) service as + defined in 3GPP TS 24.173 [10] uses the P-Asserted-Identity to + present the call originator. This makes sense because that is the + main meaning expressed by the P-Asserted-Identity header field. + + It is clear that no INVITE request can be constructed currently that + would achieve both requirements expressed in the first paragraph, + because the P-Asserted-Identity is overloaded with two meanings on + the ISC interface. When the S-CSCF will receive this request, it + will determine that the served user is user B, which is not what we + want to achieve. + +5. Requirements + + This section lists the requirements derived from the previous + scenarios: + + 1. To be able to offer real-world application services, it is + required that the identity of the served user can be conveyed on + the ISC interface (see 3GPP TS 23.218 [8]). + + 2. To be able to offer appropriate services to the served user, it + is required that in addition to the served user identity the + session case is conveyed. + + + + + + +van Elburg Informational [Page 8] + +RFC 5502 The P-Served-User P-Header April 2009 + + +6. P-Served-User Header Field Definition + + This document defines the SIP P-Served-User P-header. This header + field can be added to initial requests for a dialog or standalone + requests, which are routed between nodes in a Trust Domain for + P-Served-User. The P-Served-User P-header contains an identity of + the user that represents the served user. The "sescase" parameter + may be used to convey whether the initial request is originated by or + destined for the served user. The "regstate" parameter may be used + to indicate whether the initial request is for a registered or + unregistered user. + + The augmented Backus-Naur Form (BNF) (RFC 5234 [6]) syntax of the + P-Served-User header field is as follows: + + P-Served-User = "P-Served-User" HCOLON PServedUser-value + *(SEMI served-user-param) + served-user-param = sessioncase-param + / registration-state-param + / generic-param + PServedUser-value = name-addr / addr-spec + sessioncase-param = "sescase" EQUAL "orig" / "term" + registration-state-param = "regstate" EQUAL "unreg" / "reg" + + EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are + defined in RFC 3261 [2]. + + The following is an example of a P-Served-User header field: + + P-Served-User: <sip:user@example.com>; sescase=orig; regstate=reg + +7. Proxy Behavior + +7.1. Generating the P-Served-User Header + + Proxies that support the header MUST only insert the header in + initial requests for a dialog or in standalone requests when the + following conditions hold: + + o The proxy has the capability to determine the served user for the + current request. + + o The next hop is part of the same Trust Domain for P-Served-User. + + When the above conditions do not hold, the proxy MUST NOT insert the + header. + + + + + +van Elburg Informational [Page 9] + +RFC 5502 The P-Served-User P-Header April 2009 + + +7.2. Consuming the P-Served-User Header + + A proxy that supports the header MUST, upon receiving from a trusted + node the P-Served-User header in initial requests for a dialog or in + standalone requests, take the value of the P-Served-User header to + represent the served user in operations that require such + information. + + A proxy that supports the header MUST remove the header from requests + or responses when the header was received from a node outside the + Trust Domain for P-Served-User before further forwarding the message. + + A proxy that supports the header MUST remove the header from requests + or responses when the next hop is a node outside the Trust Domain for + P-Served-User before further forwarding the message. + +8. Applicability + + According to RFC 3427 [5], P-headers have a limited applicability. + Specifications of P-headers, such as this RFC, need to clearly + document the useful scope of the proposal and explain its limitations + and why it is not suitable for the general use of SIP on the + Internet. + + The use of the P-Served-User header field extensions is only + applicable inside a Trust Domain for served user. Nodes in such a + Trust Domain explicitly trust each other to convey the served user + and to be responsible for withholding that information outside of the + Trust Domain. The means by which the network determines the served + user and the policies that are executed for a specific served user is + outside the scope of this document. + + The served user information lacks an indication of who or what + specifically determined the served user, and so it must be assumed + that the Trust Domain determined the served user. Therefore, the + information is only meaningful when securely received from a node + known to be a member of the Trust Domain. + + Because the served user typically only has validity in one + administrative domain, it is in general not suitable for inter-domain + use or use in the Internet at large. + + Despite these limitations, there are sufficiently useful specialized + deployments that meet the assumptions described above, and that can + accept the limitations that result, to warrant informational + publication of this mechanism. An example deployment would be a + closed network like 3GPP IMS. + + + + +van Elburg Informational [Page 10] + +RFC 5502 The P-Served-User P-Header April 2009 + + +9. IANA Considerations + + This document defines a new SIP header field: P-Served-User. This + header field has been registered by the IANA in the SIP Parameters + registry under the Header Fields subregistry. + +10. Security Considerations + + The P-Served-User header field defined in this document is to be used + in an environment where elements are trusted and where attackers are + not supposed to have access to the protocol messages between those + elements. Traffic protection between network elements is sometimes + achieved by using IPsec and sometimes by physically protecting the + network. In any case, the environment where the P-Served-User header + field will be used ensures the integrity and the confidentiality of + the contents of this header field. + + The Spec(T) that defines the Trust Domain for P-Served-User MUST + require that member nodes understand the P-Served-User header + extension. + + There is a security risk if a P-Served-User header field is allowed + to propagate out of the Trust Domain where it was generated. In that + case, user-sensitive information would be revealed. To prevent such + a breach from happening, proxies MUST NOT insert the header when + forwarding requests to a hop that is located outside the Trust + Domain. When forwarding the request to a node in the Trust Domain, + proxies MUST NOT insert the header unless they have sufficient + knowledge that the route set includes another proxy in the Trust + Domain that understands the header, such as the home proxy. There is + no automatic mechanism to learn the support for this specification. + Proxies MUST remove the header when forwarding requests to nodes that + are not in the Trust Domain or when the proxy does not have knowledge + of any other proxy included in the route set that will remove it + before it is routed to any node that is not in the Trust Domain. + +11. Acknowledgments + + Alf Heidermark, Hubert Przybysz, and Erik Rolin for the discussion + that led to the solution written down in this document. Spencer + Dawkins for performing the expert review. Jon Peterson for + performing the AD review. Gonzalo Camarillo, Paul Kyzivat, Nils + Haenstroem, Arunachalam Venkatraman, Mikael Forsberg, Miguel Garcia, + Jozsef Varga, Keith Drage, Tim Polk, and Cullen Jennings for + providing improvements. Francis Dupont for performing the general + area review. Sandy Murphy for performing the security area review. + + + + + +van Elburg Informational [Page 11] + +RFC 5502 The P-Served-User P-Header April 2009 + + +12. References + +12.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [3] Watson, M., "Short Term Requirements for Network Asserted + Identity", RFC 3324, November 2002. + + [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions + to the Session Initiation Protocol (SIP) for Asserted Identity + within Trusted Networks", RFC 3325, November 2002. + + [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. + Rosen, "Change Process for the Session Initiation Protocol + (SIP)", BCP 67, RFC 3427, December 2002. + + [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +12.2. Informative References + + [7] Barnes, M., "An Extension to the Session Initiation Protocol + (SIP) for Request History Information", RFC 4244, + November 2005. + + [8] 3GPP, "IP Multimedia (IM) session handling; IM call model; + Stage 2", 3GPP TS 23.218 V7. + + [9] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 + V7. + + [10] 3GPP, "IMS multimedia telephony communication service and + supplementary services; Stage 3", 3GPP TS 24.173 V7. + + [11] 3GPP, "Internet Protocol (IP) multimedia call control protocol + based on Session Initiation Protocol (SIP) and Session + Description Protocol (SDP); Stage 3", 3GPP TS 24.229 V7. + + [12] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; + Signalling flows and message contents", 3GPP TS 29.228 V7. + + + + + +van Elburg Informational [Page 12] + +RFC 5502 The P-Served-User P-Header April 2009 + + +Appendix A. Why the History-Info Header Is Not Suitable to Convey the + Served User Information on the ISC Interface + +A.1. Semantics + + The History-Info (as specified in RFC 4244 [7]) holds a record of + subsequent Request-URI values that are put on an initial request + during its processing in the network. + + If it would be possible at all to use the History-Info header for the + purpose of communicating the served user, then again the same + overloading would occur as the one that we are trying to get rid of + (Section 4.2). In this case, we overload the particular History-Info + header field's hi-entry with the meaning "historic target identity" + and "served user". + + Another reason that the History-Info header can not solve the + requirements as expressed in this document is that, in originating + session case scenarios, the served user is currently determined from + the P-Asserted-Identity, as that header field contains the asserted + originating user's identity. The History-Info header, being a record + of Request-URIs, can never be a solution for this case. + + Looking at the call-out-of-the-blue scenario (Section 4.4), it is + impossible to construct a History-Info header for an INVITE request + on behalf of user C that appears to come from user B and targets user + D that would express the served user C without violating the original + semantics of the History-Info header according to (RFC 4244 [7]). + +A.2. Additional Observations + + The purpose of the History-Info header is a header that has an end- + to-end application. For the purpose of informing an AS on the ISC + interface, this is overkill. + + At the moment that the AS receives an initial INVITE over the ISC + interface, this INVITE may have passed a vast number of proxies that + may or may not have added history information. On top of that, the + request may have traversed several AS instances for the same served + user. In case several subsequent iFC are active, all these AS + instances may perform a forwarding. This means that it is not + possible to define an algorithm that points out which hi-entry of a + History-Info header should represent the served user. In other + words, a History-Info header field with n entries expresses a branch + of depth n. Any or none of these elements could be the served user + identity. + + + + + +van Elburg Informational [Page 13] + +RFC 5502 The P-Served-User P-Header April 2009 + + + The History-Info header does not comply with the second requirement + as expressed in Section 5, as it does not have a means to express the + session case in a natural way. + +A.3. Conclusion + + Each observation in the previous subsections, alone, is enough to + disregard the History-Info header as an information element that is + suitable for transporting the served user information over the ISC + interface. + + Note that this does not prohibit the use of the P-Served-User header + and the History-Info header in the same request. In fact that will + be a quite likely scenario for network-based diversion services like, + for example, the Communication Diversion service as specified in + (3GPP TS 24.173 [10]). + +Author's Address + + Hans Erik van Elburg + Ericsson Telecommunicatie B.V. + Ericssonstraat 2 + Rijen 5121 ML + Netherlands + + EMail: HansErik.van.Elburg@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + +van Elburg Informational [Page 14] + |