SIPPING Beck
Internet-Draft T-Systems Nova GmbH
Expires: June 20, 2003 December 20, 2002
SIP endpoint service charging requirements
draft-beck-sipping-svc-charging-req-01
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.
This Internet-Draft will expire on June 20, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Today, a SIP user wanting to charge for a service needs to establish
an agreement with all prospective callers. This administrative
overhead can be avoided if caller and callee can prove the duration
and existence of a call in case of a dispute. The draft describes
requirements for protocols and SIP extensions that can be used to
implement such functionality.
Beck Expires June 20, 2003 [Page 1]
Internet-Draft SIP endpoint service charging requirements December 2002
1. 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 [1].
Beck Expires June 20, 2003 [Page 2]
Internet-Draft SIP endpoint service charging requirements December 2002
2. Introduction
The total cost of a call can be split into the following components:
access
flat fees for IP access, SIP proxy/registrar usage etc.
bandwidth reservation
Scaling issues have prevented the introduction of bandwidth
reservation protocols in today's Internet. Such protocols will
have their own accounting mechanisms.
bandwidth usage
With the deployment of DiffServ, usage sensitive billing will
become more widespread. Accounting of DiffServ packets is done in
routers and is outside the scope of SIP. However, a SIP proxy
controlling a COPS [3] Policy Decision Point could prevent a
customer from being flooded with expensive high priority packets.
service provided by the callee
Examples are PSTN-Gateways and support hotlines. Today, these
services require an agreement between caller and callee before the
first call is made. The costs and administrative efforts to
handle the agreements limit the applicability of such schemes.
There is no way to prove the existence or duration of a call.
An ad-hoc way to charge incoming calls would allow to introduce new
services and to replicate the PSTN's Premium Rate service. Providers
of gateways, media and conferencing servers would profit from lower
administrative costs.
Ordinary end users could charge callers: instead of blocking spammer
domains, solicitors could be charged with special fees for making
calls ("pay for attention"). End users could charge callers and use
the money to pay their own high-priority VoIP traffic.
The rest of this document deals with the requirements for charging
services provided by an endpoint.
Beck Expires June 20, 2003 [Page 3]
Internet-Draft SIP endpoint service charging requirements December 2002
3. Overall Requirements
3.1 Scalability and Reliability
If third parties or intermediaries are needed to meet the
requirements of this draft, the amount of state in those entities
must be kept as low as possible. It MUST be possible to distribute
the load on multiple entities without mirroring state.
It SHOULD be possible for a client to recover within a few seconds
when a third party or intermediary fails.
3.2 Cheap End Devices
Some end devices have only limited CPU power and RAM space. A
solution SHOULD either use this resources sparingly enough or SHOULD
allow to delegate functionality to an intermediary. In the latter
case the UA MUST use a secure transport protocol to contact the
intermediary.
Permanent storage in the UA MUST NOT be a prerequisite. A solution
MUST be able to cope with device failures and network outages.
3.3 Mobile End Devices
Wireless links often have limited capacity, high error rates and use
small MTU sizes. Solutions SHOULD prefer protocols with short
messages and few round trips.
3.4 Reuse of existing protocols and formats
Existing cryptographic protocols and formats SHOULD be re-used
wherever possible.
To implement non-cryptographic functionalities, existing protocols
and formats SHOULD be used, as long as no other requirements are
violated.
Beck Expires June 20, 2003 [Page 4]
Internet-Draft SIP endpoint service charging requirements December 2002
4. Functional Requirements
4.1 Fairness
The caller MUST NOT be able to repudiate the time and duration of a
call.
The callee MUST NOT be able to charge for calls that never happened.
4.2 Anonymity
It MUST be possible for the caller to remain anonymous. Only in
cases of dispute, a trusted third party should be able to reveal the
real identity of the caller.
4.3 Expense Control
The caller needs to know about the price of the service offered by
the callee. It must either be possible to
o allow the involvement of a trusted third party, which either
provides the pricing information itself or records/signs the
pricing information provided by the callee.
o or allow the caller to set an explicit expense limit.
The latter could be achieved by using signed tokens as in some
micropayment protocols.
If the session setup fails, the caller MUST NOT be charged.
Furthermore, it must be possible to
o immediately display the current rate to the caller
o allow user-defined pricing schemes that depend on day time and
contents of a SIP message (like From: header, To: header etc).
o allow the calling UA to process the pricing information
automatically
Today's SIP can fulfill only some of these requirements:
o The callee refers to his web page (eg. in a Call-Info header) or
plays an announcement. However, in cases of dispute it will not
be easy to prove the correctness of the web page or announcement.
o The callee uses a Call-Info header that includes a URL pointing to
Beck Expires June 20, 2003 [Page 5]
Internet-Draft SIP endpoint service charging requirements December 2002
a trusted third party's web page. This web page displays the
pricing information of the callee's service. This solution
requires a web browsing capability in the UA.
o The callee is reachable through a trusted third party that plays
the announcement and refers to the callee's real UA (eg. by using
the REFER method). This solution introduces additional setup
delays.
Neither web pages nor voice announcements can be processed
automatically.
4.4 Accounting
The callee's UA can easily record accounting data, like call duration
and generated IP traffic. The question is whether the caller can
trust the callee.
4.4.1 Evidence of session establishment
The callee needs an evidence that a session has been established. In
case of dispute, he can show the evidence and prove that a caller has
really called. The evidence should contain the relevant details of
the session (time, media etc).
4.4.2 Evidence of session teardown
In case of dispute, the caller needs an evidence that a session ended
at a certain time. As sessions can be terminated without any message
exchange (eg. if a UA dies), the evidence generation is hard.
The evidence of session teardown can be replaced with the evidence of
an ongoing session. The session timer mechanism described in [4]
uses this technique.
In case of dispute, the evidence of session establishment and the
evidence of session teardown show that there has been a session. To
determine the accurate duration of the session the evidences need to
be time-stamped by a trusted third party.
Periodical evidences during a session have some advantages. The call
duration can be derived from the number of evidences and no secure
time source is needed. The evidence of session teardown needs no
extra mechanism. However, there is a trade-off between the
resolution of the call duration measurement and signaling bandwidth
requirements. A cooperative callee will only charge for the exact
call duration, though.
Beck Expires June 20, 2003 [Page 6]
Internet-Draft SIP endpoint service charging requirements December 2002
5. Security Considerations
Some of the above requirement sections deal with security issues
which are discussed there. Proven security mechanisms and protocols
should be used wherever possible.
Forging evidences MUST NOT be possible in reasonable time without
specialized hardware or very large clusters.
It MUST be possible to exchange security relevant parts of a solution
with improved versions. If an implementations speaks to an older
version it MUST either ask for user confirmation or reject the
message. The user MUST be warned of bidding-down attacks.
To avoid denial of service attacks, every stateful entity MUST
authenticate clients before creating state.
Beck Expires June 20, 2003 [Page 7]
Internet-Draft SIP endpoint service charging requirements December 2002
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[4] Rosenberg, J. and S. Donovan, "Session Initiation Protocol
Extension for Session Timer", draft-ietf-sip-session-timer-10
(work in progress), November 2002.
[5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[6] European Telecommunications Standards Institute, "Open
Settlement Protocol (OSP) for interdomain pricing and usage
exchange", ETSI TIPHON TS 101 321 v2.1.1 2000-08, August 2000.
[7] Johnston, A. and D. Rawlins, "Session Initiation Protocol
Private Extension for an OSP Authorization Token",
draft-johnston-sip-osp-token-03 (work in progress), November
2002.
[8] Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996.
Author's Address
Wolfgang Beck
T-Systems Nova GmbH
Am Kavalleriesand 3
Darmstadt 64295
Germany
EMail: beckw@t-systems.com
Beck Expires June 20, 2003 [Page 8]
Internet-Draft SIP endpoint service charging requirements December 2002
Appendix A. TLS-based micropayment schemes
Some web payment schemes use TLS (Transport Layer Security [5])
connections to a trusted third party. These schemes could be adopted
for SIP:
1. The callee returns a https URI in a Call-Info header of a '402
Payment Required' response. The https URI points to a web page
of a trusted billing service provider. The URI contains the
callee's name, a service description, rates and a unique ID.
2. The billing service provider checks if the caller is able to pay.
3. The caller's UA starts a browser to display the billing service
provider's web page which displays the callee's pricing
information. The caller confirms his willingness to pay by
clicking on a button.
4. The billing service provider redirects the caller's web browser
to a SIP URI that contains cryptographically signed transaction
data. The caller's SIP UA calls this SIP URI and the callee
checks the cryptographic portion of it. If it is valid, the
callee accepts the call.
This procedure requires some interaction between UA and web browser.
A web browser is not always present, though. Periodical small
payments to limit the caller's risk are inconvenient. The billing
service provider's web page can't be processed by a program that
assists the user.
Beck Expires June 20, 2003 [Page 9]
Internet-Draft SIP endpoint service charging requirements December 2002
Appendix B. Evaluation of the Open Settlement Protocol
The Open Settlement Protocol [6] is a promising protocol candidate.
A trusted third party, the OSP server, hands out signed authorization
tokens. The authorization tokens are a kind of ticket. Like a
ticket, the token contains a lifespan information (valid-after,
valid-until).
OSP does not really record an evidence of session establishment. It
records the fact that some user is willing to pay for a call. OSP is
not involved in the call signalling itself. It can't provide an
evidence of session teardown and is not able to verify the usage
indications it receives.
OSP allows periodic re-authorization that fits well into SIP's
session timer mechanism. The OSP server can estimate the call
duration by counting the re-authorizations. The settlement provider
can use this estimation for billing if there is a significant
difference between the caller's and the callee's usage indication.
B.1 Example Message Flow
1. The caller requests a token from an OSP server
(AuthorizationRequest, AuthorizationResponse).
2. The caller sends an INVITE to the callee containing the OSP token
[7].
3. The callee verifies the OSP token. If it is invalid or missing,
the caller responds with "402 Payment required". If the token is
valid, the callee accepts the call and responds with "200 OK".
Beck Expires June 20, 2003 [Page 10]
Internet-Draft SIP endpoint service charging requirements December 2002
Alice's UA OSP Server Bob's UA
| | |
+-- INVITE ---------------------------------->|
| | |
|<------------------- 402 Payment Required ---+
| | |
+-- AuthorizationReq -->| |
| | |
|<- AuthorizationRes ---+ |
| | |
+-- INVITE (token) -------------------------->|
| | |
|<-------------------------------- 200 OK ----+
| | |
+-- ACK-------------------------------------->|
| | |
| | |
4. If the callee does not trust the caller, he finishes the call
when the caller's credit is used up.
5. To prevent the callee from dropping the call, the caller requests
re-authorization from its OSP server and sends an INVITE or
UPDATE message containing the new OSP token to the callee.
Alice's UA OSP Server Bob's UA
+- ReAuthorizationReq ->| |
| | |
|<- ReAuthorizationRes -+ |
| | |
+-- UPDATE (token) -------------------------->|
| | |
|<-------------------------------- 200 OK ----+
| | |
+- ReAuthorizationReq ->| |
| | |
|<- ReAuthorizationRes -+ |
| | |
+-- UPDATE (token) -------------------------->|
| | |
|<-------------------------------- 200 OK ----+
| | |
.. etc
6. After the call has finished, the callee sends a usage indication
message to its OSP server. The usage indication does not only
Beck Expires June 20, 2003 [Page 11]
Internet-Draft SIP endpoint service charging requirements December 2002
contain information about the session duration, but also the OSP
tokens received during the call.
Alice's UA OSP Server Bob's UA
| | |
+-- BYE ------------------------------------->|
| | |
|<-------------------------------- 200 OK ----+
| | |
+- UsageIndication ---->|<-- UsageIndication -+
| | |
|<- UsageConfirmation --+- UsageConfirmation >|
7. The settlement provider who runs the OSP server derives a call
detail record from the usage indications and the number of
re-authorizations.
B.2 Discussion
Some open questions remain:
o Is the OSP architecture scalable enough to handle requests of
millions of SIP UAs? OSP was designed to operate with gateways,
not with endpoints. Periodic OSP re-authorizations and SIP
session refreshs will stress OSP servers and SIP proxies.
o Is OSP too complex for small end devices? OSP uses HTTP, XML, S/
MIME and TLS. Many SIP devices already support HTTP for
configuration purposes. S/MIME and TLS can be used for SIP as
well. The memory and CPU requirements will be an obstacle for
small and/or cheap end devices.
o Will OSP extend setup delays? OSP uses simple request/response
pairs in a TLS connection. If the UA and the OSP server keep
existing TLS sessions open, the setup delay caused by TCP and TLS
connection setup can be reduced.
An expired draft (sinnreich-interdomain-sip-qos-osp-03) described an
architecture where OSP was used to authenticate interdomain bandwidth
reservations. This approach would not necessarily collide with the
OSP usage outlined here. An INVITE would just carry two OSP
authorization tokens, one for authorizing the bandwidth reservation
and one for authorizing access to a non-free service.
Beck Expires June 20, 2003 [Page 12]
Internet-Draft SIP endpoint service charging requirements December 2002
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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 assignees.
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
Beck Expires June 20, 2003 [Page 13]
Internet-Draft SIP endpoint service charging requirements December 2002
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Beck Expires June 20, 2003 [Page 14]