Internet Draft E. Henrikson Document: draft-henrikson-sip-charging-information- Lucent Expires: November 2002 Technologies Category: Informational May 2002 Private SIP Extension for Mobile Charging Information draft-henrikson-sip-charging-information-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes a private extension to SIP in the form of P-Charging-Function-Addresses and P-Charging-Vector headers. The former header is used to pass the addresses of entities that provide a charging function. The latter header is used to pass charging correlation information. The affected UAs and proxies associated with a dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. They also need to pass correlation information so that the records generated and sent to the charging entities may be properly associated for a coordinated billing effort. Table of Contents 1. Background....................................................2 2. Discussion of Mechanism.......................................3 3. Applicability Statement.......................................3 4. Syntax and definition.........................................4 4.1 General......................................................4 Henrikson Expires - November 2002 [Page 1] Private SIP Extension for Mobile Charging Information May 2002 4.2 P-Charging-Function-Addresses................................4 4.3 P-Charging-Vector............................................5 5. Usage.........................................................6 5.1 Procedures at the UA.........................................6 5.2 Procedures at the Proxy......................................6 5.3 Procedures at the Back to Back UA............................7 5.4 Examples of Usage............................................7 6. Security Considerations.......................................8 7. IANA Considerations...........................................8 8. References....................................................8 8.1 Normative References.........................................8 8.2 Informative References.......................................8 9. Author's Addresses............................................9 10. Acknowledgements.............................................9 11. Full Copyright Statement....................................10 1. Background Third Generation Partnership Project (3GPP) has selected SIP [1] as the protocol to establish and tear down multimedia sessions in the IP Multimedia Subsystem (IMS). A description of the IMS can be found in 3GPP TS 23.228 [6] and 3GPP TS 24.229 [7]. 3GPP has defined a distributed architecture that results in multiple network entities becoming involved in providing access and service. Operators need the ability and flexibility to charge for the access and services as they see fit. This requires coordination among the network entities, which includes correlating charging records generated from different entities that are related to the same session. There is a need to inform each network entity involved about common charging functions to receive the generated records. The solution provided by 3GPP is to define two types of charging functions: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for off-line charging and ECF is used for on-line charging. There may be a primary and secondary CCF and ECF, for redundancy purposes. The CCF and ECF addresses may be passed during the establishment of a dialog or standalone transaction. The details are specified in the 3GPP documents, see 3GPP TS 32.200 [5]. Additionally, a charging vector is defined that may be filled in during the establishment of a dialog or standalone transaction. The information inside the charging vector may be filled in by multiple network entities and retrieved by multiple network entities. There are three types of correlation information to be passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI) Henrikson Expires - November 2002 [Page 2] Private SIP Extension for Mobile Charging Information May 2002 and access network charging information. ICID is a globally unique value that may be used to correlate charging records. There may an IOI generated from each side of the dialog to identify the network associated with each side. There is also expected to be access network charging information, which consists of network specific identifiers for the access level (e.g. 3GPP radio access network or IEEE 802.11b). The details of the information for each type of network are not described in this memo. 2. Discussion of Mechanism The provided mechanism uses private headers "P-Charging-Function- Addresses" and "P-Charging-Vector" in either the initial request or subsequent response for a dialog or standalone transaction. Only one instance of each header is allowed in a particular request or response. The mechanisms by which an entity determines which values to populate in the P-Charging-Function-Addresses and P-Charging-Vector headers are specific to the local implementation and outside the scope of this document. 3. Applicability Statement The P-Charging-Function-Addresses and P-Charging-Vector headers are applicable within a single private network where coordination of charging is required. For example, according to the architecture specified in 3GPP TS 32.200 [5]. The P-Charging-Vector header is also applicable between private networks with a trust relationship. The P-Charging-Function-Addresses header is not sent outside of a private network. The P-Charging-Vector header is not sent to another network if there is no trust relationship. Neither header is applicable if the private network does not provide a charging function or manages charging in a way that does not require correlation of records from multiple network entities. The P-Charging-Function-Addresses header is applicable whenever the following circumstances are met: 1. A UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone transaction request to a proxy in a private network. 2. A registrar, proxy or B2BUA that is located in the private network wants to generate charging records. 3. A registrar, proxy or B2BUA that is located in the private network has access to the addresses of the charging function entities for that network. Henrikson Expires - November 2002 [Page 3] Private SIP Extension for Mobile Charging Information May 2002 The P-Charging-Vector header is applicable whenever the following circumstances are met: 1. A UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone transaction request to a proxy in a private network. 2. A registrar, proxy or B2BUA that is located in the private network wants to generate charging records. 3. A proxy or B2BUA that is located in the private network has access to the charging correlation information for that network. 4. Optionally, a registrar, proxy or B2BUA that is part of the dialog or standalone transaction and is located in another private network wants to generate charging records and correlate the records with the other private network. 4. Syntax and definition 4.1 General All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are inherited for the P-Charging-Function-Addresses and P-Charging- Vector headers and are not repeated here. Implementers need to be familiar with the notation and content of RFC 3261 [2] and RFC 2234 [2] to understand this document. 4.2 P-Charging-Function-Addresses The syntax for the P-Charging-Function-Addresses header is: p-charging-addr = "P-Charging-Function-Addresses" HCOLON charg-addr-params *(SEMI charge-addr-params) charge-addr-params = ccf1 / ccf2 / ecf1 / ecf2 / generic-param ccf1 = "ccf1" EQUAL gen-value ccf2 = "ccf2" EQUAL gen-value ecf1 = "ecf1" EQUAL gen-value ecf2 = "ecf2" EQUAL gen-value Example: P-Charging-Function-Addresses: ccf1=135.18.232.565; ccf2=135.18.232.766 A P-Charging-Function-Addresses header may be inserted into a request or response by any SIP node traversed by that message. However, there may only be one instance of a P-Charging-Function- Henrikson Expires - November 2002 [Page 4] Private SIP Extension for Mobile Charging Information May 2002 Addresses in a SIP message. Further, a particular instance of P- Charging-Function-Addresses shall always contain the ccf1 parameter and may contain one instance of each of the other parameters: ccf2, ecf1 and ecf2. The allowable usage of headers is described in Table 2 of SIP [1]. Addition of P-Charging-Function-Addresses to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [8], tables 1 and 2 in the SIP INFO method [9], tables 1 and 2 in Reliability of provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE method [11], tables 1 and 2 in the SIP extension for Instant Messaging [12] and table 1 in the SIP REFER method [13]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Charging-Function-Addresses ard - o - o o o Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Charging-Function-Addresses o o o o o o o 4.3 P-Charging-Vector The syntax for the P-Charging-Vector header is: p-charging-vector = "P-Charging-Vector" HCOLON charge-params *(SEMI charge-params) charge-params = icid / orig-ioi / term-ioi / generic-param icid = "icid" EQUAL gen-value orig-ioi = "orig-ioi" EQUAL gen-value term-ioi = "term-ioi" EQUAL gen-value Example: P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN A P-Charging-Vector header may be inserted into a request or response by any SIP node traversed by that message. However, there may only be one instance of a P-Charging-Vector in a SIP message. Further, a particular instance of P-Charging-Vector shall always contain the icid parameter and may contain one instance of each of the other parameters: orig-ioi and term-ioi. Lastly, it is expected that there will be network specific information included in the extension parameter generic-param. The allowable usage of headers is described in Table 2 of SIP [1]. Addition of P-Charging-Vector to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [8], tables 1 and 2 in Henrikson Expires - November 2002 [Page 5] Private SIP Extension for Mobile Charging Information May 2002 the SIP INFO method [9], tables 1 and 2 in Reliability of provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE method [11], tables 1 and 2 in the SIP extension for Instant Messaging [12] and table 1 in the SIP REFER method [13]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Charging-Vector ard - o - o o o Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Charging-Vector o o o o o o o 5. Usage 5.1 Procedures at the UA The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Function- Addresses header, but may retrieve the information if received. The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Charging-Vector header, but may retrieve the information if received. 5.2 Procedures at the Proxy The P-Charging-Function-Addresses and P-Charging-Vector headers are treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination. If a proxy that supports this extension receives a request or response without the P-Charging-Function-Addresses or P-Charging- Vector header, it MAY insert a P-Charging-Function-Addresses or P- Charging-Vector header prior to forwarding the message. If a proxy that supports this extension receives a request or response with the P-Charging-Function-Addresses or P-Charging- Vector header, it may retrieve the information from the header to use with application specific logic, i.e. charging. The proxy SHOULD retain the P-Charging-Function-Addresses and P-Charging- Vector header in the outbound message. If the next hop for the message is outside the closed network of the proxy, then the proxy MUST remove the P-Charging-Function-Addresses header and MAY remove the P-Charging-Vector header from the message. Henrikson Expires - November 2002 [Page 6] Private SIP Extension for Mobile Charging Information May 2002 5.3 Procedures at the Back to Back UA If a B2BUA that understands the P-Charging-Function-Addresses header or P-Charging-Vector header receives a request/response with the P-Charging-Function-Addresses or P-Charging-Vector header, the B2BUA SHOULD copy them from the receiving side UA to the sending side UA. 5.4 Examples of Usage We present example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below: Scenario UA1----P1-----P2-----UA2 This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P1 is an outbound proxy for UA1. In this case P1 also inserts charging information. P1 then routes the call via P2 to UA2. Message sequence for INVITE using P-Charging-Function-Addresses and P-Charging-Vector: F1 INVITE UA1 -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: . . . F2 INVITE P1 -> P2 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Henrikson Expires - November 2002 [Page 7] Private SIP Extension for Mobile Charging Information May 2002 Contact: P-Charging-Function-Addresses: ccf1=135.18.232.565; ccf2=135.18.232.766 P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN . . . 6. Security Considerations It is expected as normal behavior that proxies and B2BUAs within a closed network will modify the values of P-Charging-Function- Addresses and P-Charging-Vector and to insert these headers into a request for a dialog, e.g. INVITE request (or other request or response). However, these proxies and B2BUAs that share this information SHOULD have a trust relationship. If an untrusted entity got inserted between trusted entities, it could potentially interfere with the charging correlation mechanism or substitute a different charging function address. Therefore, an integrity protection mechanism such as IPsec or other available mechanisms SHOULD be applied in order to prevent such attacks. Since each trusted proxy or B2BUA may need to view or modify the values in the P-Charging-Function-Addresses and P-Charging-Vector headers, the protection should be applied on a hop-by-hop basis. 7. IANA Considerations This document defines the SIP extension headers "P-Charging- Function-Addresses" and "P-Charging-Vector" which should be included in the registry of SIP headers defined in SIP [1]. As required by the SIP change process draft-tsvarea-sipchange [4] the SIP extension header name "Charging-Function-Addresses" and "Charging-Vector" should also be registered in association with this extension. 8. References 8.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol, RFC 3261", March 2002. [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," RFC 2234, Internet Engineering Task Force, November 1997. 8.2 Informative References Henrikson Expires - November 2002 [Page 8] Private SIP Extension for Mobile Charging Information May 2002 [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- sipping-3gpp-reqs-03.txt", March 2002. [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March 2002. [5] 3GPP TS 32.200, Version 5, "Telecommunication Management; Charging management; Charging principles". [6] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release 5". [7] 3GPP TS 24.229 "IP Multimedia Subsystem (IMS) (Stage 3) - Release 5". [8] A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. [9] S. Donovan, The SIP INFO method, RFC 2976, October 2000. [10] J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, RFC 3262, March 2002. [11] J. Rosenberg, The Session Initiation Protocol UPDATE Method, draft-ietf-sip-update-02.txt, April 2002, work in progress. [12] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session Initiation Protocol Extension for Instant Messaging, draft-ietf-sip-message-04, May 2002, work in progress. [13] R. Sparks, The REFER method, draft-sparks-sip-refer-split- 00.txt, April 2002, work in progress. 9. Author's Addresses Eric Henrikson Lucent Technologies 11601 Willows Rd Suite 100 Redmond, WA 98052 US Phone: +1 425 497 2442 EMail: ehenrikson@lucent.com URI: http://www.lucent.com/ 10. Acknowledgements Henrikson Expires - November 2002 [Page 9] Private SIP Extension for Mobile Charging Information May 2002 The author would like to thank Keith Drage, Miguel Garcia, Dean Willis, Rohan Mahy and the 3GPP CN1 Working Group members for their valuable comments on this document. 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Henrikson Expires - November 2002 [Page 10]