MMUSIC Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-mmusic-state-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 June, 1999 SIP 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 Internet Draft - Expiration 12/31/99 1 SIP Extensions for Distributed Call State June 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 http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as <draft- dcsgroup-mmusic-state-00.txt>, and expires December 31, 1999. Please send comments to the authors. 1. Abstract This document describes extensions to the Session Initiation Protocol RFC(2543) for supporting telephony services using the Distributed Call Signaling architecture described in [2]. This document discusses extensions to the host parameter in the SIP URL for supporting the following: (a) a call signaling architecture where call state is distributed to the clients during call setup and stored there for the duration of the call, (b) support for local number portability and (c) relaxation of the strong coupling between the phone number and its gateway in the telephony subscriber URL as defined in RFC 2543. Additional headers in SIP messages for passing call state information between the clients and their proxies, and support for PSTN-based operator services are also discussed in this document. In addition, the need for the Also and Replaces headers (previously discussed in [3]) are mentioned here. 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 [4]. 3. Introduction The Distributed call signaling (DCS) architecture provides signaling support for creating a session using a two-phase signaling scheme so that call state is distributed to the clients and network resources reserved prior to alerting the called party. The SIP proxy server in the DCS architecture is referred to as a DCS-Proxy. The SIP user agent is referred to as a client (or an MTA - "Multimedia terminal adapter"). From a call signaling perspective, the DCS Proxies are involved in setting up a call. All requests from clients that affect the characteristic of a call are sent to the DCS-Proxy. During a successful call setup, call state and the associated billing information is encrypted by the proxies and sent to the clients using the proposed "State" header in the initial INVITE to the DCS Group Internet Draft - Expiration 12/31/99 2 SIP Extensions for Distributed Call State June 1999 terminating MTA (called client) and in the 200 OK to the originating MTA (calling client). The DCS-Proxy in effect, transfers call state to the clients and other network entities during the call-setup phase and then remains stateless for the duration of the call. If the client wishes to change call characteristics (e.g. invoke calling features like forwarding, call transfer etc.), it passes the encrypted state information in the SIP INVITE request to its proxy server. We propose the addition of a host parameter value of "private" and a user-param value of "private" to the SIP-URL for supporting this capability. The presence of user-param = "private" indicates that the contents of the host field can only be interpreted by the DCS-Proxy. The client initiating the call is responsible for "collecting the digits" that represents the destination telephony URL. The DCS-Proxy is responsible for resolving the dialed digits to the IP address of the destination. The client initiating the call may not know of the gateway associated with the destination. When "user=phone" is present, we propose that the SIP host URL for the telephony subscribe permit the use of a valid E.164 number as a URL and relax the requirement on the need to add the gateway associated with the number. Support for local number portability functions requires another extension to the telephony subscriber URL. We propose the addition of an "augmented-phone-number" in the definition of the telephony subscriber URL and the addition of user-param = "lnp-phone" for supporting local number portability. The OSPS header is proposed for supporting PSTN based operator services of "Busy-Line-Verify" and "Emergency Interrupt". The response of the client (in an active call) to a SIP INVITE that includes this header is not to return busy to the PSTN media gateway (and thereby the operator) that initiated this request. The Distributed Call Signaling Architecture uses the Also and Replaces headers for implementing call transfers. The addition of parties referenced in the Also header and the removal of parties referenced in the Replaces header are used for implementing services that require the addition and removal of call-legs to an existing call. 4. SIP Extensions In this section, we propose the SIP extensions to address the issues identified in the Introduction. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [5]. DCS Group Internet Draft - Expiration 12/31/99 3 SIP Extensions for Distributed Call State June 1999 4.1 SIP URL Extensions The SIP URL host syntax is extended to allow hosts to be identified by a simple phone-number (E.164 number). The SIP client initiating the call may not know of the gateway associated with the number. The Telephony subscriber URL definition in RFC 2543 for a telephone number requires the phone number and its gateway association in the host parameter. We propose that this constraint be relaxed to allow hosts to be identified by their E.164 numbers only. If this interpretation of the hostname is used, the associated user-param user=phone MUST be present. Support for local number portability motivates the need for an "augmented phone number" field in the telephony-subscriber URL. The augmented phone number would be a number returned by a location service for local number portability. The user-param field when the augmented phone number is the lnp-phone number MUST include user=lnp-phone. All information about the parties in the call and associated billing information is encrypted by the DCS-Proxy during call setup and stored in the clients participating in the call. To invoke features that involve change in call characteristics that affects the current call leg or its billing information, the SIP client sends an INVITE to its proxy that may include an encrypted string as the SIP URL host field represented as "private" with the associated user-param being "private". This user-param indicates that the DCS-Proxy associated with the client is the only entity that can decrypt the "private" information in the host field. The field is to be interpreted as an opaque object by the clients. The representation for the host parameter desired to support the DCS architecture is shown below: host = hostname | IPv4address | telephone-subscriber | private telephone-subscriber = global-phone-number | local-phone-number | augmented-phone-number augmented-phone-number = 1*( phone-digit | dtmf-digit | pause-character | "/") private = alpha *alphanum The SIP user-param is extended to include "private" and "lnp-phone" keywords as described below. user-param = "user=" ( "ip" | "phone" | "lnp-phone" | "private" ) DCS Group Internet Draft - Expiration 12/31/99 4 SIP Extensions for Distributed Call State June 1999 The user-param "user=ip" is optional in a URL and MAY be included when the host is identified using hostname or the IPv4address syntax. Therefore, the URL "sip: John Doe" is equivalent to the URL "sip:John Doe;user=ip". When a URL includes the user-param "user=phone", the URL host field MUST be a phone number and MUST use the telephone-subscriber syntax. Additionally, when a URL includes the user-parameter "user=phone", the userinfo field MAY NOT be present. An example of a valid URL containing the user-param "user=phone" is: sip:847.555.1212;user=phone When a URL includes the user-param "user=lnp-phone", the SIP URL host field MUST use the augmented-phone-number syntax, and contain the local office code prepended to the phone number with a slash separator. Additionally, when a URL includes the user-parameter "user=lnp-phone", the SIP URL userinfo MUST NOT be present. An example of a URL containing the user-param "user=lnp-phone" is: sip:212-234/847-555-1212;user=lnp-phone When a URL includes the user-param "user=private", the SIP URL host field MUST be a string encrypted using the DCS-Proxy's private key. Additionally, the encrypted string MUST use private URL syntax. When a URL includes the user-parameter "user=private", the SIP URL "userinfo" MUST NOT be present. 4.2 State The State header conveys encrypted state information from a DCS- Proxy to a DCS capable client. This state information allows the DCS-Proxy to securely store state information in the client that may be needed for subsequent feature invocation, allowing the DCS-Proxy to remain stateless during the call. State = "State" ":" private The keyword "private" is defined in Section 4.1. The State header is sent to the terminating MTA in the initial SIP INVITE from its proxy. The State header is sent to the originating MTA (from its proxy) in the 200 OK response to the initial INVITE. 4.3 OSPS Operator services support for Busy line verification (BLV) and Emergency interrupt(EI) services initiated by an operator on the PSTN network motivates the need for the OSPS header. This header is DCS Group Internet Draft - Expiration 12/31/99 5 SIP Extensions for Distributed Call State June 1999 intended to be used in SIP INVITE messages from the PSTN gateway to the client being queried or interrupted. The tag values permitted in this header are "BLV" for busy line verification and "EI" for emergency interrupt. OSPS = "OSPS" ":" OSPS-Tag OSPS-Tag = "BLV" | "EI" The response of the client to an INVITE with this header is not to return busy. 4.4 Also The Also header is required for adding new participants to an existing call. Its functionality was originally described in the expired SIP Call Control Services draft [3]. It is discussed here for completeness and is required to realize many services in the DCS architecture. The Also header advises the recipient to issue INVITE requests to the addresses listed in the header. Also = "Also" ":" SIP-URL *[ "," SIP-URL] The URL extensions discussed in Section 4.1 are permitted in the Also header. If a client receives an INVITE with an Also header that includes a URL tagged with user=private, it SHOULD send the INVITE for the new call-leg to its DCS-Proxy with the Request-URI copied from the Also header of the received INVITE request. 4.5 Replaces The Replaces header is required for removing participants from an existing call. Its functionality was originally described in the expired SIP Call Control Services draft [3]. It is discussed here for completeness and is required to realize many services in the DCS architecture. The Replaces extension asks the recipient to issue a BYE to the addresses listed. Replaces = "Replaces" ":" SIP-URL *[ "," SIP-URL] As with the Also header, the URL extensions discussed in Section 4.1 are permitted in the Replaces header. 5. Security Considerations The clients (Multimedia Terminal Adapters) are untrusted entities in the DCS architecture. The contents of all headers tagged as "private" are verified by DCS-Proxies. DCS-Proxies are responsible DCS Group Internet Draft - Expiration 12/31/99 6 SIP Extensions for Distributed Call State June 1999 for verifying the contents and consistency of the headers and extended URL's discussed in this document. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 DCS Group, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", draft-dcsgroup-mmusic-arch-00.txt, June 1999. 3 Schulzrinne, H and Rosenberg, J, SIP Call Control Services, draft-ietf-mmmusic-sip-cc-00.txt, March 1998, expired August 1, 1998. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 7. 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 Guckle, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, and Partho Mishra, AT&T. 8. 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 DCS Group Internet Draft - Expiration 12/31/99 7 SIP Extensions for Distributed Call State June 1999 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 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 Kelley Netspeak Boca Raton, FL 33587 DCS Group Internet Draft - Expiration 12/31/99 8 SIP Extensions for Distributed Call State June 1999 Email: keith@netspeak.com Flemming Andreasen Telcordia Piscataway, NJ Email: fandreas@telcordia.com DCS Group Internet Draft - Expiration 12/31/99 9 SIP Extensions for Distributed Call State June 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 <draft-dcsgroup-mmmusic-state- 00.txt>, and expires December 31, 1999. DCS Group Internet Draft - Expiration 12/31/99 10