SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: 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 , 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 . 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 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 . 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 , and expires September 30, 2000. DCS Group Category Informational - Expiration 9/30/00 8