Internet Draft SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-sip-proxy-proxy-00.txt> AT&T Category: Informational E. Miller G. Russell CableLabs B. Beser M. Mannette K. Steinbrenner 3Com D. Oran Cisco J. Pickens Com21 P. Lalwaney J. Fellows General Instrument D. Evans Lucent Cable K. Kelly NetSpeak F. Andreasen Telcordia October, 1999 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." DCS Group Category Informational - Expiration 4/30/2000 1 SIP Proxy-to-Proxy Extensions November 1999 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 h ttp://www.ietf.org/shadow.htm l. The distribution of this memo is unlimited. It is filed as, and expires April 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 . 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 [3]. 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 [4] 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 DCS Group Category Informational - Expiration 4/30/00 2 SIP Proxy-to-Proxy Extensions November 1999 and authorized before receiving access to network resources and billable enhanced services. DCS-Proxies, as defined in [4], 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. 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. DCS Group Category Informational - Expiration 4/30/00 3 SIP Proxy-to-Proxy Extensions November 1999 The addition of two SIP General Header Fields allows for the capture of billing information and billing identification for the duration 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 [5]. 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 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 [4]. Gate = "Gate: [hostport "/"] Gate-ID DCS Group Category Informational - Expiration 4/30/00 4 SIP Proxy-to-Proxy Extensions November 1999 [";" Gate-Key ";" Gate-CipherSuite] 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. To semantically distinguish this form of phone number, the token user=phone is included, as in standard SIP. User = telephone-subscriber *("," dcs-user-param) | dcs-user-param *("," dcs-user-param) | *(unreserved | escaped | "&" | "=" | "+" | "$" | ",") telephone-subscriber = global-phone-number | local-phone-number | special-service-name dcs-user-param = lnp-param | private-param | other-param lnp-param = "lnp=" token private-param = "private=" token special-service-name = "return-call" | "call-trace" | "bridge" 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., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 DCS Group Category Informational - Expiration 4/30/00 5 SIP Proxy-to-Proxy Extensions November 1999 4 DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SOIP-based Distributed Call Control Mechanisms", draft-dcsgroup-sip-arch-01.txt, October 1999. 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 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, General Instruments; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, and Partho Mishra, AT&T. 9. Author's Addresses Bill Marshall AT&T Florham Park, NJ 07932 Email: wtm@research.att.co m K. K. Ramakrishnan AT&T Florham Park, NJ 07932 Email: kkrama@research.att.co m Ed Miller CableLabs Louisville, CO 80027 Email: E.Miller@Cablelabs.co m Glenn Russell CableLabs Louisville, CO 80027 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 DCS Group Category Informational - Expiration 4/30/00 6 SIP Proxy-to-Proxy Extensions November 1999 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 Dave Oran Cisco Acton, MA 01720 Email: oran@cisco.com John Pickens Com21 San Jose, CA Email: jpickens@com21.com Poornima Lalwaney General Instrument San Diego, CA 92121 Email: plalwaney@gi.com Jon Fellows General Instrument San Diego, CA 92121 Email: jfellows@gi.com Doc Evans Lucent Cable Communications Westminster, CO 30120 Email: n7dr@lucent.com Keith Kelly NetSpeak Boca Raton, FL 33587 Email: keith@netspeak.com Flemming Andreasen Telcordia Piscataway, NJ Email: fandreas@telcordia.com DCS Group Category Informational - Expiration 4/30/00 7 SIP Proxy-to-Proxy Extensions November 1999 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 , and expires April 30, 2000. DCS Group Category Informational - Expiration 4/30/00 8