Internet Engineering Task Force B. Campbell Internet-Draft dynamicsoft Expires: January 11, 2002 July 13, 2001 SIP Call Control - Framework draft-ietf-sip-cc-framework-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 11, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes that SIP call control features be added in a modular fashion, using an open-ended framework of extensions instead of a single extension. This memo proposes a modular design philosophy for call control extensions, and lists current work-in-progress call control related drafts. Campbell Expires January 11, 2002 [Page 1] Internet-Draft SIP Call Control - Framework July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes from Previous Version . . . . . . . . . . . . . . . . 3 3. Call Control Feature Examples . . . . . . . . . . . . . . . . 3 4. A Modular Approach . . . . . . . . . . . . . . . . . . . . . . 4 5. Call Control Extension Design Philosophy . . . . . . . . . . . 4 6. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 5 7. Adding New Call Control Operations . . . . . . . . . . . . . . 5 8. Call Control Documents . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 Campbell Expires January 11, 2002 [Page 2] Internet-Draft SIP Call Control - Framework July 2001 1. Introduction Most conventional telephony applications provide some level of support for modifying an in-progress call, or call control. Simple examples include call transfer and three way calling. More complex examples include conferencing and third party control. The baseline SIP protocol[1]provides some limited support for call control, in that a call-leg participant can terminate the call leg, put it on hold, or modify the characteristics of its media stream. However, many common call control applications require extensions to SIP in order to accomplish tasks such as referring a call to a new end point, or joining an existing call. This memo proposes a modular approach to call control extension. 2. Changes from Previous Version This revision has only minor changes from the previous version: Removed open item concerning usage of the term "attended transfer." Renamed file to reflect status as a SIP working group item. Added references to the Call Control Model draft.[3] Added a section listing Call Control drafts that are currently in process. Removed discussion of original SIP call control draft. Made minor editorial revisions to improve clarity. 3. Call Control Feature Examples The following examples are call features for which extensions are currently under development, or may require extensions in the near future. These are examples only, and should not be considered authoritative; a formal treatment of call control features and terminology can be found in [3]. Transfer with Consultation Hold - The transferring party establishes a session with the transfer target before completing the transfer (Currently proposed in [4]). Attended transfer - the transferring party establishes a session with the target and mixes both sessions together so that all three Campbell Expires January 11, 2002 [Page 3] Internet-Draft SIP Call Control - Framework July 2001 parties can participate, then disconnects leaving the transferee and transfer target with an active session. Conference Bridge - Callers join a conference on a centralized bridge. Fully meshed conference - Callers establish sessions with all other callers on the conference. Each client mixes media streams. Call Park - Call participant transfers a call to a call park, then retrieves it at a later time. Call Pick - A party picks up a call that was ringing at another station. Call Monitoring - A call center supervisor joins an in-progress call for monitoring purposes. These examples are not exhaustive; we expect that more call control feature requirements will be proposed as SIP usage matures. Therefore it is not possible for this document to enumerate all call control extensions in advance. 4. A Modular Approach We propose the SIP call control extensions be handled in a modular fashion. Instead of having a single unified call control extension, we should instead have a framework of extensions. Each of these extensions would focus on a bounded and coherent requirement (or extension) set. A framework approach allows SIP entities to negotiate feature support with more granularity. For example, an implementation could assert that it supports call transfer without implying that it also supports conferencing. 5. Call Control Extension Design Philosophy Each call control extension should address a coherent group of requirements that are most likely to be needed as a set. If implementers find themselves having to add features that would not normally be required by their application just because they are defined by the extension, it is probably to big. The negotiated support of one call control extension MUST not imply the support of other extensions. While multiple extensions MAY share extended methods or headers, they MUST NOT do so unless the semantics are identical for all extensions. Campbell Expires January 11, 2002 [Page 4] Internet-Draft SIP Call Control - Framework July 2001 Call Control extension designers SHOULD NOT overload existing methods and headers, unless the new function is actually a logical extension of the method or header in question. Overloaded headers and extension create complications for protocol implementations. For example, if an extension overloads INVITE by adding a new header, the implementation must check every INVITE for the presence of the header before taking action. If the implementation supports many extensions that each overload INVITE, the decision logic becomes complex. Subject to the limitation on overloading methods and headers, extensions should be as simple as possible and reuse existing SIP related features whenever appropriate. 6. Extension Negotiation Since call control actions could conceivably be initiated by any user agent, SIP entities MUST follow the guidelines concerning feature negotiation described in the draft,"Guidelines for the Authors of SIP Extensions"[2]. If a SIP entity receives a message containing a call control extension method or header that normally requires negotiation but has not been properly negotiated, it SHOULD behave as if it had no knowledge of the extension in question, regardless of whether the entity is capable of supporting it. It is tempting to suggest that if an entity recognized an un-negotiated extension, it should go ahead and act on it. However, it is dangerous for an entity to assume it understands the intent behind an extension without explicit negotiation. If two extensions were to use the same keyword for an extended feature with different semantics, the receiving entity would have no way to guess the intent of the sending entity. 7. Adding New Call Control Operations Additional call control operations SHOULD be implemented as additional SIP extension methods. Each such extension method MUST progress through the standards process as per other IETF standards. Such extensions SHOULD include motivations, requirements, specification of syntax and semantics, and detailed usage examples. Additionally, it SHOULD describe how to specifically apply the negotiation guidelines in [2]. Campbell Expires January 11, 2002 [Page 5] Internet-Draft SIP Call Control - Framework July 2001 8. Call Control Documents Work is in progress on the following documents which fit into this framework: "SIP Call Control - Model"[3] "SIP Call Control - Transfer"[4] 9. Security Considerations Each call control extension SHOULD describe mechanisms to prevent unauthorized parties to invoke the extensions. Any extension that allows entities not party to a call to invoke call control operations MUST describe said mechanisms. 10. Acknowledgments The author thanks the following for their contribution to this work: Chris Cunningham, Steve Donovan, Alan Johnston, Robert Sparks, Kevin Summers, Dean Willis, and Rohan Mahy. References [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: session initiation protocol", RFC 2543, March 1999. [2] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions", draft-ietf-sip-guidelines-01.txt (work in progress), March 2000. [3] Mahy, R. , "SIP Call Control Model", draft-mahy-sip-cc-models-00.txt (work in progress), March 2001. [4] Sparks, R., "SIP Call Control - Transfer", draft-sip-cc-transfer-04.txt (work in progress), February 2001. Author's Address Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 email: bcampbell@dynamicsoft.com Campbell Expires January 11, 2002 [Page 6] Internet-Draft SIP Call Control - Framework July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 implementation 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Campbell Expires January 11, 2002 [Page 7]