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

Versions: 00 01

                                                                R. Mahy
Internet Draft                                            Cisco Systems
Document: draft-mahy-sip-cc-models-00.txt                      Jul 2001
Expires: Jan, 2002


                      A Call Control Model for SIP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026 [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.


1. Abstract

   This document defines an abstract call model for describing the
   media relationships required for call control features in SIP, and
   discusses other issues related to SIP call control as part of the
   SIP Call Control Framework.


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



3. Overview

   This document defines an abstract call model for describing the
   changes in media relationships (actions) which are needed to fulfill
   most call control features in SIP.  The call model is an integral
   part of the SIP Call Control Framework defined in [cc-framework].
   The model and actions described here are specifically chosen to be
   independent the SIP signaling and/or mixing approach chosen to
   actually setup the media relationships.
 Mahy                     Expires: Jan 2002                         1

                      Call Control Model for SIP



   Implementations may setup the media relationships described in this
   model using the approach described in [3pcc]. The 3pcc approach
   relies on only the following 3 primitive operations:

        new INVITE
        reINVITE (modify the session, hold, resume from hold, etc.)
        BYE

   The main advantage of the 3pcc approach is that it only requires
   very basic SIP support from end systems to support call control
   features.  It also has the advantage and disadvantage that new
   features can/must be implemented in one place only (the controller),
   and neither requires enhanced client functionality, nor takes
   advantage of it.

   In addition, a peer-to-peer approach is discussed at length in this
   draft.  The primary drawback of the peer-to-peer model is additional
   end system complexity.  The benefits of the peer-to-peer model
   include:
   - state remains at the edges
   - signaling is same whether mixing is performed by one of the
     participants, or by a central conference server
   - calls only go through participants involved (no additional points
     of failure)
   - does not reproduce the MGCP/Megaco command/control trust model
   - less complex to setup end-to-end QoS and security
   - shorter setup time (fewer messages, and round trips required)
   - many additional features applied at other UAs are transparent

   The peer-to-peer approach relies on additional "primitive"
   operations, some of which are identified here.

        INVITE with [Replaces] semantics
        INVITE with Join semantics
        INVITE or [REFER] with [Media Forking] semantics
        [REFER] to ask another UA to send a request on your behalf
        [PHONECTL] for desktop call control

   Many of the features, primitives, and actions described in this
   document require some type of mixing/combining/selection.


4. "Conversation Space" Model

   This document introduces the concept of an abstract "conversation
   space" (essentially as a set of participants who believe they are
   all communicating among one another).  Each conversation space
   contains one or more participants.

   Participants are SIP User Agents which send original media to or
   terminate and receive media from other members of the conversation
   space.  Logically, every participant in the conversation space has
 Mahy                     Expires: Jan 2002                         2

                      Call Control Model for SIP


   access to all the media generated in that space (this is true if all
   participants share a common media type).  A SIP User Agent which
   merely forwards, transcodes, mixes, or selects media originating
   elsewhere in the conversation space is NOT a participant.  [Note
   that a conversation space consists of one or more SIP calls or SIP
   conferences.  A conversation space is similar to the definition of a
   "call" in some other call models.]

   Participants may represent human users or non-human users (referred
   to as robots or automatons in this document).  Some participants may
   be hidden within a conversation space. Some examples of hidden
   participants include: robots which generate tones, images, or
   announcements during a conference to announce users arriving and
   departing, a human call center supervisor monitoring a conversation
   between a trainee and a customer, and robots which record media for
   training or archival purposes.

   Participants may also be active or passive.  Active participants are
   expected to be intelligent enough to leave a conversation space when
   they no longer desire to participate.  (An attentive human
   participant is obviously active.)  Some robotic participants (such
   as a voice messaging system, an instant messaging agent, or a voice
   dialog system) may be active participants if they can leave the
   conversation space when there is no human interaction.  Other robots
   (for example our tone generating robot from the previous example)
   are passive participants.  A human participant "on-hold" is passive.

   An example diagram of a conversation space shown as a "bubble" or
   ovals, and as a "set" in curly or square brace notation. Each set,
   oval, or "bubble" represents a conversation space. Hidden
   participants are shown in lowercase letters.


   { A , B }            [ A , B ]

      .-.
     /   \
    /  A  \
   (       )
    \  B  /
     \   /
      '-'


   Some examples of the relationship between conversation spaces and
   SIP calls, SIP call legs, and SIP sessions are listed below.  In
   each example, a human user will perceive that there is a single
   call.

       A simple two-party call is a single conversation space, a single
       call, a single session, and a single call-leg.

 Mahy                     Expires: Jan 2002                         3

                      Call Control Model for SIP


       A locally mixed three-way call is one or two calls (one if the
       mixer invited all the other participants, two otherwise), two
       sessions, and two call-legs.  It is also a single conversation
       space.

       A simple dial-in audio conference is a single conversation
       space, but is represented by as many calls, call-legs, and
       sessions as there are human participants.

       A multicast conference is a single conversation space, a single
       session, one or more calls, and as many call-legs as
       participants.


5. Catalog of call control actions and sample features

   Below are listed several call control "actions" which modify the
   participants in a conversation space. The names of the actions
   listed are for descriptive purposes only (they are not normative).
   This list of actions is not meant to be exhaustive.

   In the examples, all actions are initiated by the user "Alice"
   represented by UA "A".


5.1 Transfer

   The conversation space changes as follows:

         before            after
        { A , B }  -->   { C , B }

   A replaces itself with C.

   To make this happen using the peer-to-peer approach, "A" would send
   two SIP requests.  A shorthand for those requests is shown below:
        REFER B  Refer-To:C
        BYE B

   To make this happen instead using the 3pcc approach, the controller
   sends requests represented by the shorthand below:
        INVITE C (w/SDP of B)
        reINVITE B (w/SDP of C)
        BYE A

   Features enabled by this action:
   - blind transfer
   - transfer to a central mixer (some type of conference or forking)
   - transfer to park server (park)
   - transfer to music on hold or announcement server
   - transfer to a "queue"
   - transfer to a service (such as Voice Dialogs service)
   - transition from local mixer to central mixer
 Mahy                     Expires: Jan 2002                         4

                      Call Control Model for SIP



5.2 Take

   The conversation space changes as follows:

        { B , C }  -->   { B , A }

   A forcibly replaces C with itself.  In most uses of this primitive,
   A is just "un-replacing" itself.

   Using the peer-to-peer approach, "A" sends:
        INVITE B  Replaces: <call leg between B and C>

   Using the 3pcc approach (all requests sent from controller)
        INVITE A (w/SDP of B)
        reINVITE B (w/SDP of A)
        BYE C

   Features enabled by this action:
   - transferee completes an attended transfer
   - retrieve from central mixer (not recommended)
   - retrieve from music on hold or park
   - retrieve from queue
   - call center take
   - voice portal resuming ownership of a call it originated
   - answering-machine style screening (pickup)

5.3 Add

   The conversation space changes as follows:

        { A , B } -->    { A, B, C }

   A adds C to the conversation.

   Using the peer-to-peer approach, adding a party using local mixing
   requires no signaling.  To transition from a 2-party call or a
   locally mixed conference to centrally mixing A could send the
   following requests:
        REFER B  Refer-To: mixer
        INVITE mixer
        BYE B

   To add a party to a central mixer:
        REFER C  Refer-To: mixer
                or
        REFER mixer  Refer-To: C

   Using the 3pcc approach to transition to centrally mixed, the
   controller would send:
        INVITE mixer leg 1 (w/SDP of A)
        INVITE mixer leg 2 (w/SDP of B)
        INVITE C (late SDP)
 Mahy                     Expires: Jan 2002                         5

                      Call Control Model for SIP


        reINVITE A (w/SDP of mixer leg 1)
        reINVITE B (w/SDP of mixer leg 2)
        INVITE mixer leg3 (w/SDP of C)

   To add a party to a central mixer:
        INVITE C (late SDP)
        INVITE mixer (w/SDP of C)

   Features enabled:
   - standard conference feature
   - call recording
   - answering-machine style screening (screening)

5.4 Local Join

   The conversation space changes like this:

        { A, B}  , {A, C}  -->  {A, B, C}

                or like this

        { A, B}  , {C, D}  -->  {A, B, C, D}

   A takes two conversation spaces and joins them together into a
   single space.

   Using the peer-to-peer approach, A can mix locally, or REFER the
   participants of both conversation spaces to the same central mixer
   (as in 5.3)

   For the 3pcc approach, the call flows for inserting participants,
   and joining and splitting conversation spaces are tedious yet
   straightforward, so these are left as an exercise for the reader.

   Features enabled:
   - standard conference feature
   - leaving a sidebar to rejoin a larger conference

5.5 Insert

   The conversation space changes like this:

        { B , C }  -->  {A, B, C }

   A inserts itself into a conversation space.

   A proposed mechanism for signaling this using the peer-to-peer
   approach is to send a new header in an INVITE with "joining"
   semantics.  For example:
        INVITE B  Join: <call id of B and C>

 Mahy                     Expires: Jan 2002                         6

                      Call Control Model for SIP


   If B accepted the INVITE, B would accept responsibility to setup the
   call legs and mixing necessary (for example: to mix locally or to
   transfer the participants to a central mixer)

   Features enabled:
   - barge-in
   - call center monitoring
   - call recording

5.6 Split
   { A, B, C, D } --> { A, B } , { C, D }

   If using a central mixer with peer-to-peer
   REFER C  Refer-To: mixer (new URI)
   REFER D  Refer-To: mixer (new URI)
   BYE C
   BYE D

   Features enabled:
   - sidebar conversations during a larger conference


5.7 Near-fork

   A participates in two conversation spaces simultaneously:

        { A, B } --> { B , [ A } , C ]


   A is a participant in two conversation spaces such that A sends the
   same media to both spaces, and renders media from both spaces,
   presumably by mixing or rendering the media from both.  We can
   define that A is the "anchor" point for both forks, each of which is
   a separate conversation space.

   This action is purely local implementation (it requires no special
   signaling).  Local features such as switching calls between the
   background and foreground are possible using this media
   relationship.

5.8 Far fork

   The conversation space diagram...

        { A, B } --> { A , [ B } , C ]

   A requests B to be the "anchor" of two conversation spaces.

   For an example of using 3pcc to setup media forking, see [Media
   forking].  The session descriptions for forking are quite complex.
   Controllers should verify that endpoints can handle forked-media, by
   using some type of Requires header token.

 Mahy                     Expires: Jan 2002                         7

                      Call Control Model for SIP


   Two ways to setup this media relationship using peer-to-peer call
   control have been proposed:
   - the anchor receives a REFER with require: forked-media (implicit)
   - the anchor receives an INVITE with Fork-with header (explicit)

   Features enabled:
   - barge-in
   - voice portal services
   - whisper
   - hotword detection
   - sending DTMF somewhere else


6. Other Call Control Issues

6.1 Transparent feature interaction

   Combinations of features must work in SIP call control.  For
   example, let us examine the combination of a transfer of a call
   which is conferenced.

   Alice calls Bob.  Alice silently "conferences in" her robotic
   assistant Albert as a hidden party.  Bob transfers Alice to Carol.
   If Bob asks Alice to Replace her leg with a new one to Carol then
   both Alice and Albert should be communicating with Carol
   (transparently).

   Using the peer-to-peer model, this combination of features works
   fine if A is doing local mixing (Alice replaces Bob's call-leg with
   Carol's), or if A is using a central mixer (the mixer replaces Bob's
   call leg with Carol's).  A clever implementation using the 3pcc
   model can generate similar results.

   New extensions to the SIP Call Control Framework should attempt to
   preserve this property.

6.2 Presenting information to the user or application

   Participants should have access to the names of the other
   participants in a conversation space, so that this information can
   be rendered to a human user or processed by an automaton.  Although
   some of this information may be available from To, From, Remote-
   Party-Id, or other SIP headers, another mechanism of reporting this
   information may be necessary.  [The author believes that the data
   reported by RTCP is insufficient for these purposes.]

   For example, a mixer involved in a conversation space may wish to
   provide URLs for conference status, and/or conference/floor control.

6.3 Use of different mixing models

   Several conferencing models are discussed in [conf-models].  For
   brevity, only the two most popular conferencing models are
 Mahy                     Expires: Jan 2002                         8

                      Call Control Model for SIP


   significantly discussed in this document (local and centralized
   mixing).  Applications of the conversation spaces model to
   distributed full mesh and multicast conferences are left as an
   exercise for the reader.
   Note that a distributed full mesh conference can be used for basic
   conferences, but does not allow for more complex conferencing
   actions like splitting, joining, and forking.

   Call control features should be designed to allow a mixer (local or
   centralized) to decide when to reduce a conference back to a 2-party
   call, or drop all the participants (for example if only two
   automatons are communicating).

   The actual heuristics used to release calls are beyond the scope of
   this document, but may depend on properties in the conversation
   space, such as the number of active, passive, or hidden
   participants; and the send-only, receive-only, or send-and-receive
   orientation of various participants.

6.4 Effect when one user is represented by multiple UAs in same call

   Multiple participants in the same conversation space may represent
   the same human user.  For example, the user may use one participant
   for video, chat, and whiteboard media on a PC and another for audio
   media on a SIP phone.  In addition, human users may add robot
   participants which act on their behalf (for example a
   call recording service, or a calendar reminder).  Call Control
   features in SIP should continue to function as expected in such an
   environment.

6.5 "Special" participants

   Call control implementation are encouraged to make intelligent
   decisions based on the type of participants (active/passive, hidden,
   human/robot) in a conversation space.  Currently there is no
   standard way to convey this information about participants in a
   conversation space, but work in this area is encouraged.

   For example, a music on hold service may take the sensible approach
   that if there are two or more unhidden participants, it should not
   provide hold music; or that it will not send hold music to robots.

6.6 Billing issues

   Billing in PSTN is typically based on who initiated a call.  At the
   moment billing in a SIP network is neither consistent with itself,
   nor with the PSTN.  (A billing model for SIP should allow for both
   PSTN-style billing, and non-PSTN billing.)  The example below
   demonstrates one such inconsistency.

   Alice places a call to Bob.  Alice then blind transfers Bob to Carol
   through a PSTN gateway.  In current usage of REFER and BYE/Also, Bob
   may be billed for a call he did not initiate (his UA originated the
 Mahy                     Expires: Jan 2002                         9

                      Call Control Model for SIP


   outgoing call leg however).  This is not necessarily a terrible
   thing, but it demonstrates a security concern (Bob must have
   appropriate local policy to prevent fraud).  Also, Alice may wish to
   pay for Bob's session with Carol.  There should be a way to signal
   this in SIP.

   Likewise a Replacement call may maintain the same billing
   relationship as a Replaced call, so if Alice first calls Carol, then
   asks Bob to Replace this call, Alice may continue to receive a bill.

   Further work in SIP billing should define a way to set or discover
   the direction of billing.

7. Security Considerations

   Let us first examine the security of the primitives used by the 3pcc
   approach (INVITE, reINVITE, and BYE).  All signaling goes through
   the controller, which is a trusted entity.  Initial INVITEs are
   frequently authenticated and may also be hop-by-hop (e.g. IPsec or
   TLS) or end-to-end (e.g. PGP or S/MIME) encrypted.  Also, the human
   or robot user receiving the INVITE may accept or decline the INVITE
   based on any number of factors.

   An attacker can do many "rude" things to a SIP call-leg today (place
   calls on hold, send BYEs, reINVITE to a session of their choosing),
   if they have knowledge of the correct To, From, Call-ID, and CSeq
   headers.  Encrypting or integrity protecting the signaling between
   User Agents and 3pcc controllers can prevent these attacks.

   When using the peer-to-peer approach, the call control actions and
   primitives are initiated by a) an existing participant in the
   conversation space, b) a former participant in the conversation
   space, or c) an entity trusted by one of the participants.  For
   example, a participant always initiates a transfer; a retrieve from
   Park (a take) is initiated on behalf of a former participant; and a
   barge-in (insert or far-fork) is initiated by a trusted entity (an
   operator for example).

   Both REFER and PHONECTL primitives can be secured in the same manner
   as for an initial INVITE. To authorize call control primitives that
   trigger special behavior (such as an INVITE with Replace, Join, or
   Fork semantics), the receiving user agent needs some credentials
   with which to challenge or authorize the call, as the sender may be
   completely unknown to the receiver, except through the introduction
   of a third party.  As future work, some form of generic
   authorization token is probably needed.


8. References


   [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session
   Initiation Protocol", RFC2543, Internet Engineering Task Force,
 Mahy                     Expires: Jan 2002                        10

                      Call Control Model for SIP


   Nov 1998.

   [3pcc] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo,
   "Third Party Call Control in SIP", Internet Draft <draft-rosenberg-
   sip-3pcc-02.txt>, IETF;  March 2001.  Work in progress

   [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3",
   RFC2026 (BCP), IETF, October 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
   requirement     levels," Request for Comments (Best Current
   Practice) 2119, Internet     Engineering Task Force, Mar. 1997.

   [cc-framework] B. Campbell, "SIP Call Control - Framework ",
   Internet Draft <draft-campbell-sip-cc-framework-02.txt>, IETF, Mar.
   2001.  Work in progress.

   [REFER] R. Sparks, "SIP Call Control - Transfer", Internet Draft
   <draft-ietf-sip-cc-transfer-04.txt>, IETF; Feb. 2001. Work in
   progress.

   [Replaces] B. Biggs, R. Dean, "The SIP Replaces Header", Internet
   Draft <draft-biggs-sip-replaces-00.txt>, IETF, Nov. 2000.  Work in
   progress.

   [Media forking] M. Shankar, "SIP Forked Media", Internet Draft
   <draft-shankar-sip-forked-media-00.txt>, IETF, Feb. 2001.  Work in
   progress.

   [PHONECTL] R. Dean, Belkind, B. Biggs, "PHONECTL: A Protocol for
   Remote Phone Control", Internet Draft <draft-dean-phonectl-03.txt>,
   IETF, Jan. 2001.  Work in progress.

   [conf-models]  J. Rosenberg, H. Schulzrinne, "Models for Multi Party
   Conferencing in SIP", Internet Draft <draft-rosenberg-sip-
   conferencing-models-00.txt>, IETF; Nov. 2000. Work in progress.

10.  Acknowledgments

   Thanks to all who attended the SIP interim meeting in February 2001
   for their support of the ideas behind this document.



11. Author's Addresses

   Rohan Mahy
   Cisco Systems
   170 West Tasman Dr, MS: SJC-21/3/3
   Phone: +1 408 526 8570
   Email: rohan@cisco.com


 Mahy                     Expires: Jan 2002                        11

                      Call Control Model for SIP


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


 Mahy                     Expires: Jan 2002                        12


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