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