Internet DRAFT - draft-beck-sippping-billing-scen
draft-beck-sippping-billing-scen
INTERNET DRAFT Wolfgang Beck
SIPPING Working Group T-Systems Nova
draft-beck-sippping-billing-scen-00 28 March 2002
SIP billing scenarios
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 docu-
ments 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 September 28, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
In contrast to other Internet services, most SIP sessions take
place between individuals. Today's billing schemes (flat rate or
volume based) do not reflect that. A caller causes costs on the
callee's side. With SIP's authentication methods and few additional
headers, a SIP billing service could be established that would
enable callees to charge their callers. Call stateful proxies are
not required.
Beck Expires September 2002 [Page 1]
Internet-Draft SIP billing scenarios 28 March 2002
Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [4].
Motivation
How to mimic PSTN style billing with SIP is a frequently asked
question. The lack of the centralized state makes billing diffi-
cult. Today, Internet providers charge either a flat rate or by
volume. Sender and receiver share the cost of a session. This is
fair as long as both parties agree upon this. By accessing a web
site, the user accepts the site returning a certain amount of traf-
fic. The owner of the web site accepts the visitors causing traf-
fic he is being charged for. With e-mail the situation is often
different. This is known as unsolicited e-mail or spam. As with
e-mails, so can unsolicited SIP calls be expected. By imposing a
charge on the traffic caused by the caller, it is possible to limit
unwanted solicitation. Furthermore, there are additional services
such as access to PSTN gateways, non-free support hotlines etc,
that require billing.
Glossary
BSP Billing service provider. A trusted third party that gathers
call details and handles billing on behalf of callees
BP Billing proxy. A proxy of a billing service provider authenti-
cating and recording transactions.
billing system
A system that gathers transaction records from BPs and recon-
structs call details. It does consistency checks to detect
fraud.
Requirements
SIP follows the common internet design principles in maintaining
call state in the end device. Billing should not change this.
* Callers MUST be protected against false claims.
Beck Expires September 2002 [Page 2]
Internet-Draft SIP billing scenarios 28 March 2002
* Callers MUST be able to limit the cost associated with a SIP
call to a certain callee.
* Callees MUST be protected against repudiation of calls.
* Billing MUST be possible across provider boundaries
Creating and updating billing information in the end device has
some security shortcomings. A trusted third party is needed that
collects and verifies call details. A bullet-proof non-repudiation
system is difficult to implement. However, it should be possible to
achieve at least the non-repudiation level of today's PSTN.
Collecting call data
A callee willing to use a billing service accepts only transactions
that have passed one of the billing service provider's proxies.
The BSP's proxies send transaction details to a repository where
the call details can be reconstructed. The proxies need not to be
stateful.
The BSP's proxy authenticates the callers with SIP mechanisms.
Transactions originating from unknown proxies or UAs are not
logged. They will not be forwarded but redirected. The callee can
decide whether he accepts the call which the caller can not be
charged for.
The call details reconstructed from transactions of authenticated
callers can be used for invoicing.
* The call duration can be used for client billing
* The call time and type can be used to find SIP sessions match-
ing IP flow information collected by the callee's access
router. If the callee pays for traffic volume, he can charge
the caller using this data. If BSP and ISP are identical,
this can be done by the ISP.
The former scenario requires some agreement between callee and his
BSP, the latter resembles today's PSTN billing. Other variations
are possible.
Cross domain operations
Beck Expires September 2002 [Page 3]
Internet-Draft SIP billing scenarios 28 March 2002
To make billing services scalable, an authentication hierarchy is
required.
* A call can be billed if there is an agreement between the
caller and the callee's BSP
* A call can be billed if there is an agreement between the
caller's BSP and the callee's BSP.
To limit the number of agreements between BSPs, a toplevel settle-
ment instance would be useful. The agreement consists of authenti-
cation data and bank account details.
Determining the price
The principle of least astonishment requires some pricing informa-
tion to be included in SIP messages.
Price Tag
The UAS responds with a "402 Payment Required" containing a
pricing information. The UAC sends a new INVITE if the user is
willing to accept the indicated price.
Budget Unit
The UAC could include a budget limit header in the INVITE mes-
sage saying:
"I am willing to pay x $ per interval t". The UAS rejects the
call if this limit is insufficient.
The UAS's response contains a pricing information.
If the UAS accepts the call, it monitors the UAC's budget. If
the limit is reached, it sends a re-INVITE containing a new
pricing information.
If the caller responds with a "200 OK" containing the new bud-
get, the call continues.
The BSP records the call's transactions.
Although re-INVITEs require additional bandwidth, yet it is
quite fail-safe and allows billing schemes vary over time.
[UPDATE instead of re-INVITE?]
Additional schemes may be possible.
Beck Expires September 2002 [Page 4]
Internet-Draft SIP billing scenarios 28 March 2002
Security Considerations
The billing service is a trusted third party that collects data
about SIP transactions. The billing service is a component to pre-
vent repudiation.
Non-repudiation of Origin/Receipt
The BP authenticates a UA or a different BSP's proxy with com-
mon SIP mechanisms, like TLS, IPSec or digest.
Non-repudiation of Delivery/Submission
The delivery of the BYE message must be confirmed by the BSP.
A UAC may construct BYE requests that will be seen by the BP
but not by the UAS, eg. by choosing a low Max-Forwards value.
However, the billing system can detect whether the UAS has
received the BYE or not. Error responses such as "483 Too many
Hops" or "482 Loop detected" show that a SIP device has dis-
carded the message. To avoid packet loss, the remaining down-
stream proxies MUST use reliable transport and they MUST have
a trust relationship with the BSP.
A UAC can circumvent the BP by sending requests directly to the
UAS. A malicious callee can use this to pretend a long call dura-
tion. It sends a BYE request directly to the UAS to terminate the
real session and issues a BYE request to the BP later. The UAS
responds with a "481 Call/Transaction does not exist". The calling
UA can prevent such frauds in rejecting requests that were not
authenticated by a BSP.
The pricing information headers MUST be integrity protected.
References
[1] Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J.,
"SIP: Session Initiation Protocol", Work In Progress, draft-ietf-
sip- rfc2543bis-09.txt, IETF, February 2002
[2] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
for Comments 2246, Internet Engineering Task Force, Jan. 1999.
[3] S. Kent and R. Atkinson, "Security architecture for the inter-
net protocol," Request for Comments 2401, Internet Engineering Task
Force, Nov. 1998.
Beck Expires September 2002 [Page 5]
Internet-Draft SIP billing scenarios 28 March 2002
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Acknowledgements
Dariusch Shirinzadeh
T-Systems Nova
Author's Address
Wolfgang Beck
T-Systems Nova
Am Kavalleriesand 3
64295 Darmstadt, Germany
electronic mail: beckw@t-systems.com
Beck Expires September 2002 [Page 6]
