One document matched: draft-prasanna-bip-00.txt
Internet Draft <R. Prasanna>
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" <sip:caller@example.com>;tag=12sdfa.234
To: "Callee" <sip:callee@example.com>;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]
| PAFTECH AB 2003-2026 | 2026-04-21 19:30:41 |