[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
   Internet Draft                                    O. Levin/RADVISION
   Document:                                            R. Even/Polycom
   draft-levin-sipping-conferencing-                    A. Zmolek/Avaya
   requirements-01.txt                                D. Petrie/Pingtel
   July 2002                                 P. Koskelainen/Columbia U.
   Expires: January 2003                                  S. Sen/Nortel






             Requirements for Tightly Coupled SIP Conferencing


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.


Abstract


   This document examines a wide range of conferencing requirements
   being applied to a tightly coupled SIP Star conference.

   Separate documents will map the requirements to existing protocol
   primitives, define new protocol extensions, and introduce new
   protocols.

   Together, these documents would provide a guide for building
   interoperable SIP conferencing applications.





   O. Levin et al.           Expires: January  2003             Page 1


             Requirements for Tightly Coupled SIP Conferencing



Table of Contents
1.  SCOPE............................................................3

2.  TIGHTLY COUPLED SIP CONFERENCING FRAMEWORK.......................3

3.  GENERAL DESIGN GUIDELINES........................................4

4.  DISCOVERY PHASE REQUIREMENTS.....................................4
 SIP ENTITY CONFERENCING CAPABILITIES DISCOVERY......................4
 A PARTICULAR CONFERENCE LOCATION AND INFORMATION DISCOVERY..........5
5.  BASIC CONFERENCING REQUIREMENTS..................................5
 PARTICIPATION OF RFC 3261 COMPLIANT ONLY USER AGENT.................5
 CONFERENCE ESTABLISHMENT IN DIAL-OUT SCENARIOS (AS PER [3]).........5
 CONFERENCE ESTABLISHMENT IN DIAL-IN SCENARIOS (AS PER [3])..........6
 THIRD PARTY INVITATION TO A CONFERENCE..............................6
 DISCONNECTION OF CONFERENCE MEMBERS AND CONFERENCE TERMINATION......6
 CONFERENCE MEMBER PRIVACY...........................................7
6.  CONFERENCE STATE DISSEMINATION REQUIREMENTS......................7
 REPORT OF CHANGES...................................................7
 ON-DEMAND DISSEMINATION.............................................8
7.  MISCELLANEOUS REQUIREMENTS.......................................8

8.  MEDIA CONTROL REQUIREMENTS.......................................9

9.  CONFERENCE ACCESS CONTROL LIST (ACL).............................9

10.  CONFERENCE PARTICIPANT PRIVILEGES..............................10
 MODEL..............................................................10
 REQUIREMENTS.......................................................10
11.  FLOOR CONTROL..................................................10
 DEFINITIONS........................................................10
 REQUIREMENTS.......................................................11
12.  REQUIREMENTS BEYOND MANAGEMENT OF A SINGLE CONFERENCE..........12

13.  CONVENTIONS USED IN THIS DOCUMENT..............................13

14.  SECURITY CONSIDERATIONS........................................13

15.  AUTHOR'S ADDRESSES.............................................13

16.  REFERENCES.....................................................14

   O. Levin et al.         Expires: January 2003               Page 2


             Requirements for Tightly Coupled SIP Conferencing




1. Scope

   This document examines a wide range of conferencing requirements
   being applied to a tightly coupled SIP Star conference.

   The requirements are grouped according to their topics in order to
   define solutions to different topics in parallel.

   Separate documents will map the requirements to existing protocol
   primitives, define new protocol extensions, and introduce new
   protocols.

   Together, these documents would provide a guide for building
   interoperable SIP conferencing applications.

2. Tightly Coupled SIP Conferencing Framework

   SIP conference is an association of SIP User Agents (e.g. conference
   members) with a central member (e.g. a conference host), which has a
   direct peer-wise relationship with each other member by means of a
   SIP dialog. Each dialog can belong to a different SIP session.

   In this framework, the SIP conference graph is always a star. The
   conference host maintains the correlation among conference's dialogs
   internally.

   The conference state is defined by a set of information describing
   the conference in progress. This MAY include the following: all or
   some participant information such as dialog-ids, media sessions in
   progress, etc. A complete conference state definition can be found
   in [5].

   The conference can be hosted either by a participating entity (e.g.
   terminal) or by a separate application server.

   Typically to the first case, a terminal is capable of hosing a
   limited ad hoc conference. Such conference is established using
   basic conferencing primitives.

   Editor's Note: This is similar to traditional offering from PSTN
   service providers in audio conferencing such as being able to join
   independent calls into a multiparty conference.

   Application server offers more robust options including reservation,
   large conferences, and managed conferences. In addition to the basic
   functionality, the conferencing server supports any subset of
   advanced conferencing features, presented in this document. In this
   case, the conference has a globally routable identifier, such as SIP
   URI.


   O. Levin et al.         Expires: January 2003               Page 3


             Requirements for Tightly Coupled SIP Conferencing



   The conference properties are defined by a list of configuration
   parameters (e.g., maximum number of ports/participants, needs chair-
   person supervision or not, password protected or not, duration,
   etc.) that a conference creator can request from the conference
   service. Conference properties are configured at the onset of a
   conference and, typically, need special privileges to be changed.

   Conference participants MAY have different roles or privileges in a
   conference. For example, a conference Chair MAY have the right to
   disconnect users from a conference, or terminate the conference.

   SIP conference MAY have media sessions similarly to standard two-
   party SIP calls. The conference media graph is constructed
   independently from the SIP star conference. For example, it can be
   centralized (e.g. following the star graph of the SIP conference) or
   it can be de-centralized (such as multicast mesh among the
   participating entities). As it can be seen from the examples, the
   function of the media processing can be performed either by the
   conference host alone or by each one of the participating entities.

3. General Design Guidelines

   GDG-1: Keep It Simple.

   GDG-2: Low Bandwidth Consumption.
   Mobile low-bandwidth devices represent large portion of user base.
   Bandwidth consumption on the access link is the most important mobile
   requirement.

   GDG-3: MUST NOT assume IP Multicast.
   The solution MUST NOT assume IP multicast since it is not widely
   available in mobile networks or in residential environments (such as
   PPPoE).

   GDG-4: The design MUST allow for scalable architecture in order to
   support large (but still tightly managed) conferences.

   GDG-5: Since the request processing may take long time at the
   server, the response mechanism SHOULD be asynchronous.

   Editor's note: For example, if a conference creation includes long
   list of dial-out participants, it may take a long time to have the
   final response to the request.

4. Discovery Phase Requirements

SIP Entity Conferencing Capabilities Discovery





   O. Levin et al.         Expires: January 2003               Page 4


             Requirements for Tightly Coupled SIP Conferencing


   Editor's Note: The following requirements can always be achieved by
   configuration means or/and human agreement. Nevertheless, we feel
   that automatic means MUST be defined.

   CAPD-1: A standard means MUST be defined for automatic discovery of
   location of conferencing application server(s).

   CAPD-2: A standard format for expressing UA's conferencing
   capabilities MUST be defined. Each SIP entity MUST be able to
   independently express its capabilities as a conference member only
   and as a conference host.

   CAPD-3: A standard means MUST be defined for retrieving conferencing
   capabilities of a known SIP entity. In this regard, the SIP entity
   can be either a user device (e.g. a terminal) or a dedicated
   conferencing server.

A Particular Conference Location and Information Discovery

   CNFD-1: Given a global identifier of a particular conference, a
   standard means MUST be defined for locating the hosting entity of
   this conference.

   CNFD-2: Given a global identifier of a particular conference, a
   standard means MUST be defined for obtaining the conference
   properties.

   CNFD-3: Given a global identifier of a particular conference, a
   standard means MUST be defined for obtaining the conference state
   information.

5. Basic Conferencing Requirements

Participation of RFC 3261 compliant only User Agent

   BSC-1:  A conference host MUST be able to invite and disconnect an
   RFC 3261 compliant only SIP UA to and from a SIP conference.

   BSC-2: RFC 3261 compliant only SIP UA's MUST be able to dial-in a
   particular SIP conference (as per [3]). In this case, only the user
   behind its UA knows that he dials into the conference.

   Editor's Note: In this case, the conference can be identified either
   by manually populating the Request-URI field with the conference
   identifier or, alternatively, by using an IVR service.

Conference Establishment in Dial-Out Scenarios (as per [3])

   DOUT-1: A means MUST be defined for a conference host to invite a
   User Agent to one of its active conferences (specified by a



   O. Levin et al.         Expires: January 2003               Page 5


             Requirements for Tightly Coupled SIP Conferencing


   conference identifier) over an existing SIP dialog between the two.
   As a result, the dialog becomes a part of the conference.

   DOUT -2: A means MUST be defined for a conference host to invite a
   User Agent by establishing a new SIP dialog between the two together
   with specifying the identifier of the conference. The dialog belongs
   to the conference.


Conference Establishment in Dial-In Scenarios (as per [3])

   DIN-1: Provided desired conference properties and the hosting entity
   location (as per DS-1 and DS-2), a means MUST be defined for a UA to
   create an ad-hoc conference [3] and to become its member. A means
   MUST be defined for creating a global conference identifier for this
   ad-hoc scenario.

   DIN-2: Provided a reserved conference identifier, a means MUST be
   defined for a UA to activate the conference and to become its
   member.

   DIN-3: Provided a reserved conference identifier, a means MUST be
   defined for a UA to dial-in an active conference and to become its
   member.

   DIN-4: Provided one of the dialogs ID, belonging to a particular
   active conference, a means MUST be defined for a UA to dial-in an
   active conference and to become its member.

Third Party Invitation to a Conference

   THIP-1: Provided a conference identifier, a means MUST be defined
   for a UA to invite another UA to this conference.

   THIP-2: Provided one of the dialogs ID, belonging to a particular
   active conference, a means MUST be defined for a UA to invite
   another UA to this conference.

   THIP-3: Provided a conference identifier, a means MAY be defined for
   a UA to invite a list of UAs to this conference (a so-called "mass
   invitation").

Disconnection of Conference Members and Conference Termination

   TERM-1: A means MUST be defined for a conference host to disconnect
   a conference member from an active conference.

   TERM-2: A means MAY be defined for a conference host to revert a
   two-party conference to a basic SIP point-to-point session (and
   releasing internal conferencing resources).



   O. Levin et al.         Expires: January 2003               Page 6


             Requirements for Tightly Coupled SIP Conferencing


   TERM-3: Provided a conference identifier, a means MUST be defined
   for a UA to disconnect another UA from this conference.

   TERM-4: Provided one of the dialogs ID, belonging to a particular
   active conference, a means MAY be defined for a UA to disconnect
   another UA from this conference.

   TERM-5: Provided a conference identifier, a means MAY be defined for
   a UA to disconnect a list of UAs from this conference (a so-called
   "mass feature").

   TERM-6: Provided a conference identifier, a means MUST be defined
   for a UA to disconnect all members from this conference.

   TERM-7: Provided a conference identifier, a means MAY be defined for
   a UA to terminate this conference by disconnection all the members,
   releasing conference resources together with the conference
   identifier.

   Editor's note: Some of the requirements above overlap with each
   other.

Conference Member Privacy

   The following features depend both on host's capabilities and
   policies and on members' capabilities.

   A conference host SHOULD support these. A conference member MAY
   support these.

   PRV-1: A conference member participates in a conference
   "anonymously", meaning that its presence is known and can be
   announced but without disclosing its identity.

   PRV-2: A conference member requests anonymous participation from the
   host.

   PRV-3: A conference member participates in a conference "in a hidden
   mode", meaning that both its presence and its identity are not
   disclosed.

   PRV-4: A conference member requests participation in a hidden mode.

6. Conference State Dissemination Requirements

Report of Changes

   CNG-1: It is expected that the set of events related a conference
   state and required to be reported would grow with time. Therefore, a
   mechanism for extensible definition/registration of new conference
   state changes MUST be defined.


   O. Levin et al.         Expires: January 2003               Page 7


             Requirements for Tightly Coupled SIP Conferencing



   CNG-2: A means MUST be defined for reporting the conference state
   changes to interested parties (including conference members) in a
   timely manner. The report MAY include more than one change.

   CNG-3: A means MUST be defined for a SIP UA to express its interest
   in selected state changes only.

   CNG-4: A means MUST be defined for a SIP UA to express the minimum
   interval between receiving state change reports.

   A means MUST be defined for reporting at least the following changes
   in a conference state:

   CNG-5: A new conference member joined the conference.

   CNG-6: A Particular conference member left the conference.

On-demand Dissemination

   ODD-1: A means MUST be defined to disseminate any conference state
   information (as per [5]) to interested parties (i.e. SIP UAs) on-
   demand.

   ODD-2: A means MUST be defined for a SIP UA to request a conference
   state information of a particular conference defined by the
   conference identifier.

   ODD-3: A means MUST be defined for a SIP UA to specify the subset of
   the conference state information, it wants and capable to receive.

7. Miscellaneous Requirements

   MISC-1: A procedure for delegating of a host role by the current
   host to another member MUST be defined.

   MISC-2: A procedure for requesting a conference host to transfer its
   role to another conference member MUST be defined.

   MISC-3: A procedure for on-demand unconditional transfer of the host
   role to a different member MUST be defined.

   MISC-4: A detection procedure for a conference host failure
   condition MUST be defined.

   MISC-5: In case a conference host failure, a procedure for assigning
   a new conference host MUST be defined.

   Editor's Note: This is a difficult for standardization requirement.




   O. Levin et al.         Expires: January 2003               Page 8


             Requirements for Tightly Coupled SIP Conferencing


8. Media Control Requirements

   This section is left for future study.
   To this point, the listed below requirements have been identified:

   MEDI-1: Each media session between the conference Server and a
   participant in a conference MUST have a unique identity in the
   conference space

   MEDI-2: It MUST be possible for a user to participate in a sub-set
   of media sessions of a conference

   MEDI-3: It MUST be possible to modify media sessions of certain
   subset of the participants without impacting the sessions of other
   participants (e.g., introduce side-bar conversations between two
   participants).

   MEDI-4: It MUST be possible to modify a subset of the media sessions
   of a participant during the conference (e.g., swap in and out
   video).

   MEDI-5: A media session of a participant MUST be in one of the
   following states:
   - Inactive : SDP attribute=inactive
   - Active   : opposite of inactive
   - On-hold  : SDP attribute=sendonly
   - Disabled : media port = 0

   MEDI-6: It MUST be possible for the conference server to mix a sub-
   set of the active media sessions in a conference (e.g., mix audio
   from two most audible speakers).

   MEDI-7: It SHOULD be possible for a participant with appropriate
   privileges to add (and delete) conference-wide media sessions into
   (from) the conference, or modify their properties.

9. Conference Access Control List (ACL)

   The purpose of the Access Control List is to define who is allowed
   (or not allowed) to join the conference. If there is user's join
   attempt, but user is not in the ACL then (depending on the
   conference policy), the conference chair MAY be consulted whether
   the user can be accepted to join the conference.

   ACL-1: There MUST be a mechanism to define Access Control List (ACL)
   so that user's joins can be pre-authorized (or denied).

   ACL-2: It MUST be possible to add and delete users to/from ACL.





   O. Levin et al.         Expires: January 2003               Page 9


             Requirements for Tightly Coupled SIP Conferencing


   ACL-3: It MUST be possible to consult a user with appropriate
   privileges (such as chair) when an unknown user tries to join the
   conference. The chair may accept or deny the join attempt.

10.     Conference Participant Privileges

Model

   Conference participants MAY have different privileges.

   In the simplest case, only two kinds of participants exist: the
   conference Chair (with all the privileges), and normal Participants
   (without any privileges).

   For example, following privileges MAY be supported:
   -    Right to terminate a conference
   -    Right to disconnect participants
   -    Right to manage general conference properties
   -    Right to manage conference access control list (ACL)
   -    Right to manage conference-wide media sessions (e.g. add audio
   session into conference)
   -    Right to manage other participant's session parameters (such as
   media)
   -    Right to make real-time authorization (for join attempts)
   -    Right to hand-off all (or some of) the above privileges to
   another participant

   Some conferences may utilize more complex privilege definition and
   hierarchy; such as guru-participants have the right to disconnect
   participants.

   Therefore, protocol mechanisms MUST be in place to translate these
   rights into actions.


Requirements

   PRIV-1:  It MUST be possible to define different privileges to
   different participants.

   PRIV-2: It MAY be possible that different participant levels are
   defined (e.g. senior-member, panelist).

   PRIV-3: Rules MUST be defined for special cases, such as if chair
   leaves suddenly, or chair tries to take privileges away from all
   privilege holders.

11.     Floor Control

Definitions



   O. Levin et al.         Expires: January 2003              Page 10


             Requirements for Tightly Coupled SIP Conferencing


   Conference applications often have shared resources such as the
   right to talk, input access to a limited-bandwidth video channel, or
   a pointer or input focus in a shared application.

   In many cases, it is desirable to be able to control who can provide
   input (send/write/control, depending on the application) to the
   shared resource.

   Floor control enables applications or users to gain safe and
   mutually exclusive or non-exclusive input access to the shared
   object or resource.

   This is an optional feature for conferencing applications. SIP
   conferencing applications may decide not to implement this feature.

   Floor control has been studied extensively over the years (e.g. [8],
   [9], [10], [11], and [12]) therefore earlier work can be utilized
   here.

   A floor control protocol is used to convey the floor control
   messages among the floor chairs (moderators) of the conference, the
   conference server and the participants of the conference.

   The centralized conference server controls the floors at least in
   the signaling level. Controlling also the actual (physical) media
   resources (e.g. audio mixer) is highly recommended, but beyond the
   scope of this document.

   Note that the floor is a concept coupled with one or more media
   sessions.
   The creation of the media session itself is defined elsewhere.
   A participant with appropriate privileges may create a floor by
   defining that existing media session(s) is now floor-controlled.

Requirements

   FLO-1: It MUST be possible to announce that one or more conference's
   media sessions are floor-controlled. This means that, unless
   otherwise defined, all floor participants are in passive receive-
   only mode. It MUST also be possible to group more than one media
   sessions together so that one floor applies to the group of media
   sessions.

   Editor's note: This announcement can be done e.g. via SDP "fid"
   extensions ([6] and [7]).

   FLO-2: It MUST be possible to define who is allowed to create a
   floor in a conference.

   Editor's note: This may be a conference chair, or a participant
   authorized by conference chair.


   O. Levin et al.         Expires: January 2003              Page 11


             Requirements for Tightly Coupled SIP Conferencing



   FLO-3: It MUST be possible for a participant with appropriate
   privileges to create a floor with specific parameters, such as how
   many simultaneous users are allowed.  Similarly, floor modification
   and termination MUST be supported.

   Example of this is that chair creates a floor (for existing audio
   session) and defines that max two users are allowed to hold the
   floor at the same time. The server can then take care of this.

   FLO-4: It MUST be possible to use moderator-controlled floor policy
   in which the server notifies the floor moderator and waits for the
   moderator to make decisions. This enables the moderator to fully
   control who has the floor. The server MAY forward all requests
   immediately to moderator, or it may do filtering and send only
   occasional notifications to moderator.

   FLO-5: It MAY be possible that several users are acting as floor
   moderators. The centralized server may send floor request
   notifications either sequentially, or at the same time.

   FLO-6: The moderator actions (e.g. floor grant) MUST be atomic and
   the server MUST cope with "simultaneous write" problem in which many
   moderators try to make conflicting decisions at the same time.

   FLO-7: Participants MUST be able to request (claim) a floor.

   FLO-8: It MUST be possible (for a floor holder) to release a floor.

   FLO-9: It MUST be possible (for a server or participant with
   appropriate privileges) to revoke a floor from its current holder.

   FLO-10: It MUST be possible to grant a floor to a participant.


   Floor control related parameters are defined when the controlled
   floor is created, or modified.

   FLO-11: It MUST be possible to manipulate at least the following
   floor parameters:

   - Floor control chair (this does not have to be the conference
   chair)
   - Floor control policy (such as moderator-controlled, FCFS, Random)
   - Number of simultaneous floor holders

   FLO-12: it MAY be possible to manipulate additional parameters, such
   as time limits.

12.     Requirements Beyond Management of a Single Conference



   O. Levin et al.         Expires: January 2003              Page 12


             Requirements for Tightly Coupled SIP Conferencing


   This section is left for future study.
   To this point, the listed below requirements have been identified:

   MET-1: It SHOULD be possible to merge two existing conferences to
   form a single conference.

   MET-2: It SHOULD be possible to split an active conference into two
   or more conferences.

   MET-3: It SHOULD be possible to daisy-chain multiple ongoing
   conferences.

   Editor's Note: In general, conferencing split and merge operations
   are extremely difficult. We may consider achieving this
   functionality by transferring individual participants to other
   conference using simple SIP means.

13.     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 [1].

14.     Security Considerations
   Security requirements will be addressed in the next version of this
   document.

15.     Author's Addresses

   Orit Levin
   RADVISION Inc.
   266 Harristown Road,
   Suite 201,
   Glen Rock, NJ 07452          Phone:  +1-201-689-6330
   USA                          Email:  orit@radvision.com


   Roni Even
   Polycom
   94 Derech Em Hamoshavot
   Petach Tikva                 Phone: +972-3-925-1200
   Israel                       Email: roni.even@polycom.co.il


   Andy Zmolek
   Avaya
   8740 Lucent Blvd. 403E273
   Highlands Ranch, CO 80129    Phone: +1-720-444-4001
   USA                          Email: zmolek@avaya.com




   O. Levin et al.         Expires: January 2003              Page 13


             Requirements for Tightly Coupled SIP Conferencing


   Daniel G. Petrie
   Pingtel Corp.
   400 W. Cummings Park
   Suite 2200
   Woburn, MA 01801             Phone: +1 781 938 5306
   USA                          Email: dpetrie@pingtel.com


   Petri Koskelainen
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue,
   MC 0401 New York,
   NY 10027
   USA                          Email: petkos@cs.columbia.edu

   Sanjoy Sen
   Nortel Networks              Email: sanjoy@nortelnetworks.com




16.     References


   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
   2  J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation
      Protocol", RFC 3261.
   3  J. Rosenberg, H. Schulzrinne, "Models for Multi Party
      Conferencing in SIP", draft-ietf-sipping-conferencing-models-
      00.txt, Nov 2001, IETF Draft. Work in progress.
   4  Mahy/Cambell/Johnston/Petrie/Rosenberg/Sparks, "A Multi-party
      Application Framework for SIP", draft-ietf-sipping-cc-framework-
      00.txt, Feb 2002, IETF Draft. Work in progress.
   5 J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP)
     Event Package for Conference State", draft-ietf-sipping-
     conference-package-00.txt, June 2002, IETF Draft. Work in
     progress.
   6 M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description
     Protocol", draft-ietf-mmusic-sdp-new-08.txt, Apr 2002, IETF Draft.
     Work in progress.
   7 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in
     SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Work in
     progress.
   8 Dommel, H-P. and Garcia-Luna-Aceves, J., "Floor control for
     activity coordination in networked multimedia applications." In
     Proc. of 2nd Asian-Pacic Conference on Communications (APCC)
     (Osaka, Japan, June 1995).



   O. Levin et al.         Expires: January 2003              Page 14


             Requirements for Tightly Coupled SIP Conferencing




   9 Dommel, H-P. and Garcia-Luna-Aceves J., "Efficacy of Floor Control
     Protocols in Distributed Multimedia Collaboration," Cluster
     Computing Journal, Special issue on Multimedia Collaborative
     Environments, Vol. 2, No.1, 1999.
   10 Bormann, C., Kutscher, D., Ott, J., and Trossen, D. "Simple
     conference control protocol service specifation." Mar. 2001, IETF
     Draft,. Work in progress.
   11 Koskelainen, P., Schulzrinne H., and Wu, X. "A SIP-based
     Conference Control Framework," in Proc. International Workshop on
     Network and Operating System Support for Digital Audio and Video
     (NOSSDAV), (Miami Beach, Florida), May 2002.
   12 Wu/Koskelainen/Schulzrinne/Chen, "Use SIP and SOAP for conference
     floor control", draft-wu-sipping-floor-control-01.txt, Apr
     2002,IETF Draft. Work in progress.




































   O. Levin et al.         Expires: January 2003              Page 15