Internet Engineering Task Force Ben Campbell Internet Draft dynamicsoft draft-campbell-sip-cc-framework-01.txt July 4, 2000 Expires February 2001 Framework for SIP Call Control Extensions 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 made obsolete 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 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. These extensions should be advertised and requested following previously defined negotiation techniques. The document continues to describe preferred call control extension design philosophy. Table of Contents 1. Introduction.......................................................2 2. Call Control Feature Examples......................................2 3. A Modular Approach.................................................3 4. Call Control Extension Design Philosophy...........................3 5. Extension Negotiation..............................................4 6. Adding New Call Control Operations.................................4 7. Security Considerations............................................4 8. Open Issues........................................................4 9. Author's Address...................................................4 10. Acknowledgements.................................................5 11. References.......................................................5 Ben Campbell [Page 1] Internet Draft draft-campbell-sip-cc-framework-01.txt July 4, 2000 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. Schulzrinne and Rosenberg published the SIP Call Control Services [2] draft, which describes an approach to providing many of these services in a unified way. However, implementation support has so far been very limited. The author asserts that the attempt to unify call control is the very reason that it has been rarely implemented. Many application environments will have very different and sometimes contradictory requirements for call control behavior. While we can predict many possible call control applications, the set of all such applications is unbounded. There is no way to predict all possible requirements in advance. Additionally, implementers who wish to provide only simple call control features should not be burdened by the requirements of more complex applications. 2. Call Control Feature Examples The following examples are call features that may require extensions in the near future: Unattended-Transfer - A call participant transfers the call and disconnects without establishing a session with the transfer target (Currently proposed in "Call Transfer" draft [4]). Transfer with Consultation Hold - The transferring party establishes a session with the transfer target before completing the transfer (Currently proposed in "Call Transfer" draft [4]). Attended transfer - the transferring party establishes a session with the target and mixes both sessions together so that all three 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. Ben Campbell [Page 2] Internet Draft draft-campbell-sip-cc-framework-01.txt July 4, 2000 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. This may also be required for certain operator functions. 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. 3. 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. 4. 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. 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. Ben Campbell [Page 3] Internet Draft draft-campbell-sip-cc-framework-01.txt July 4, 2000 5. 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" [3]. 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. 6. 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. In addition, the extensions MUST define extension option tags as described in [3]. Additionally, it SHOULD describe how the negotiation guidelines in [3] specifically apply. 7. Security Considerations Each call control extension SHOULD describe mechanisms to prevent unauthorized parties from invoking the extensions. Any extension that allows entities not party to a call to invoke call control operations MUST describe said mechanisms. 8. Open Issues Is the proscription against acting on extensions without explicit negotiation acceptable? Would it be better for an entity to attempt to guess the intent of the sender if it receives a message with extended features that have not been explicitly negotiated? 9. Author's Address Ben Campbell dynamicsoft 72 Eagle Rock Avenue Phone: +1 972 768 9229 East Hanover, NJ 07936-3151 Email: bcampbell@dynamicsoft.com Ben Campbell [Page 4] Internet Draft draft-campbell-sip-cc-framework-01.txt July 4, 2000 10. Acknowledgements The author thanks the following for their contribution to this work: Chris Cunningham, Steve Donovan, Alan Johnston, Robert Sparks, Kevin Summers and Dean Willis. 11. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [2] H. Schulzrinne and J. Rosenberg, "SIP call control services," Internet Draft, Internet Engineering Task Force, Jun. 1999. Work in progress (expired Dec. 1999). [3] J. Rosenberg and H. Schulzrinne, "Guidelines for Authors of SIP Extensions," Internet Draft, Internet Engineering Task Force, March 10, 2000. Work in progress. [4] R. Sparks, "Call Transfer," Internet Draft, Internet Engineering Task Force, July 2000. Work in progress. Ben Campbell [Page 5]