Internet Draft Document: draft-prasanna-bip-00.txt Huawei Technologies Expires: May 2003 December 2002 BIP: Billing Information Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [6]. 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. This internet draft will expire on Jun, 2003. Abstract Billing information protocol is a simple protocol that can be used by servers to indicate the charging information incurred due to a specific operation with a client. In many situations a client, like a SIP user agent may need to know the charging information about a specific interaction with the server. This document defines the BIP (Billing Information Protocol) that can be used as a standard way to share this charging information. BIP supports simple indication of charging information. The protocol defines a generic representation on the number of units charged, the charge incurred per unit etc. This will be useful for implementing services like advice of charge. The protocol is targeted for VoIP usages, however any generic client-server interaction can use this protocol. Conventions used in this document Prasanna Expires - May 2003 [Page 1] BIP: Billing information Protocol Dec 2002 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 RFC-2119 [7]. Prasanna Expires - May 2003 [Page 2] BIP: Billing information Protocol Dec 2002 Table of Contents 1. Introduction..................................................3 2. Definitions...................................................4 3. Protocol Operation............................................4 3.1. Charging Background......................................5 3.2. Charge Data..............................................5 3.3. Additional Charge Information............................5 3.4. Security.................................................6 4. Billing Information Protocol Syntax...........................6 5. Header Fields.................................................7 5.1. Advice-State.............................................7 5.2. Charge-Type..............................................8 5.3. Charge-Units.............................................8 5.4. Currency-Units...........................................8 5.5. Currency-ID..............................................9 5.6. Duration.................................................9 5.7. Bill-ID..................................................9 5.8. Service-Type.............................................9 5.9. Hash....................................................10 6. Illustrative Examples........................................10 7. IANA considerations..........................................11 7.1. The "application/bip" mime type.........................11 8. Formal Syntax................................................11 9. Security Considerations......................................12 10. References..................................................13 Acknowledgments.................................................14 Author's Addresses..............................................14 1.Introduction It is a standard requirement, in the deployment of commercial client-server applications, that the server can indicate charging information to the client in some format and method. With VoIP applications gaining a lot of popularity this requirement becomes very critical. For example in the case of SIP[1], the user agents may require to be provided with charging information about the call they have placed. This may be as a supplementary service like "Advice of Charge" or used for pre-paid card services. There has to be a standard way by which this information is transferred in the network and interpreted by the client. This document proposes a protocol, the "billing information protocol (BIP)" that can be used to share this information. The motivation for this protocol is the requirement for the "advice of charge" service for SIP[1]. However, this protocol is no way constrained to be used only with SIP [1] or to be only used with Prasanna Expires - May 2003 [Page 3] BIP: Billing information Protocol Dec 2002 VoIP applications. It can be used for data applications with little or no modification and can be carried payload by any suitable protocol. This document however does not enumerate all the applications of this protocol, which can be identified in various other drafts for this media type. This document does not define any accounting procedure by which this data is collected and is only meant to carry charging information between entities. It also does not describe the units of charging. There has to be a prior understanding on this between the billing entity and the billed entity. The billing information may in most of the conditions be rendered, but other handling may be defined suitably by the applications. This protocol information is required to be carried in signalling protocols like SIP or HTTP. This document identifies SIP [1] as a suitable carrier for this protocol. Other suitable carriers may also be defined by other documents. 2.Definitions The following generic definitions are relevant to this document Charging information: the data carried by the protocol Information header: Header containing some charging element and its value Billing entity: The server or entity that generates the billing information Billed entity: The client or entity to which the billing information is sent The following telephony related definitions are relevant to this document Advice Of Charge: The advice of charge allows the served user to be informed of usage-based charging information. This is the typical application that is the motivation for this protocol. Reverse Charging: Where a called user is charged rather than the calling user 3.Protocol Operation Prasanna Expires - May 2003 [Page 4] BIP: Billing information Protocol Dec 2002 The protocolÆs singular purpose is to carry charging related data from the billing entity to the billed entity. The way the data is created or computed is beyond the scope of the protocol. Though it is expected that the charging information carried is accurate at that point of time, the validity of the charging information is an agreement between the billing entity and the billed entity. The information contains a series of information lines. Each line contains some part of the charging information. While the most common handling of the charging information by the billed entity may be displaying it to the user, other operations like terminating a call based on the billing data or request of additional currency from the user in the case of a public phone may be performed. This protocol just defines how the data is to be carried, various usages of this protocol has to be enumerated in other documents. The protocol uses text based encoding and not binary encodings like CDR, as the common application of this protocol shall be to display the charging information to the user. The pieces of information to be carried are grouped into four components. 3.1.Charging Background The charging information has to mention the kind of charging done and the kind of information carried by this data. The charging information generated may be intermediate or final. Intermediate information is generated where the billed entity is required to be fed with the charge information incrementally or periodically. The charging information can be final, in which case there shall be no update to the charging information. The kind of charging done can be classified as free or normal or reverse. This mentions why the billed entity is getting this information. 3.2.Charge Data This forms the key component of the information. The actual charge information is conveyed either as units charged or currency charged. The units are pre-negotiated between the billing entity and the billed entity. If the currency units are mentioned, then the currency can be qualified. 3.3.Additional Charge Information Prasanna Expires - May 2003 [Page 5] BIP: Billing information Protocol Dec 2002 To qualify the charging information in a better way some additional information can be provided by the billing entity. This may be additional services for which the billing entity is charging the billed entity or some indication of the duration for which the billed entity is charged. 3.4.Security It is highly desirable that the carrier protocol provides the security for the billing information payload. However to cater to carriers which do not provide any basic security the protocol has provisions for some basic security. Since data tampering is the most likely security threat, optionally a cryptographic hash of the information can be carried by the protocol. The cryptographic hash can be a MD5 (RFC 1321 [14]) of the complete charging information and a secret key shared by the billing entity and the billed entity. 4.Billing Information Protocol Syntax The media type follows the conventions of the SIP (RFC 3261 [1]) for information header formatting. The billing information contains a series of information headers with each of the information header lines terminated by a CRLF. billing-information = *info-header info-header = "header-name" HCOLON header-value *(COMMA header-value) CRLF The basic set of information header fields are defined in this document. However the information elements can be extended adhering to the generic framework of header format defined above. The header field formats strictly adhere to the conventions defined for SIP in section 7.3.1 of RFC 3261. Each header field consists of a field name followed by a colon (":") and the field value. field-name: field-value The definitions of headers are defined in Section 5. There is no specific requirement for the order in which the information headers should be present in the charging information. The header names and the header values are case sensitive. Prasanna Expires - May 2003 [Page 6] BIP: Billing information Protocol Dec 2002 5.Header Fields This section lists the full set of header fields along with notes on syntax, meaning, and usage. The ABNF [8] definitions for the headers follow the notations on the basis of section 25 of SIP (RFC 3261[1]). The conditions for the presence of the header fields in the billing information are summarized in Table 1. The following codes are used in the table. c: Conditional; requirements on the header field depend on other fields in the information. m: The header field is mandatory. o: The header field is optional. Header Field presence _____________________________________________________ Advice-State m Charge-Type m Charge-Units c Currency-Amount c Currency-ID o Duration o Bill-ID o Service-Type o Hash o Table 1: Presence of headers 5.1.Advice-State The advice state header field defines the state of the advice of the charge. The charging information may be liable to be updated. In this case the state of the advice is termed as ôIntermediateö. But if the billing entity knows there is going to be no further updates on the charging information then the charging information may be termed ôfinal. This header field MUST be present one and only once per billing information. Advice-State = "Advice-State" HCOLON Advice-States Advice-State = "final" | "intermediate" Example: Advice-State: final Prasanna Expires - May 2003 [Page 7] BIP: Billing information Protocol Dec 2002 5.2.Charge-Type This header field defines the type of the charging information. Though there are many kinds of charging, this document formally defines three of them: normal charging, free call and reverse charging. This header MUST be present one and only once per billing information. While the first two are used for any application, reverse- charging is a typical telephony concept. Charge-Type = "Charge-Type" HCOLON Charge-Types Charge-Types = "normal" | "reverse" | "free" | other-type other-type = token Example: Charge-Type: normal 5.3.Charge-Units This field provides the number of charge units incurred. If the Charging Type is not "free" either this field or Currency Units (section 5.4) MUST be present. Charge-Units = "Charge-Units" HCOLON 1*DIGIT["." 1*DIGIT] Example: Charge-Units = 12.2 5.4.Currency-Units This field defines the number of currency units incurred when this charging information was generated. If the Charging Type is not "free" either this field or Currency Units (section 5.3) MUST be present. Currency-Units = "Currency-Units" HCOLON 1*DIGIT["." 1*DIGIT] Example: Currency-Units = 1.4 Prasanna Expires - May 2003 [Page 8] BIP: Billing information Protocol Dec 2002 5.5.Currency-ID This field defines the currency used for charging. This normally shall be used in conjunction with the Currency Units. If this field is absent then the default currency as agreed upon by the billed entity and the billing entity shall be used. However the mechanisms by which this information is shared is outside the scope of this document. Currency-Identifier = "Currency-ID" HCOLON quoted-string For certain currencies like "Yuan" or "Yen" the symbol may not be a part of the ASCII definition and may required UTF-8 symbols. Example: Currency-ID: "Rs." Currency-ID: "$" 5.6.Duration This field defines the number of seconds elapsed in the interaction. Though this can be computed by the client themselves, this timing information serves as a basis on which the charge information could have been calculated. Duration = "Duration" HCOLON 1*DIGIT ["." 1*DIGIT] Example: Duration: 140 5.7.Bill-ID This field can optionally identify this charging information uniquely. This field may be required for some applications to identify the charging information generated by the same set of billing entity and billed entity but for different interactions. Bill-Identifier = "Bill-ID" HCOLON token [ô@ö token] 5.8.Service-Type If the billing was done for some special service rendered by the billing entity, the service type can be optionally carried by the charging information. This document defines a small set of services that can be extended. All these services are typical telephony services. Service-Type = "Service-Type" HCOLON Service-Types Prasanna Expires - May 2003 [Page 9] BIP: Billing information Protocol Dec 2002 Service-Types = "cfu" | "cfb" | "cfnr" | "ct" | other-services other-services = token The meanings of the service types are as follows cfu - Call Forward Unconditional cfb - Call Forward Busy cfnr - Call Forward No Resposne ct - Call Transfer Example: Service-Type: cfu 5.9.Hash This field can optionally provide a cryptographic hash of the charging information and a secret key shared between the billing entity and billed entity. The recommended mechanism is MD5( charging information + ô:ö + Shared Secret Key ) Hash = "Hash" HCOLON (32LHEX | token )ö;ö Alg-param Alg-param = ôalgorithmö EQUAL (ômd5ö | token) Example: Hash: c3fcd3d76192e4007dfb496cca67e13b;algorthim=md5 6.Illustrative Examples A provision of Advice Of Charge at the end of a call is taken as an example. BYE sip:callee@example.com SIP/2.0 From: "Caller" ;tag=12sdfa.234 To: "Callee" ;tag=exdsra.ert Call-ID: 12345@example.com CSeq: 2 BYE Via: SIP/2.0/UDP 169.100.1.1;branch=z9hG4bKnashds10 Content-Type: application/billing Content-Length: 107 Advice-State: final Bill-ID: 12345@example.com Charge-Type: normal Charge-Units: 8 Duration: 210 Prasanna Expires - May 2003 [Page 10] BIP: Billing information Protocol Dec 2002 7.IANA considerations 7.1.The "application/bip" mime type This draft registers the "application/bip" MIME media type. The advice of charge information is text-based. It follows the recommendations of RFC 2045[10] for the usage of text-based data for MIME. The information elements and the data filled in the billing information are mostly derived from the ETSI specifications for Advice of Charge ([2], [3], [4]) and the ITU-T specification for the Advice of charge([5]). This media type is defined by the following information: Media type name: application Media subtype name: bip Required Parameters: None Encoding scheme: ASCII Security considerations: See section 9 8.Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. The grammar for this mime-type is mostly derived out of the SIP specification (RFC 3261[1]). The following definitions are derived from the SIP specification (RFC 3261[1]) token DIGIT HCOLON quoted-string Billing-Information = *(Information-Header) Information-Header = (Advice-State / Charge-Type / Charge-Units / Currency-Units / Currency-Identifier / Duration / Bill-Identifier / Service-Type / Hash / extension-header ) Prasanna Expires - May 2003 [Page 11] BIP: Billing information Protocol Dec 2002 Advice-State = "Advice-State" HCOLON Advice-States Advice-State = "final" | "intermediate" Charge-Type = "Charge-Type" HCOLON Charge-Types Charge-Types = "normal" | "reverse" | "free" | other-type other-type = token Charge-Units = "Charge-Units" HCOLON 1*DIGIT["." 1*DIGIT] Currency-Units = "Currency-Units" HCOLON 1*DIGIT["." 1*DIGIT] Currency-Identifier = "Currency-ID" HCOLON quoted-string Duration = "Duration" HCOLON 1*DIGIT Bill-Identifier = ôBill-IDö HCOLON token [ô@ö token] Service-Type = "Service-Type" HCOLON Service-Types Service-Types = "cfu" | "cfb" | "cfnr" | "ct" | other-services other-services = token Hash = "Hash" HCOLON (32LHEX | token )ö;ö Alg-param Alg-param = ôalgorithmö EQUAL (ômd5ö | token) extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 9.Security Considerations Information carried by the Billing Information Protocol may include sensitive customer information, potentially requiring use of encryption. A charging information should not be trusted until it is ensured that it is received through reliable sources. Since the charging information is carried by various protocols, security mechanisms defined by these protocols to ensure security and authenticity SHOULD be used. As a reference, security mechanisms provided in SIP [1] (section 26.1.3) can be used as this is appropriate for both the SIP message and the encapsulated charging information. It is preferable to receive the billing information over a secure protocol, like SIP over TLS. Encryption of the billing-information is also considered a good solution. Some form of cryptographic hashing on the billing information may be used to ensure there is no tampering of the message en-route. MD5 (RFC 1321[14]) is a good choice. Prasanna Expires - May 2003 [Page 12] BIP: Billing information Protocol Dec 2002 However if the carrier protocol is not providing any security mechanism, a cryptographic hash of the charging information along with a shared key SHOULD be carried as a part of the charging information. 10.References 1 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. 2 ETSI Recommendation, "Advice of Charge: charging information at call set-up time (AOC-s) supplementary service description", ETS 300 178, October 1992. 3 ETSI Recommendation, "Advice of Charge: charging information during the call (AOC-D) supplementary service description", ETS 300 179, October 1992. 4 ETSI Recommendation, "Advice of Charge: charging information at the end of the call (AOC-E) supplementary service description", ETS 300 180, October 1992. 5 ITU-T Recommendation, "Advice of Charge ", ITU-T Rec. Q.965.2, October 1995. 6 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 9 Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. 10 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 11 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Prasanna Expires - May 2003 [Page 13] BIP: Billing information Protocol Dec 2002 12 Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. 13 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 14 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. Acknowledgments Thanks for the SIP and the Huawei soft-switch team which actively proposed the idea for a protocol to carry billing information. In particular I wish to thank Dr. Ford, WangYing, Kamesh, XuPeili, Ranjit, LuKe, ChenMin and YuanZiWen, all belonging to Huawei India for helping me carry this work forward and providing the idea and comments. Author's Addresses R. Prasanna Huawei Technologies India Pvt. Ltd. Level IV, No.23, Leela Galleria, Airport Road, Bangalore - 560 008 Phone: +91-080-521 6824 Email: prasanna@huawei.com Prasanna Expires - May 2003 [Page 14] BIP: Billing information Protocol Dec 2002 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. Prasanna Expires - May 2003 [Page 15]