idnits 2.17.1 draft-dcsgroup-mmusic-proxy-proxy-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 357 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 6) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 43 looks like a reference -- Missing reference section? '2' on line 81 looks like a reference -- Missing reference section? '3' on line 212 looks like a reference -- Missing reference section? '4' on line 171 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group W. Marshall 2 Internet Draft K. Ramakrishnan 3 Document: AT&T 5 Category: Informational 6 E. Miller 7 G. Russell 8 CableLabs 10 B. Beser 11 M. Mannette 12 K. Steinbrenner 13 3Com 15 D. Oran 16 Cisco 18 J. Pickens 19 Com21 21 P. Lalwaney 22 J. Fellows 23 General Instrument 25 D. Evans 26 Lucent Cable 28 K. Kelly 29 NetSpeak 31 F. Andreasen 32 Telcordia 34 June, 1999 36 SIP proxy-to-proxy extensions for supporting Distributed Call State 38 Status of this Memo 40 This document is an Internet-Draft and is NOT offered in accordance 41 with Section 10 of RFC2026[1], and the author does not provide the 42 IETF with any rights other than to publish as an Internet-Draft. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. Internet-Drafts are draft documents valid for a maximum of 48 six months and may be updated, replaced, or obsoleted by other 49 documents at any time. It is inappropriate to use Internet- Drafts 50 as reference material or to cite them other than as "work in 51 progress." 53 DCS Group Category Informational - Expiration 12/31/99 1 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 The distribution of this memo is unlimited. It is filed as , and expires December 31, 1999. 62 Please send comments to the authors. 64 1. Abstract 66 In order to deploy a residential telephone service at very large 67 scale across different domains, it is necessary for trusted elements 68 owned by different service providers to exchange trusted information 69 that conveys customer-specific information and expectations about 70 the parties involved in the call. This document describes extensions 71 to the Session Initiation Protocol (RFC2543) for supporting the 72 exchange of customer information and billing information between 73 trusted entities in the architecture described in . 76 2. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC-2119 [2]. 82 3. Introduction 84 In order to deploy a residential telephone service at very large 85 scale across different domains, it is necessary for trusted elements 86 owned by different service providers to exchange trusted information 87 that conveys billing information and expectations about the parties 88 involved in the call. 90 There are many billing models used in deriving revenue from 91 telephony services today. Charging for telephony services is tightly 92 coupled to the use of network resources. It is outside the scope of 93 this document to discuss the details of these numerous and varying 94 methods. 96 A key motivating principle of the DCS architecture described in [3] 97 is the need for network service providers to be able to control and 98 monitor network resources; revenue may be derived from the usage of 99 these resources as well as from the delivery of enhanced services 100 such as telephony. Furthermore, the DCS architecture recognizes the 101 need for coordination between call signaling and resource 102 management. This coordination ensures that users are authenticated 104 DCS Group Category Informational - Expiration 12/31/99 2 105 and authorized before receiving access to network resources and 106 billable enhanced services. 108 DCS-Proxies, as defined in [3], have access to subscriber 109 information and act as policy decision points and trusted 110 intermediaries along the call signaling path. Edge routers provide 111 the policy enforcement mechanism and also capture and report usage 112 information. Edge routers need to be given billing information that 113 can be logged with Record Keeping or Billing servers. The DCS 114 Proxy, as a central point of coordination between call signaling and 115 resource management, can provide this information based on the 116 authenticated identity of the calling and called parties. Since 117 there is a trust relationship among DCS Proxies, they can be relied 118 upon to exchange trusted billing information pertaining to the 119 parties involved in a call. 121 For these reasons, it is appropriate to consider defining SIP header 122 extensions to allow DCS Proxies to exchange information during call 123 setup. It is the intent that the extensions would only appear on 124 trusted network segments, should be inserted upon entering a trusted 125 network region, and removed before leaving trusted network segments. 127 4. Justification for proxy-to-proxy information 129 Significant amounts of information is retrieved by an originating 130 proxy in its handling of a connection setup request from a user 131 agent. Such information includes location information about the 132 subscriber (essential for emergency services calls), billing 133 information, and station information (e.g. coin operated phone). In 134 addition, while translating the destination number, information such 135 as the local-number-portability office code is obtained and will be 136 needed by all other proxies handling this call. 138 For Usage Accounting records, it is necessary to have an identifier 139 that can be associated with all the event records produced for the 140 call. Call-ID cannot be used as such an identifier since it is 141 selected by the originating user agent, and may not be unique among 142 all past calls as well as current calls. Further, since this 143 identifier is to be used by the service provider, it should be 144 chosen in a manner and in a format that meets the service provider's 145 needs. 147 Billing information may not necessarily be unique for each user 148 (consider the case of calls from an office all billed to the same 149 account). Billing information may not necessarily be identical for 150 all calls made by a single user (consider prepaid calls, credit card 151 calls, collect calls, etc). It is therefore necessary to carry 152 billing information separate from the calling and called party 153 identification. Furthermore, some billing models call for split- 154 charging where multiple entities are billed for portions of the 155 call. 157 DCS Group Category Informational - Expiration 12/31/99 3 158 The addition of two SIP General Header Fields allows for the capture 159 of billing information and billing identification for the duration 160 of the call. Alternative techniques such as multi-part attachments 161 will not coexist with encrypted messages. 163 It is the intent that the billing extensions would only appear on 164 trusted network segments, and MAY be inserted by a DCS Proxy in 165 INVITE requests entering a trusted network segment, and MUST be 166 removed before leaving trusted network segments. 168 5. Formal Syntax 170 The following syntax specification uses the augmented Backus-Naur 171 Form (BNF) as described in RFC-2234 [4]. 173 The proposed additional headers are: 175 BILLING-INFO 177 The Billing-info general header identifies a subscriber account 178 number of the payer, and other information necessary for accurate 179 billing of the service. This header MUST only used between Proxies. 181 Billing-Info = "Billing-Info:" hostport ["/" Key ] 182 "<" Acct-Data ">" 184 Key = 1*alphanum 186 Acct-Data = 1*unreserved 187 | (1*unreserved "," Acct-Data) 189 The hostport specifies a record keeping server, and the Key is the 190 security key needed to send event records to that server. Acct-Data 191 is arbitrary format data understood only by the record keeping 192 server. 194 BILLING-ID 196 The Billing-ID general header contains an identifier that can be 197 used by an event recorder to associate multiple usage records, 198 possibly from different sources, with a billable account. This 199 header MUST only be used between Proxies. 201 Billing-ID = "Billing-ID" ":" 1*unreserved 203 A proposed implementation of billing ID is a string made up of DCS 204 IP address, timestamp, and sequence number. 206 GATE-LOCATION 208 DCS Group Category Informational - Expiration 12/31/99 4 209 The Gate-Location general header contains the location and 210 identifier of a Gate associated with the IP flow for this call. 211 This information is needed for gate coordination, as described in 212 [3]. 214 Gate-Location = "Gate-Location:" hostport "/" GateID 215 ["/" Gate-Key ] 217 GateID = 1*alphanum 219 Gate-Key = 1*alphanum 221 REQUEST-URI 223 The Request-URI is extended to allow a phone number to contain 224 augmented information, which may include the local-number- 225 portability office code. To semantically distinguish this form of 226 phone number, a new token user=lnp-phone is defined. This form of 227 Request URI MUST only be used between DCS-Proxies. 229 Telephone-subscriber = global-phone-number 230 | local-phone-number 231 | augmented-phone-number 232 augmented-phone-number = 1*(phone-digit | dtmf-digit 233 | pause-character | "/") 234 user-param = "user=" ("phone" | "ip" | "lnp-phone") 236 6. Security Considerations 238 The general headers and request URI extensions described in this 239 draft MUST only be used between proxies, and MUST never be given to 240 a user agent. 242 Billing information is often considered sensitive and private 243 information to the customers. It is therefore necessary that the 244 Proxies take precautions to protect this information from 245 eavesdropping and interception. Use of IPSec between Proxies is 246 recommended. 248 7. References 250 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 251 9, RFC 2026, October 1996. 253 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 254 Levels", BCP 14, RFC 2119, March 1997 256 3 DCS Group, "Architectural Considerations for Providing Carrier 257 Class Telephony Services Utilizing SIP-based Distributed Call 259 DCS Group Category Informational - Expiration 12/31/99 5 260 Control Mechanisms", draft-dcsgroup-mmusic-arch-00.txt, June 261 1999. 263 4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 264 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 265 Demon Internet Ltd., November 1997 267 8. 268 Acknowledgments 270 The Distributed Call Signaling work in the PacketCable project is 271 the work of a large number of people, representing many different 272 companies. The authors would like to recognize and thank the 273 following for their assistance: John Wheeler, Motorola; David 274 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 275 Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug 276 Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay 277 Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckle, Cisco; 278 and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, and Partho 279 Mishra, AT&T. 281 9. Author's Addresses 283 Bill Marshall 284 AT&T 285 Florham Park, NJ 07932 286 Email: wtm@research.att.com 288 K. K. Ramakrishnan 289 AT&T 290 Florham Park, NJ 07932 291 Email: kkrama@research.att.com 293 Ed Miller 294 CableLabs 295 Louisville, CO 80027 296 Email: E.Miller@Cablelabs.com 298 Glenn Russell 299 CableLabs 300 Louisville, CO 80027 301 Email: G.Russell@Cablelabs.com 303 Burcak Beser 304 3Com 305 Rolling Meadows, IL 60008 306 Email: Burcak_Beser@3com.com 308 DCS Group Category Informational - Expiration 12/31/99 6 309 Mike Mannette 310 3Com 311 Rolling Meadows, IL 60008 312 Email: Michael_Mannette@3com.com 314 Kurt Steinbrenner 315 3Com 316 Rolling Meadows, IL 60008 317 Email: Kurt_Steinbrenner@3com.com 319 Dave Oran 320 Cisco 321 Acton, MA 01720 322 Email: oran@cisco.com 324 John Pickens 325 Com21 326 San Jose, CA 327 Email: jpickens@com21.com 329 Poornima Lalwaney 330 General Instrument 331 San Diego, CA 92121 332 Email: plalwaney@gi.com 334 Jon Fellows 335 General Instrument 336 San Diego, CA 92121 337 Email: jfellows@gi.com 339 Doc Evans 340 Lucent Cable Communications 341 Westminster, CO 30120 342 Email: n7dr@lucent.com 344 Keith Kelly 345 NetSpeak 346 Boca Raton, FL 33587 347 Email: keith@netspeak.com 349 Flemming Andreasen 350 Telcordia 351 Piscataway, NJ 352 Email: fandreas@telcordia.com 354 DCS Group Category Informational - Expiration 12/31/99 7 355 Full Copyright Statement 357 "Copyright (C) The Internet Society (1999). All Rights Reserved. 358 This document and translations of it may be copied and furnished to 359 others, and derivative works that comment on or otherwise explain it 360 or assist in its implmentation may be prepared, copied, published 361 and distributed, in whole or in part, without restriction of any 362 kind, provided that the above copyright notice and this paragraph 363 are included on all such copies and derivative works. However, this 364 document itself may not be modified in any way, such as by removing 365 the copyright notice or references to the Internet Society or other 366 Internet organizations, except as needed for the purpose of 367 developing Internet standards in which case the procedures for 368 copyrights defined in the Internet Standards process must be 369 followed, or as required to translate it into languages other than 370 English. The limited permissions granted above are perpetual and 371 will not be revoked by the Internet Society or its successors or 372 assigns. This document and the information contained herein is 373 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 374 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 375 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 379 Expiration Date This memo is filed as , and expires December 31, 1999. 382 DCS Group Category Informational - Expiration 12/31/99 8