idnits 2.17.00 (12 Aug 2021) /tmp/idnits12696/draft-prasanna-bip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations: See section 9' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (December 2002) is 7097 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '6' on line 12 looks like a reference -- Missing reference section? '7' on line 51 looks like a reference -- Missing reference section? '1' on line 518 looks like a reference -- Missing reference section? '14' on line 526 looks like a reference -- Missing reference section? '8' on line 247 looks like a reference -- Missing reference section? '10' on line 439 looks like a reference -- Missing reference section? '2' on line 443 looks like a reference -- Missing reference section? '3' on line 457 looks like a reference -- Missing reference section? '4' on line 443 looks like a reference -- Missing reference section? '5' on line 444 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 Document: draft-prasanna-bip-00.txt Huawei Technologies 4 Expires: May 2003 December 2002 6 BIP: Billing Information Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [6]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This internet draft will expire on Jun, 2003. 31 Abstract 33 Billing information protocol is a simple protocol that can be used 34 by servers to indicate the charging information incurred due to a 35 specific operation with a client. In many situations a client, like 36 a SIP user agent may need to know the charging information about a 37 specific interaction with the server. This document defines the 38 BIP (Billing Information Protocol) that can be used as a standard 39 way to share this charging information. BIP supports simple 40 indication of charging information. The protocol defines a generic 41 representation on the number of units charged, the charge incurred 42 per unit etc. This will be useful for implementing services like 43 advice of charge. The protocol is targeted for VoIP usages, 44 however any generic client-server interaction can use this 45 protocol. 47 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC-2119 [7]. 52 Table of Contents 54 1. Introduction..................................................3 55 2. Definitions...................................................4 56 3. Protocol Operation............................................4 57 3.1. Charging Background......................................5 58 3.2. Charge Data..............................................5 59 3.3. Additional Charge Information............................5 60 3.4. Security.................................................6 61 4. Billing Information Protocol Syntax...........................6 62 5. Header Fields.................................................7 63 5.1. Advice-State.............................................7 64 5.2. Charge-Type..............................................8 65 5.3. Charge-Units.............................................8 66 5.4. Currency-Units...........................................8 67 5.5. Currency-ID..............................................9 68 5.6. Duration.................................................9 69 5.7. Bill-ID..................................................9 70 5.8. Service-Type.............................................9 71 5.9. Hash....................................................10 72 6. Illustrative Examples........................................10 73 7. IANA considerations..........................................11 74 7.1. The "application/bip" mime type.........................11 75 8. Formal Syntax................................................11 76 9. Security Considerations......................................12 77 10. References..................................................13 78 Acknowledgments.................................................14 79 Author's Addresses..............................................14 81 1.Introduction 83 It is a standard requirement, in the deployment of commercial 84 client-server applications, that the server can indicate charging 85 information to the client in some format and method. 87 With VoIP applications gaining a lot of popularity this requirement 88 becomes very critical. For example in the case of SIP[1], the user 89 agents may require to be provided with charging information about 90 the call they have placed. This may be as a supplementary service 91 like "Advice of Charge" or used for pre-paid card services. There 92 has to be a standard way by which this information is transferred 93 in the network and interpreted by the client. This document 94 proposes a protocol, the "billing information protocol (BIP)" that 95 can be used to share this information. 97 The motivation for this protocol is the requirement for the "advice 98 of charge" service for SIP[1]. However, this protocol is no way 99 constrained to be used only with SIP [1] or to be only used with 100 VoIP applications. It can be used for data applications with 101 little or no modification and can be carried payload by any 102 suitable protocol. 104 This document however does not enumerate all the applications of 105 this protocol, which can be identified in various other drafts for 106 this media type. This document does not define any accounting 107 procedure by which this data is collected and is only meant to 108 carry charging information between entities. It also does not 109 describe the units of charging. There has to be a prior 110 understanding on this between the billing entity and the billed 111 entity. 113 The billing information may in most of the conditions be rendered, 114 but other handling may be defined suitably by the applications. 116 This protocol information is required to be carried in signalling 117 protocols like SIP or HTTP. This document identifies SIP [1] as a 118 suitable carrier for this protocol. Other suitable carriers may 119 also be defined by other documents. 121 2.Definitions 123 The following generic definitions are relevant to this document 125 Charging information: the data carried by the protocol 127 Information header: Header containing some charging element and 128 its value 130 Billing entity: The server or entity that generates the billing 131 information 133 Billed entity: The client or entity to which the billing 134 information is sent 136 The following telephony related definitions are relevant to this 137 document 139 Advice Of Charge: The advice of charge allows the served user to 140 be informed of usage-based charging information. This is the 141 typical application that is the motivation for this protocol. 143 Reverse Charging: Where a called user is charged rather than the 144 calling user 146 3.Protocol Operation 147 The protocolÆs singular purpose is to carry charging related data 148 from the billing entity to the billed entity. The way the data is 149 created or computed is beyond the scope of the protocol. Though it 150 is expected that the charging information carried is accurate at 151 that point of time, the validity of the charging information is an 152 agreement between the billing entity and the billed entity. 154 The information contains a series of information lines. Each line 155 contains some part of the charging information. While the most 156 common handling of the charging information by the billed entity 157 may be displaying it to the user, other operations like terminating 158 a call based on the billing data or request of additional currency 159 from the user in the case of a public phone may be performed. 161 This protocol just defines how the data is to be carried, various 162 usages of this protocol has to be enumerated in other documents. 164 The protocol uses text based encoding and not binary encodings like 165 CDR, as the common application of this protocol shall be to display 166 the charging information to the user. 168 The pieces of information to be carried are grouped into four 169 components. 171 3.1.Charging Background 173 The charging information has to mention the kind of charging done 174 and the kind of information carried by this data. The charging 175 information generated may be intermediate or final. Intermediate 176 information is generated where the billed entity is required to be 177 fed with the charge information incrementally or periodically. The 178 charging information can be final, in which case there shall be no 179 update to the charging information. 181 The kind of charging done can be classified as free or normal or 182 reverse. This mentions why the billed entity is getting this 183 information. 185 3.2.Charge Data 187 This forms the key component of the information. The actual charge 188 information is conveyed either as units charged or currency 189 charged. The units are pre-negotiated between the billing entity 190 and the billed entity. If the currency units are mentioned, then 191 the currency can be qualified. 193 3.3.Additional Charge Information 194 To qualify the charging information in a better way some additional 195 information can be provided by the billing entity. This may be 196 additional services for which the billing entity is charging the 197 billed entity or some indication of the duration for which the 198 billed entity is charged. 200 3.4.Security 202 It is highly desirable that the carrier protocol provides the 203 security for the billing information payload. However to cater to 204 carriers which do not provide any basic security the protocol has 205 provisions for some basic security. Since data tampering is the 206 most likely security threat, optionally a cryptographic hash of the 207 information can be carried by the protocol. 209 The cryptographic hash can be a MD5 (RFC 1321 [14]) of the complete 210 charging information and a secret key shared by the billing entity 211 and the billed entity. 213 4.Billing Information Protocol Syntax 215 The media type follows the conventions of the SIP (RFC 3261 [1]) 216 for information header formatting. The billing information 217 contains a series of information headers with each of the 218 information header lines terminated by a CRLF. 220 billing-information = *info-header 221 info-header = "header-name" HCOLON header-value *(COMMA 222 header-value) CRLF 224 The basic set of information header fields are defined in this 225 document. However the information elements can be extended 226 adhering to the generic framework of header format defined 227 above. 229 The header field formats strictly adhere to the conventions 230 defined for SIP in section 7.3.1 of RFC 3261. Each header 231 field consists of a field name followed by a colon (":") and 232 the field value. 234 field-name: field-value 236 The definitions of headers are defined in Section 5. 238 There is no specific requirement for the order in which the 239 information headers should be present in the charging 240 information. 242 The header names and the header values are case sensitive. 244 5.Header Fields 246 This section lists the full set of header fields along with 247 notes on syntax, meaning, and usage. The ABNF [8] definitions 248 for the headers follow the notations on the basis of section 25 249 of SIP (RFC 3261[1]). 251 The conditions for the presence of the header fields in the 252 billing information are summarized in Table 1. The following 253 codes are used in the table. 255 c: Conditional; requirements on the header field depend on 256 other fields in the information. 258 m: The header field is mandatory. 260 o: The header field is optional. 262 Header Field presence 263 _____________________________________________________ 264 Advice-State m 265 Charge-Type m 266 Charge-Units c 267 Currency-Amount c 268 Currency-ID o 269 Duration o 270 Bill-ID o 271 Service-Type o 272 Hash o 274 Table 1: Presence of headers 276 5.1.Advice-State 278 The advice state header field defines the state of the advice of 279 the charge. The charging information may be liable to be updated. 280 In this case the state of the advice is termed as ôIntermediateö. 281 But if the billing entity knows there is going to be no further 282 updates on the charging information then the charging information 283 may be termed ôfinal. 285 This header field MUST be present one and only once per billing 286 information. 288 Advice-State = "Advice-State" HCOLON Advice-States 289 Advice-State = "final" | "intermediate" 291 Example: 292 Advice-State: final 294 5.2.Charge-Type 296 This header field defines the type of the charging information. 297 Though there are many kinds of charging, this document formally 298 defines three of them: normal charging, free call and reverse 299 charging. 301 This header MUST be present one and only once per billing 302 information. 304 While the first two are used for any application, reverse- 305 charging is a typical telephony concept. 307 Charge-Type = "Charge-Type" HCOLON Charge-Types 308 Charge-Types = "normal" | "reverse" | "free" | other-type 309 other-type = token 311 Example: 312 Charge-Type: normal 314 5.3.Charge-Units 316 This field provides the number of charge units incurred. If the 317 Charging Type is not "free" either this field or Currency Units 318 (section 5.4) MUST be present. 320 Charge-Units = "Charge-Units" HCOLON 1*DIGIT["." 1*DIGIT] 322 Example: 323 Charge-Units = 12.2 325 5.4.Currency-Units 327 This field defines the number of currency units incurred when this 328 charging information was generated. If the Charging Type is not 329 "free" either this field or Currency Units (section 5.3) MUST be 330 present. 332 Currency-Units = "Currency-Units" HCOLON 1*DIGIT["." 1*DIGIT] 334 Example: 335 Currency-Units = 1.4 337 5.5.Currency-ID 339 This field defines the currency used for charging. This normally 340 shall be used in conjunction with the Currency Units. If this 341 field is absent then the default currency as agreed upon by the 342 billed entity and the billing entity shall be used. However the 343 mechanisms by which this information is shared is outside the scope 344 of this document. 346 Currency-Identifier = "Currency-ID" HCOLON quoted-string 348 For certain currencies like "Yuan" or "Yen" the symbol may not be 349 a part of the ASCII definition and may required UTF-8 symbols. 351 Example: 352 Currency-ID: "Rs." 353 Currency-ID: "$" 355 5.6.Duration 357 This field defines the number of seconds elapsed in the 358 interaction. Though this can be computed by the client themselves, 359 this timing information serves as a basis on which the charge 360 information could have been calculated. 362 Duration = "Duration" HCOLON 1*DIGIT ["." 1*DIGIT] 364 Example: 365 Duration: 140 367 5.7.Bill-ID 369 This field can optionally identify this charging information 370 uniquely. This field may be required for some applications to 371 identify the charging information generated by the same set of 372 billing entity and billed entity but for different interactions. 374 Bill-Identifier = "Bill-ID" HCOLON token [ô@ö token] 376 5.8.Service-Type 378 If the billing was done for some special service rendered by the 379 billing entity, the service type can be optionally carried by the 380 charging information. This document defines a small set of 381 services that can be extended. All these services are typical 382 telephony services. 384 Service-Type = "Service-Type" HCOLON Service-Types 385 Service-Types = "cfu" | "cfb" | "cfnr" | "ct" | other-services 386 other-services = token 388 The meanings of the service types are as follows 389 cfu - Call Forward Unconditional 390 cfb - Call Forward Busy 391 cfnr - Call Forward No Resposne 392 ct - Call Transfer 394 Example: 395 Service-Type: cfu 397 5.9.Hash 399 This field can optionally provide a cryptographic hash of the 400 charging information and a secret key shared between the billing 401 entity and billed entity. 403 The recommended mechanism is 404 MD5( charging information + ô:ö + Shared Secret Key ) 406 Hash = "Hash" HCOLON (32LHEX | token )ö;ö Alg-param 407 Alg-param = ôalgorithmö EQUAL (ômd5ö | token) 409 Example: 410 Hash: c3fcd3d76192e4007dfb496cca67e13b;algorthim=md5 412 6.Illustrative Examples 414 A provision of Advice Of Charge at the end of a call is taken as an 415 example. 417 BYE sip:callee@example.com SIP/2.0 418 From: "Caller" ;tag=12sdfa.234 419 To: "Callee" ;tag=exdsra.ert 420 Call-ID: 12345@example.com 421 CSeq: 2 BYE 422 Via: SIP/2.0/UDP 169.100.1.1;branch=z9hG4bKnashds10 423 Content-Type: application/billing 424 Content-Length: 107 426 Advice-State: final 427 Bill-ID: 12345@example.com 428 Charge-Type: normal 429 Charge-Units: 8 430 Duration: 210 432 7.IANA considerations 434 7.1.The "application/bip" mime type 436 This draft registers the "application/bip" MIME media type. 438 The advice of charge information is text-based. It follows 439 the recommendations of RFC 2045[10] for the usage of text-based 440 data for MIME. 441 The information elements and the data filled in the billing 442 information are mostly derived from the ETSI specifications for 443 Advice of Charge ([2], [3], [4]) and the ITU-T specification for 444 the Advice of charge([5]). 446 This media type is defined by the following information: 448 Media type name: application 449 Media subtype name: bip 450 Required Parameters: None 451 Encoding scheme: ASCII 452 Security considerations: See section 9 454 8.Formal Syntax 456 The following syntax specification uses the augmented Backus-Naur 457 Form (BNF) as described in RFC-2234 [3]. 459 The grammar for this mime-type is mostly derived out of the SIP 460 specification (RFC 3261[1]). The following definitions are derived 461 from the SIP specification (RFC 3261[1]) 462 token 463 DIGIT 464 HCOLON 465 quoted-string 467 Billing-Information = *(Information-Header) 469 Information-Header = (Advice-State 470 / Charge-Type 471 / Charge-Units 472 / Currency-Units 473 / Currency-Identifier 474 / Duration 475 / Bill-Identifier 476 / Service-Type 477 / Hash 478 / extension-header ) 480 Advice-State = "Advice-State" HCOLON Advice-States 481 Advice-State = "final" | "intermediate" 483 Charge-Type = "Charge-Type" HCOLON Charge-Types 484 Charge-Types = "normal" | "reverse" | "free" | other-type 485 other-type = token 487 Charge-Units = "Charge-Units" HCOLON 1*DIGIT["." 1*DIGIT] 489 Currency-Units = "Currency-Units" HCOLON 1*DIGIT["." 1*DIGIT] 491 Currency-Identifier = "Currency-ID" HCOLON quoted-string 493 Duration = "Duration" HCOLON 1*DIGIT 495 Bill-Identifier = ôBill-IDö HCOLON token [ô@ö token] 497 Service-Type = "Service-Type" HCOLON Service-Types 498 Service-Types = "cfu" | "cfb" | "cfnr" | "ct" | other-services 499 other-services = token 501 Hash = "Hash" HCOLON (32LHEX | token )ö;ö Alg-param 502 Alg-param = ôalgorithmö EQUAL (ômd5ö | token) 504 extension-header = header-name HCOLON header-value 505 header-name = token 506 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 508 9.Security Considerations 510 Information carried by the Billing Information Protocol may include 511 sensitive customer information, potentially requiring use of 512 encryption. A charging information should not be trusted until it 513 is ensured that it is received through reliable sources. Since the 514 charging information is carried by various protocols, security 515 mechanisms defined by these protocols to ensure security and 516 authenticity SHOULD be used. 518 As a reference, security mechanisms provided in SIP [1] (section 519 26.1.3) can be used as this is appropriate for both the SIP message 520 and the encapsulated charging information. 522 It is preferable to receive the billing information over a secure 523 protocol, like SIP over TLS. Encryption of the billing-information 524 is also considered a good solution. Some form of cryptographic 525 hashing on the billing information may be used to ensure there is 526 no tampering of the message en-route. MD5 (RFC 1321[14]) is a good 527 choice. 529 However if the carrier protocol is not providing any security 530 mechanism, a cryptographic hash of the charging information along 531 with a shared key SHOULD be carried as a part of the charging 532 information. 534 10.References 536 1 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 537 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 538 Session Initiation Protocol", RFC 3261, June 2002. 540 2 ETSI Recommendation, "Advice of Charge: charging information at 541 call set-up time (AOC-s) supplementary service description", ETS 542 300 178, October 1992. 544 3 ETSI Recommendation, "Advice of Charge: charging information 545 during the call (AOC-D) supplementary service description", ETS 546 300 179, October 1992. 548 4 ETSI Recommendation, "Advice of Charge: charging information at 549 the end of the call (AOC-E) supplementary service description", 550 ETS 300 180, October 1992. 552 5 ITU-T Recommendation, "Advice of Charge ", ITU-T Rec. Q.965.2, 553 October 1995. 555 6 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 556 9, RFC 2026, October 1996. 558 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement 559 Levels", BCP 14, RFC 2119, March 1997 561 8 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 562 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 563 Demon Internet Ltd., November 1997 565 9 Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail 566 Extensions (MIME) Part Four: Registration Procedures", BCP 13, 567 RFC 2048, November 1996. 569 10 Freed, N. and N. Borenstein, "Multipart Internet Mail 570 Extensions(MIME) Part One: Format of Internet Message Bodies", 571 RFC 2045, November 1996. 573 11 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions 574 (MIME) Part Two: Media Types", RFC 2046, November 1996. 576 12 Troost, R., Dorner, S. and K. Moore, "Communicating Presentation 577 Information in Internet Messages: The Content-Disposition Header 578 Field", RFC 2183, August 1997. 580 13 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 581 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 583 14 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 584 1992. 586 Acknowledgments 588 Thanks for the SIP and the Huawei soft-switch team which actively 589 proposed the idea for a protocol to carry billing information. In 590 particular I wish to thank Dr. Ford, WangYing, Kamesh, XuPeili, 591 Ranjit, LuKe, ChenMin and YuanZiWen, all belonging to Huawei India 592 for helping me carry this work forward and providing the idea and 593 comments. 595 Author's Addresses 597 R. Prasanna 598 Huawei Technologies India Pvt. Ltd. 599 Level IV, 600 No.23, Leela Galleria, 601 Airport Road, 602 Bangalore - 560 008 603 Phone: +91-080-521 6824 604 Email: prasanna@huawei.com 605 Full Copyright Statement 607 Copyright (C) The Internet Society (2002). All Rights Reserved. 609 This document and translations of it may be copied and furnished 610 to others, and derivative works that comment on or otherwise explain 611 it or assist in its implementation may be prepared, copied, published 612 and distributed, in whole or in part, without restriction of any 613 kind, provided that the above copyright notice and this paragraph are 614 included on all such copies and derivative works. However, this 615 document itself may not be modified in any way, such as by removing 616 the copyright notice or references to the Internet Society or other 617 Internet organizations, except as needed for the purpose of 618 developing Internet standards in which case the procedures for 619 copyrights defined in the Internet Standards process must be 620 followed, or as required to translate it into languages other than 621 English. 623 The limited permissions granted above are perpetual and will not 624 be revoked by the Internet Society or its successors or assigns. 626 This document and the information contained herein is provided on 627 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.