SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-sip-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 October, 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 04/30/00 1 SIP Extensions for Distributed Call State October 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-sip-state-01.txt>, and expires April 30, 2000. 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 the semantics associated with the user parameter in the SIP URL for supporting a call signaling architecture where call state is distributed to the clients during call setup and stored there for the duration of the call while the proxy server remains stateless. 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 endpoint. 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. This is sent in the initial INVITE to the "called" client (and in the 200 OK to the "calling" client/caller. The DCS-Proxy in effect, transfers call state to the DCS Group Internet Draft - Expiration 04/30/00 2 SIP Extensions for Distributed Call State October 1999 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 use of the "private=" token in the user field of the SIP URL to indicates that "token" can only be interpreted by the DCS-Proxy. The semantics of the telephony subscriber URL and associated user-param values to support number identification and portability are discussed in Section 4.1. The OSPS (Operator Services Provisioning System) 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]. 4.1 SIP URL Extensions The distributed call signaling protocol defines the semantics of the user field of the SIP-URL and refers to such as a DCS-URL. These URLs MUST be in accordance with SIP version 2 section 2, Figure 2 of RFC-2543. The DCS protocol defines the SIP-URL 'user' syntax to allow endpoints to be identified by an encrypted string that may be decrypted only by the DCS proxy. This allows end-point address information and billing information to be encrypted, stored in client devices, then later delivered to a trusted DCS proxy in support of CLASS features such as 3-way-calling, call-trace and return-call. Additionally, the DCS protocol defines the SIP-URL DCS Group Internet Draft - Expiration 04/30/00 3 SIP Extensions for Distributed Call State October 1999 'user' syntax to allow endpoints to be identified by phone numbers augmented with additional parameters. This allows DCS proxies to support local number portability (LNP) location services. The user syntax for a DCS-URL in BNF is shown below. 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" A standard SIP parser will accept this definition as a valid username. The user-param "user=ip" is optional and may be included when the destination is identified using hostname or IPv4address syntax. Therefore, the DCS-URL "sip: John Doe" is equivalent to DCS-URL "sip:John Doe;user=ip". When a DCS-URL includes the user-param "user=phone", the user field MUST contain an ITU recommendation E.164 phone number and MUST use DCS-URL telephone-subscriber syntax. An example of a valid DCS-URL containing the user-param "user=phone" is: sip:212.555.1212@dcs-proxy.provider;user=phone When a DCS-URL includes the lnp-param, the user field MUST contain an ITU recommendation E.164 phone number, and user-param MUST include user=phone. An example of a DCS-URL containing the lnp- param is: sip:212-555-1212,lnp=212-234@dcsproxy.provider;user=phone When a DCS-URL includes the private-param, the token in the private- param MUST be a string encrypted by the DCS Proxy using its private key. An example of a DCS-URL containing the private-param is: sip: return-call,private=x419d2b70a3@dcsproxy.provider DCS Group Internet Draft - Expiration 04/30/00 4 SIP Extensions for Distributed Call State October 1999 4.2 State The State extension conveys encrypted state information between a Proxy and a client. This state information allows the Proxy to reliably and securely store state information in the client that may be needed for subsequent feature invocation, allowing the Proxy to remain stateless. State = "State" ":" token The State field is an alphanumeric (starting with alphabetic only) string that is syntactically identical to a token. It is an encoding of an encrypted structure containing multiple pieces of information needed by the proxy to perform various mid-call features. The encrypted structure is returned from the client to the Proxy for various call services, such as return-call, call- trace, call-forwarding-no-answer, etc. The State field typically includes but is not limited to the following information: the calling and called party address information, the indication of privacy requested, optional billing information, sequence of via's and calling party id, for support of call-trace and return-call. This information is encrypted and signed by the proxy. The State header field discussed in this section should not be confused with HTTP1.1 Cookies as described in [6]. The intended use of the two is very different. HTTP uses the Cookie for "state" management, or as a handle to pass session context change from server to client where the server is the other endpoint of the session. On the otherhand, the State header is sent by the SIP proxy to the client so that call state can be securely stored at the endpoint making the associated proxy "stateless" during the call. The state header can be considered to be a handle to request session change by the endpoint from its proxy. In addition, there are no attribute value pairs associated with the state header as in the Cookie that clients make use of. 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 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 DCS Group Internet Draft - Expiration 04/30/00 5 SIP Extensions for Distributed Call State October 1999 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 is described in the 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 private=<string>, 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 are untrusted entities in the DCS architecture. The contents of all headers tagged as "private" are verified by DCS- Proxies. DCS-Proxies are responsible for verifying the contents and consistency of the headers and extended URL's discussed in this document. 6. References DCS Group Internet Draft - Expiration 04/30/00 6 SIP Extensions for Distributed Call State October 1999 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-sip-arch-01.txt, October 1999. 3 Schulzrinne, H and Rosenberg, J, SIP Call Control Services, draft-ietf-mmusic-sip-cc-01.txt, June 1999, expires December 1999. 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 6 K r i s t ol, D. and Montulli, L. ," HTTP State Management Mechanism", RFC 2109, February 1997.See current working draft <draft-ietf-http-state-man-mec-12.txt > modified by the same authors based on field implementation feedback. 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 Guckel, Michael Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, 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 04/30/00 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 Kelly NetSpeak DCS Group Internet Draft - Expiration 04/30/00 8 SIP Extensions for Distributed Call State June 1999 Boca Raton, FL 33587 Email: keith@netspeak.com Flemming Andreasen Telcordia Piscataway, NJ Email: fandreas@telcordia.com DCS Group Internet Draft - Expiration 04/30/00 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-sip-state- 01.txt>, and expires April 30, 2000. DCS Group Internet Draft - Expiration 04/30/00 10