One document matched: draft-campbell-sip-cc-framework-00.txt

Internet Engineering Task Force                           Ben Campbell
Internet Draft                                            MCI WorldCom
draft-campbell-sip-cc-framework-00.txt
March 6, 2000
Expires September 2000


               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 ...................................................5
10. Acknowledgements .................................................5
11. References .......................................................5


Ben Campbell                                                  [Page 1]

Internet Draft  draft-campbell-sip-cc-framework-00.txt   March 6, 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-00.txt   March 6, 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.

   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-00.txt   March 6, 2000


5.  Extension Negotiation

   Since call control actions could conceivably be initiated by any
   user agent, SIP entities MUST use the approach described in the
   draft, "Mandating SIP Extension Support by Servers" [3] and in the
   base protocol [1] to declare supported and required features.

   If a SIP entity receives a message containing a call control
   extension method or header that 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 methods in [3] and [1] specifically apply.

7.  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.

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?

   Is the framework an extension in itself? That is, should it have its
   own option tag, and should all implementations of any call control
   extension also include the framework tag? Or should each call
   control extension stand alone with no hierarchy?



Ben Campbell                                                  [Page 4]

Internet Draft  draft-campbell-sip-cc-framework-00.txt   March 6, 2000


9.  Author's Address

     Ben Campbell
     MCI Worldcom
     2400 N. Glenville Dr.           Phone: +1 972 729 6131
     Richardson, TX 75082            Email: ben.campbell@wcom.com

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, "Mandating SIP Extension
   Support by Servers," Internet Draft, Internet Engineering Task
   Force, Jan. 2000. Work in progress.

   [4] R. Sparks, "Call Transfer," Internet Draft, Internet Engineering
   Task Force, Mar. 2000. Work in progress.

























Ben Campbell                                                  [Page 5]