[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-sip-cc-framework

Internet Engineering Task Force                              B. Campbell
Internet-Draft                                               dynamicsoft
Expires: August 30, 2001                                   March 1, 2001


                      SIP Call Control - Framework
                   draft-campbell-sip-cc-framework-02

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 August 30, 2001.

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 August 30, 2001                 [Page 1]


Internet-Draft        SIP Call Control - Framework            March 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 . . . . . . . . . . . . . . . . . . . .  5
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  6
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7



































Campbell                Expires August 30, 2001                 [Page 2]


Internet-Draft        SIP Call Control - Framework            March 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:

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


Campbell                Expires August 30, 2001                 [Page 3]


Internet-Draft        SIP Call Control - Framework            March 2001


   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.

   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


Campbell                Expires August 30, 2001                 [Page 4]


Internet-Draft        SIP Call Control - Framework            March 2001


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

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]


Campbell                Expires August 30, 2001                 [Page 5]


Internet-Draft        SIP Call Control - Framework            March 2001


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

   There is some confusion on the distinction between a "transfer with
   consultation hold" and an "attended transfer". This document
   describes the latter as including a phase in which all three callers
   are conferenced before the transferor leaves the call, while the
   former does not include the conference phase.

11. 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 August 30, 2001                 [Page 6]


Internet-Draft        SIP Call Control - Framework            March 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 August 30, 2001                 [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/