One document matched: draft-dcsgroup-sip-proxy-proxy-01.txt
Differences from draft-dcsgroup-sip-proxy-proxy-00.txt
SIP Working Group W. Marshall
Internet Draft K. Ramakrishnan
Document: <draft-dcsgroup-sip-proxy-proxy-01.txt> AT&T
Category: Informational
E. Miller
G. Russell
CableLabs
B. Beser
M. Mannette
K. Steinbrenner
3Com
D. Oran
F. Andreasen
Cisco
J. Pickens
Com21
P. Lalwaney
J. Fellows
Motorola
D. Evans
Secure Cable Solutions
K. Kelly
NetSpeak
March, 2000
SIP proxy-to-proxy extensions for supporting Distributed Call State
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026[1], and the author does not provide the
IETF with any rights other than to publish as an Internet-Draft.
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
DCS Group Category Informational - Expiration 9/30/2000 1
SIP Proxy-to-Proxy Extensions March 2000
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
dcsgroup-sip-proxy-proxy-01.txt>, and expires September 30, 2000.
Please send comments to the authors.
1. Abstract
In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys customer-specific information and expectations about
the parties involved in the call. This document describes extensions
to the Session Initiation Protocol (RFC2543) for supporting the
exchange of customer information and billing information between
trusted entities in the architecture described in <draft-dcsgroup-
sip-arch-01.txt>.
2. Conventions used in this document
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 [2].
3. Introduction
In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys billing information and expectations about the parties
involved in the call.
There are many billing models used in deriving revenue from
telephony services today. Charging for telephony services is tightly
coupled to the use of network resources. It is outside the scope of
this document to discuss the details of these numerous and varying
methods.
A key motivating principle of the DCS architecture described in [3]
is the need for network service providers to be able to control and
monitor network resources; revenue may be derived from the usage of
these resources as well as from the delivery of enhanced services
such as telephony. Furthermore, the DCS architecture recognizes the
need for coordination between call signaling and resource
management. This coordination ensures that users are authenticated
and authorized before receiving access to network resources and
billable enhanced services.
DCS Group Category Informational - Expiration 9/30/00 2
SIP Proxy-to-Proxy Extensions March 2000
DCS-Proxies, as defined in [3], have access to subscriber
information and act as policy decision points and trusted
intermediaries along the call signaling path. Edge routers provide
the policy enforcement mechanism and also capture and report usage
information. Edge routers need to be given billing information that
can be logged with Record Keeping or Billing servers. The DCS
Proxy, as a central point of coordination between call signaling and
resource management, can provide this information based on the
authenticated identity of the calling and called parties. Since
there is a trust relationship among DCS Proxies, they can be relied
upon to exchange trusted billing information pertaining to the
parties involved in a call.
For these reasons, it is appropriate to consider defining SIP header
extensions to allow DCS Proxies to exchange information during call
setup. It is the intent that the extensions would only appear on
trusted network segments, should be inserted upon entering a trusted
network region, and removed before leaving trusted network segments.
Rules for inserting and removing headers exchanged only between
proxies are for further study.
4. Justification for proxy-to-proxy information
Significant amounts of information is retrieved by an originating
proxy in its handling of a connection setup request from a user
agent. Such information includes location information about the
subscriber (essential for emergency services calls), billing
information, and station information (e.g. coin operated phone). In
addition, while translating the destination number, information such
as the local-number-portability office code is obtained and will be
needed by all other proxies handling this call.
For Usage Accounting records, it is necessary to have an identifier
that can be associated with all the event records produced for the
call. Call-ID cannot be used as such an identifier since it is
selected by the originating user agent, and may not be unique among
all past calls as well as current calls. Further, since this
identifier is to be used by the service provider, it should be
chosen in a manner and in a format that meets the service provider's
needs.
Billing information may not necessarily be unique for each user
(consider the case of calls from an office all billed to the same
account). Billing information may not necessarily be identical for
all calls made by a single user (consider prepaid calls, credit card
calls, collect calls, etc). It is therefore necessary to carry
billing information separate from the calling and called party
identification. Furthermore, some billing models call for split-
charging where multiple entities are billed for portions of the
call.
The addition of two SIP General Header Fields allows for the capture
of billing information and billing identification for the duration
DCS Group Category Informational - Expiration 9/30/00 3
SIP Proxy-to-Proxy Extensions March 2000
of the call. Alternative techniques such as multi-part attachments
will not coexist with encrypted messages.
It is the intent that the billing extensions would only appear on
trusted network segments, and MAY be inserted by a DCS Proxy in
INVITE requests entering a trusted network segment, and removed
before leaving trusted network segments.
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [4].
The proposed additional headers are:
BILLING-INFO
The Billing-info general header identifies a subscriber account
number of the payer, and other information necessary for accurate
billing of the service. This header MUST only used between Proxies.
Billing-Info = "Billing-Info" ":" hostport "<" Acct-Data ">"
Acct-Data = 1*unreserved | (1*unreserved "," Acct-Data)
The hostport specifies a record keeping server. Acct-Data is
arbitrary format data understood only by the record keeping server.
The Acct-Data may contain a security key needed to send event
records to the record keeping server.
BILLING-ID
The Billing-ID general header contains an identifier that can be
used by an event recorder to associate multiple usage records,
possibly from different sources, with a billable account. This
header MUST only be used between Proxies.
Billing-ID = "Billing-ID" ":" 1*unreserved
A proposed implementation of billing ID is a string made up of DCS
proxy's IP address, timestamp, and sequence number.
GATE-LOCATION
The Gate general header contains the location and identifier of a
Gate associated with the IP flow for this call. This information is
needed for gate coordination, as described in [3].
Gate = "Gate" ":" hostport "/" Gate-ID
[";" Gate-Key ";" Gate-CipherSuite]
DCS Group Category Informational - Expiration 9/30/00 4
SIP Proxy-to-Proxy Extensions March 2000
Gate-ID = 1*alphanum
Gate-Key = 1*alphanum
Gate-CipherSuite = token
REQUEST-URI
The Request-URI is extended to allow a phone number to contain
augmented information, which may include the local-number-
portability office code. The telephone-subscriber syntax defined in
<draft-antii-telephone-url-12.txt> allows augmented information to
be exchanged between proxies. As such, if the host is an Internet
telephony device, the SIP URL user field MAY encode a phone number
or an augmented phone number using the telephone-subscriber syntax
of <draft-antii-telephone-url-12.txt>.
To semantically distinguish this form of host, the token user=phone
is included, as in standard SIP.
6. Security Considerations
The general headers and request URI extensions described in this
draft MUST only be used between proxies, and MUST never be given to
a user agent.
Billing information is often considered sensitive and private
information to the customers. It is therefore necessary that the
Proxies take precautions to protect this information from
eavesdropping and interception. Use of IPSec between Proxies is
recommended.
7. References
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 DCS Group, "Architectural Considerations for Providing Carrier
Class Telephony Services Utilizing SIP-based Distributed Call
Control Mechanisms", draft-dcsgroup-sip-arch-01.txt, March 2000.
4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
DCS Group Category Informational - Expiration 9/30/00 5
SIP Proxy-to-Proxy Extensions March 2000
8. Acknowledgments
The Distributed Call Signaling work in the PacketCable project is
the work of a large number of people, representing many different
companies. The authors would like to recognize and thank the
following for their assistance: John Wheeler, Motorola; David
Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin,
Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks;
Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho,
Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent
Cable Communications.
9. Author's Addresses
Bill Marshall
AT&T
Florham Park, NJ 07932
Email: wtm@research.att.com
K. K. Ramakrishnan
AT&T
Florham Park, NJ 07932
Email: kkrama@research.att.com
Ed Miller
CableLabs
Louisville, CO 80027
Email: E.Miller@Cablelabs.com
Glenn Russell
CableLabs
Louisville, CO 80027
Email: G.Russell@Cablelabs.com
Burcak Beser
3Com
Rolling Meadows, IL 60008
Email: Burcak_Beser@3com.com
Mike Mannette
3Com
Rolling Meadows, IL 60008
Email: Michael_Mannette@3com.com
Kurt Steinbrenner
3Com
Rolling Meadows, IL 60008
Email: Kurt_Steinbrenner@3com.com
DCS Group Category Informational - Expiration 9/30/00 6
SIP Proxy-to-Proxy Extensions March 2000
Dave Oran
Cisco
Acton, MA 01720
Email: oran@cisco.com
Flemming Andreasen
Cisco
Edison, NJ
Email: fandreas@cisco.com
John Pickens
Com21
San Jose, CA
Email: jpickens@com21.com
Poornima Lalwaney
Motorola
San Diego, CA 92121
Email: plalwaney@gi.com
Jon Fellows
Motorola
San Diego, CA 92121
Email: jfellows@gi.com
Doc Evans
Secure Cable Solutions
Westminster, CO 30120
Email: drevans@securecable.com
Keith Kelly
NetSpeak
Boca Raton, FL 33587
Email: keith@netspeak.com
DCS Group Category Informational - Expiration 9/30/00 7
SIP Proxy-to-Proxy Extensions March 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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."
Expiration Date This memo is filed as <draft-dcsgroup-sip-proxy-
proxy-01.txt>, and expires September 30, 2000.
DCS Group Category Informational - Expiration 9/30/00 8
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:45 |