tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5239

 
 
 

A Framework for Centralized Conferencing

Part 2 of 3, p. 17 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
7.  Conferencing System Realization

   Implementations based on this centralized conferencing framework can
   range from systems supporting ad hoc conferences, with default
   behavior only, to sophisticated systems with the ability to schedule
   recurring conferences, each with distinct characteristics, being
   integrated with external resource reservation tools, and providing
   snapshots of the conference information at any of the stages of the
   conference life-cycle.

   A conference object is the logical representation of a conference
   instance at a certain stage, such as capabilities description upon
   conference creation, reservation, activation, etc., which a
   conferencing system maintains in order to describe the system
   capabilities and to provide access to the available services provided
   by the conferencing system.  Consequently, this centralized
   conferencing framework does not mandate the actual usage of the
   conference object, but rather defines the general cloning tree
   concept and the mechanisms required for its realization, as described
   in detail in Section 7.1.

   Ad hoc and advanced conferencing examples are provided in Section 7.2
   and Section 7.3, with the latter providing additional description of
   the conference object in terms of the stages of a conference, to
   support scheduled and other advanced conference capabilities.  The
   scheduling of a conference based on these concepts and mechanisms is
   then detailed in Section 7.4

   As discussed in Section 5.2, the overall policy in terms of
   permissions and limitations is outside the scope of this framework
   document.  The policies applicable to the conference object as a
   whole in terms of read/write access would require a conferencing
   system have access to basic policy information to make the decisions.
   In the examples in this section, the policies are shown logically
   associated with the conference objects to emphasize the general
   requirement for policy functionality necessary for the realization of
   this framework.

7.1.  Cloning Tree

   The concept defined in this section is a logical representation only,
   as it is reflected through the centralized conferencing mechanisms:
   the URIs and the protocols.  Of course, the actual system realization
   can differ from the presented model.  The intent is to illustrate the
   role of the logical elements in providing an interface to the data,
   based on conferencing system and conferencing client actions, and
   describe the resultant protocol implications.

Top      Up      ToC       Page 18 
   Any conference object in a conferencing system is created by either
   being explicitly cloned from an existing parent object or being
   implicitly cloned from a default system conference blueprint.  A
   conference blueprint is a static conference object used to describe a
   typical conference setting supported by the system.  Each system can
   maintain multiple blueprints, typically each describing a different
   conferencing type using the conference information format.  This
   document uses the "cloning" metaphor instead of the "inheritance"
   metaphor because it more closely fits the idea of object replication,
   rather than a data type re-usage and extension concept.

   The cloning operation needs to specify whether or not the link
   between the parent and child needs to be maintained in the system.
   If no link between the parent and child exists, the objects become
   independent and the child is not impacted by any operations on the
   parent object nor subject to any limitations of the parent object.

   Once the new object is created, it can be addressed by a unique
   conference object URI assigned by the system, as described in
   Section 6.2.1.  By default, the newly created object contains all the
   data existing in the parent object.  The newly created object can
   expand the data it contains, within the schema types supported by the
   parent.  It can also restrict the read/write access to its objects.
   However, unless the object is independent, it cannot modify the
   access restrictions imposed by the parent object.

   Any piece of data in the child object can be independently accessed
   and, by default, can be independently modified without affecting the
   parent data.

   Unless the object is independent, the parent object can enforce a
   different policy by marking certain data elements as "parent
   enforceable".  The values of these data elements cannot be changed by
   directly accessing the child object, nor can they be expanded in the
   child object alone.

   Figure 4 illustrates an example of a conference (Parent B), which is
   created independent of its Parent (Parent A).  Parent B creates two
   child objects, Child 1 and Child 2.  Any of the data elements of
   Parent B can be modified (i.e., there are no "parent enforceable"
   data elements), and depending upon the element, the changes will be
   reflected in Child 1 and Child 2 , whereas changes to Parent A will
   not impact the data elements of Parent B.  Any "parent enforceable"
   data elements, as defined by Parent B, cannot be modified in the
   child objects.

Top      Up      ToC       Page 19 
   +---+-----------------------+
   | p |                       |
   | o |   P A R E N T  A      |
   | l |                       |
   | i |   C O N F E R E N C E |
   | c |                       |
   | i |   O B J E C T         |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/  INDEPENDENT
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |   P A R E N T  B      |
   | l |                       |
   | i |   C O N F E R E N C E |
   | c |                       |
   | i |   O B J E C T         |
   | e |                       |
   +-s-+-----------------------+
           |    |
           |    |
           |    ---------------------------
           |                              |
           V                              V
   +---+-----------------------+    +---+-----------------------+
   | p |                       |    | p |                       |
   | o |   C H I L D  1        |    | o |   C H I L D  2        |
   | l |                       |    | l |                       |
   | i |   C O N F E R E N C E |    | i |   C O N F E R E N C E |
   | c |                       |    | c |                       |
   | i |   O B J E C T         |    | i |   O B J E C T         |
   | e |                       |    | e |                       |
   +-s-+-----------------------+    +-s-+-----------------------+

                        Figure 4: The Cloning Tree

   Using the defined cloning model and its tools, the following sections
   show examples of how different systems based on this framework can be
   realized.

Top      Up      ToC       Page 20 
7.2.  Ad Hoc Example

   Figure 5 illustrates how an ad hoc conference can be created and
   managed in a conferencing system.  A client can create a conference
   by establishing a call signaling channel with a conference factory,
   as specified in Section 6.1.  The conference factory can internally
   select one of the system supported conference blueprints based on the
   requesting client privileges and the media lines included in the
   Session Description Protocol (SDP) body.

   The selected blueprint with its default values is copied by the
   server into a newly created conference object, referred to as an
   'Active Conference'.  At this point, the conference object becomes
   independent from its blueprint.  A new conference object identifier,
   a new conference identifier, and a new focus are allocated by the
   server.

   During the conference lifetime, an authorized client can manipulate
   the conference object, by performing operations such as adding
   participants, using the conference control protocol.

   +---+-----------------------+
   | p |                       |
   | o |   System  Default     |
   | l |                       |
   | i |   Conference          |
   | c |                       |
   | i |   Blueprint           |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o |  Active               |
   | l |                       |
   | i |  Conference           |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+

             Figure 5: Conference Ad-hoc Creation and Lifetime

Top      Up      ToC       Page 21 
7.3.  Advanced Example

   Figure 6 illustrates how a recurring conference can be specified
   according to system capabilities, scheduled, reserved, and managed in
   a conferencing system.  A client would first query a conferencing
   system for its capabilities.  This can be done by requesting a list
   of the conference blueprints the system supports.  Each blueprint
   contains a specific combination of capabilities and limitations of
   the conference server in terms of supported media types (e.g., audio,
   video, text, or combinations of these), participant roles, maximum
   number of participants of each role, availability of floor control,
   controls available for participants, availability and type of
   sidebars, the definitions and names of media streams, etc.

   The selected blueprint with its default values is cloned by the
   client into a newly created conference object, referred to as a
   conference reservation, that specifies the resources needed from the
   system for this conference instance.  At this point, the conference
   reservation becomes independent from its blueprint.  The client can
   also change the default values, within the system ranges, and add
   additional information, such as the list of participants and the
   conference 'start' time, to the conference reservation.

   At this point, the client can ask the conference server to create new
   conference reservations by attaching the conference reservation to
   the request.  As a result, the server can allocate the needed
   resources, create the additional conference objects for the child
   conference reservations, and allocate the conference object
   identifiers for all -- the original conference reservation and for
   each child conference reservation.

   From this point on, any authorized client is able to access and
   modify each of the conference objects independently.  By default,
   changes to an individual child conference reservation will affect
   neither the parent conference reservation, from which it was created,
   nor its siblings.

   On the other hand, some of the conference sub-objects, such as the
   maximum number of participants and the participants list, can be
   defined by the system as parent enforceable.  As a result, these
   objects can be modified by accessing the parent conference
   reservation only.  The changes to these objects can be applied
   automatically to each of the child reservations, subject to local
   policy.

Top      Up      ToC       Page 22 
   +---+-----------------------+
   | p |                       |
   | o |   Selected            |
   | l |                       |
   | i |   Conference          |
   | c |                       |
   | i |   Blueprint           |
   | e |                       |
   +-s-+-----------------------+
           |
          \| /
           \/
           /\
          /| \
           V
   +---+-----------------------+
   | p |                       |
   | o | Conference            |
   | l |                       |
   | i | Reservation           |
   | c |                       |
   | i |                       |
   | e |                       |
   +-s-+-----------------------+
           |  |  |
           |  |  |
           |  |  |
           |  |  |
       +---|--|--V-----------------+
     +-+---|--V------------------+ |
   +-+-+---V-------------------+ | |
   | p |                       | | |
   | o | Child Conference      | | |
   | l |                       | | |
   | i | Reservation           | | |
   | c |                       | | |
   | i |                       | |-+
   | e |                       |-+
   +-s-+-----------------------+

     Figure 6: Advanced Conference Definition, Creation, and Lifetime

   When the time comes to schedule the conference reservation, either
   via the system determination that the 'start' time has been reached
   or via client invocation, an active conference is cloned based on the
   conference reservation.  As in the ad hoc example, the active
   conference is independent from the parent, and changes to the
   conference reservation will not impact the active conference.  Any

Top      Up      ToC       Page 23 
   desired changes must be targeted towards the active conference.  An
   example of this interaction is shown in Section 9.1.

7.4.  Scheduling a Conference

   The capability to schedule conferences forms an important part of the
   conferencing system solution.  An individual conference reservation
   typically has a specified 'start' and 'end' time, with the times
   being specified relative to a single specified 'fixed' time (e.g.,
   'start' = 09.00 GMT, 'end'= 'start'+2), subject to system
   considerations.  In most advanced conferencing solutions, it is
   possible to not only schedule an individual occurrence of a
   conference reservation, but also schedule a series of related
   conferences (e.g., a weekly meeting that starts on Thursday at 09.00
   GMT).

   To be able to achieve such functionality, a conferencing system needs
   to be able to appropriately schedule and maintain conference
   reservations that form part of a recurring conference.  The mechanism
   proposed in this document makes use of the "Internet Calendaring and
   Scheduling Core Object" specification defined in [RFC2445] in union
   with the concepts introduced in Section 5 for the purpose of
   achieving advanced conference scheduling capability.

   Figure 7 illustrates a simplified view of a client interacting with a
   conferencing system.  The client is using the conference control
   protocol to add a new conference reservation to the conferencing
   system by interfacing with the conference control server.  A CCP
   request contains a valid conference reservation and reference by
   value to an "iCal" object that contains scheduling information about
   the conference (e.g., 'start' time, 'end' time).

Top      Up      ToC       Page 24 
   +--------------+     +-------Conferencing System-----------------+
   | Generic ICAL |     |                                           |
   |   Resource   |     |    ..Conference Instance....              |
   +--------------+     |    .                       . +-----------+|
         ^ ^            |    . +-------------------+ . | Conference||
         | |            |    . |Conference Objects |<--| Control   ||
         | ----------------->. +-------------------+ . | Server    ||
         |              |    .                       . +-----------+|
         |              |    .........................       ^      |
         |              |                ^                   |      |
   +-----|--------------+                |                   |      |
   |     v                               |                   |      |
   |  +--------------+                   |                   |      |
   |  |   Resource   |<------------------+                   |      |
   |  |   Scheduler  |                                       |      |
   |  +--------------+                                       |      |
   |                                                         |      |
   +---------------------------------------------------------|------+
                                                             |
                                                             |
                                                        +-Request-+
                                                        |         |
                                                        +----+    |
                                                        |ICAL|    |
                                                        +----+----+
                                                             |
                                                             |
                                                             |
                                           Conference Control|
                                               Protocol      |
                                                             |
                                                    +-------------+
                                                    | Conferencing|
                                                    | Client      |
                                                    +-------------+

                       Figure 7: Resource Scheduling

   A CCP request to create a new conference reservation is validated,
   including the associated iCal object, and the resultant conference
   reservation is created.  The conference reservation is uniquely
   represented within the conferencing system by a conference object
   identifier (e.g., xcon:hd87928374), as introduced in Section 6.2.1
   and defined in [XCON-COMMON].  This unique URI is returned to the
   client and can be used to reference the conference reservation, if
   any future manipulations are required (e.g., alter 'start' time),
   using a CCP request.

Top      Up      ToC       Page 25 
   The previous example explains how a client creates a basic conference
   reservation using an iCal reference in association with a conference
   control protocol.  Figure 7 can also be applied when explaining how a
   series of conferences are scheduled in the system.  The description
   is almost identical with the exception that the iCal definition that
   is included in a CCP request represents a series of recurring
   conference instances (e.g., conference 'start' time, 'end' time,
   occur weekly).  The conferencing system will treat this request the
   same as the first example.  The CCP request will be validated, along
   with the associated iCal object, and the conference reservation is
   created.  The conference reservation and its conference object ID,
   created for this example, represent the entire series of recurring
   conference instances rather than a single Conference.  If the client
   uses the conference object ID provided and a CCP request to adjust
   the conference reservation, every conference instance in the series
   will be altered.  This includes all future occurrences, such as a
   conference scheduled as an infinite series, subject to the
   limitations of the available calendaring interface.

   A conferencing system that supports the scheduling of a series of
   conference instances should also be able to support manipulation
   within a specific range of the series.  A good example is a
   conference reservation that has been scheduled to occur every Monday
   at 09.00 GMT.  For the next three weeks only, the meeting has been
   altered to occur at 10.00 GMT in an alternative venue.  With Figure 7
   in mind, the client will construct a CCP request whose purpose is to
   modify the existing conference reservation for the recurring
   conference instance.  The client will include the conference object
   ID provided by the conferencing system to explicitly reference the
   conference reservation within the conferencing system.  A CCP request
   will contain all the required changes to the conference reservation
   (e.g., change of venue).

   The conferencing system matches the incoming CCP request to the
   existing conference reservation but identifies that the associated
   iCal object only refers to a range of the existing series.  The
   conferencing system creates a child, by cloning the original
   conference reservation, to represent the altered conference instances
   within the series.  The cloned child object is not independent of the
   original parent object, thus preventing any potential conflicts in
   scheduling (e.g., a change to the whole series ''start' time').  The
   cloned conference reservation, representing the altered series of
   conference instances, has its own associated conference object ID
   that is returned to the client using a CCP response.  This conference
   object ID is then used by the client to make any future alterations
   on the newly defined sub-series.  This process can be repeated any
   number of times as the newly returned conference object ID
   representing an altered (cloned) series of conference instances, can

Top      Up      ToC       Page 26 
   itself be manipulated using a CCP request for the newly created
   conference object ID .  This provides a flexible approach to the
   scheduling of recurring conference instances.

8.  Conferencing Mechanisms

8.1.  Call Signaling

   The focus is the central component of the conference.  Participants
   interface with the focus using an appropriate call signaling protocol
   (CSP).  Participants request to establish or join a conference using
   the CSP.  After checking the applicable policies, a focus then either
   accepts the request, sends a progress indication related to the
   status of the request (e.g., for a parked call while awaiting
   moderator approval to join), or rejects that request using the call
   signaling interface.

   During an active conference, a conference control protocol can be
   used to affect the conference state.  For example, CCP requests to
   add and delete participants are communicated to the focus and checked
   against the conference policies.  If approved, the participants are
   added or deleted using the call signaling to/from the focus.

8.2.  Notifications

   A conferencing system is responsible for implementing a conference
   notification service.  The conference notification service provides
   updates about the conference instance state to authorized parties,
   including participants.  A model for notifications using SIP is
   defined in [RFC3265] with the specifics to support conferencing
   defined in [RFC4575].

   The conference user identifier and associated role are used by the
   conferencing system to filter the notifications such that they
   contain only information that is allowed to be sent to that user.

8.3.  Conference Control Protocol

   The conference control protocol provides for data manipulation and
   state retrieval for the centralized conferencing data, represented by
   the conference object.  The details of the conference control
   protocol are provided in separate documents.

8.4.  Floor Control

   A floor control protocol allows an authorized client to manage access
   to a specific floor and to grant, deny or revoke access of other
   conference users to that floor.  Floor control is not a mandatory

Top      Up      ToC       Page 27 
   mechanism for a conferencing system implementation, but it provides
   advanced media input control features for conference users.  A
   mechanism for floor control within a conferencing system is defined
   in the "Binary Floor Control Protocol (BFCP)" specification
   [RFC4582].

   Within this framework, a client supporting floor control needs to
   obtain information for connecting to a floor control server to enable
   it to issue floor requests.  This connection information can be
   retrieved using information provided by mechanisms such as
   negotiation using the SDP [RFC4566] offer/answer [RFC3264] exchange
   on the signaling interface with the focus.  Section 11.3 provides a
   discussion of client authentication of a floor control server.

   As well as the client to the floor control server connection
   information, a client wishing to interact with a floor control server
   requires access to additional information.  This information
   associates floor control interactions with the appropriate floor
   instance.  Once a connection has been established and authenticated
   (see [RFC4582] for authentication details), a specific floor control
   message requires detailed information to uniquely identify a
   conference, a user, and a floor.

   The conference is uniquely identified by the conference object ID per
   Section 6.2.1.  This conference object ID must be included in all
   floor control messages.  When the SDP model is used as described in
   [RFC4583], this identifier maps to the 'confid' SDP attribute.

   Each authorized user associated with a conference object is uniquely
   represented by a conference user ID per Section 6.3.  This conference
   user ID must be included in all floor control messages.  When using
   SDP offer/answer exchange to negotiate a floor control connection
   with the focus using the call signaling protocol, the unique
   conference user identifier is contained in the 'userid' SDP
   attribute, as defined in [RFC4583].

   A media session within a conferencing system can have any number of
   floors (0 or more) that are represented by the conference identifier.
   When using SDP offer/answer exchange to negotiate a floor control
   connection with the focus using the call signaling interface, the
   unique conference identifier is contained in the 'floorid' SDP
   attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 .
   Each 'floorid' attribute, representing a unique floor, has an
   'm-stream' tag containing one or more identifiers.  The identifiers
   represent individual SDP media sessions (as defined using 'm=' from
   SDP) using the SDP 'Label' attribute, as defined in [RFC4574].

Top      Up      ToC       Page 28 
9.  Conferencing Scenario Realizations

   This section addresses how advanced conferencing scenarios, many of
   which have been described in [RFC4597], are realized using this
   centralized conferencing framework.  The objective of this section is
   to further illustrate the model, mechanisms, and protocols presented
   in the previous sections and also serves to validate that the model,
   mechanisms, and protocols are sufficient to support advanced
   conferencing scenarios.

   The scenarios provide a high level primitive view of the necessary
   operations and general logic flow.  The details shown in the
   scenarios are for illustrative purposes only and don't necessarily
   reflect the actual structure of the conference control protocol
   messages nor the detailed data, including states, which are defined
   in separate documents.  It should be noted that not all entities
   impacted by the request are shown in the diagram (e.g., focus), but
   rather the emphasis is on the new entities introduced by this
   centralized conferencing framework.

9.1.  Conference Creation

   There are different ways to create a conference.  A participant can
   create a conference using call signaling means only, such as SIP
   detailed in [RFC4579].  For a conferencing client to have more
   flexibility in defining the characteristics and capabilities of a
   conference, a conferencing client would implement a conference
   control protocol client.  By using a conference control protocol, the
   client can determine the capabilities of a conferencing system and
   its various resources.

   Figure 8 provides an example of one client "Alice" determining the
   conference blueprints available for a particular conferencing system
   and creating a conference based on the desired blueprint.

Top      Up      ToC       Page 29 
                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +------------+|
   +--------+                         |                  |            ||
   |        |CCP Request <blueprints> | +-----------+    |            ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |<--------------------------|Control    |~~~>|Blueprint(s)||
   +--------+CCP Response<blueprintA, | |Server     |    |            ||
                             ...      | +-----------+    +------------+|
                          blueprintZ, |                                |
                          confUserID> |                                |
   "Alice"                            |
   +--------+                         |                                |
   |        |CCP Request <reserve,    |                  +------------+|
   |        |     blueprintAConfObjID,| +-----------+    |            ||
   | Client |-------------------------->|Conference |    |Conference  ||
   |        |    confUserID>          | |Control    |~~~>|BlueprintA  ||
   |        |<--------------------------|Server     |    |            ||
   |        |CCP Response             | |           |    +------------+|
   +--------+  <reservationConfObjID, | |           |          \|/     |
                          confID>     | |           |          /|\     |
                                      | |           |           V      |
                                      | |           |    +------------+|
                                      | |           |~~~>|Conference  ||
                                      | |           |    |Reservation ||
                                      | +-----------+    +------------+|
   "Alice"                            |                         |      |
   +--------+                         |                         |      |
   |        |CCP Request <add,        |                         V      |
   |        |reservationConfObjID,    | +-----------+    +------------+|
   | Client |-------------------------->|Conference |    |Active      ||
   |        |     confID,confUserID>  | |Control    |~~~>|Conference  ||
   |        |<--------------------------|Server     |    |            ||
   |        |CCP Response             | |           |    +------------+|
   +--------+   <activeConfObjID,     | |           |                  |
                 confID>              | +-----------+                  |
                                      +--------------------------------+

         Figure 8: Client Creation of Conference Using Blueprints

   Upon receipt of the conference control protocol request for
   blueprints, the conferencing system would first authenticate "Alice"
   (and allocate a conference user identifier, if necessary) and then
   ensure that "Alice" has the appropriate authority based on system
   policies to receive any blueprints supported by that system.  Any
   blueprints that "Alice" is authorized to use are returned in a
   response, along with the conference user ID.

Top      Up      ToC       Page 30 
   Upon receipt of the conference control protocol response containing
   the blueprints, "Alice" determines which blueprint to use for the
   conference to be created.  "Alice" creates a conference object based
   on the blueprint (i.e., clones) and modifies applicable fields, such
   as membership list and 'start' time.  "Alice" then sends a request to
   the conferencing system to create a conference reservation based upon
   the updated blueprint.

   Upon receipt of the conference control protocol request to "reserve"
   a conference based upon the blueprint in the request, the
   conferencing system ensures that the blueprint received is a valid
   blueprint (i.e., the values of the various field are within range).
   The conferencing system determines the appropriate read/write access
   of any users to be added to a conference based on this blueprint
   (using membership, roles, etc.).  The conferencing system uses the
   received blueprint to clone a conference reservation.  The
   conferencing system also reserves or allocates a conference ID to be
   used for any subsequent protocol requests from any of the members of
   the conference.  The conferencing system maintains the mapping
   between this conference ID and the conference object ID associated
   with the reservation through the conference instance.

   Upon receipt of the conference control protocol response to reserve
   the conference, "Alice" can now create an active conference using
   that reservation or create additional reservations based upon the
   existing reservations.  In this example, "Alice" has reserved a
   meetme conference bridge.  Thus, "Alice" provides the conference
   information, including the necessary conference ID, to desired
   participants.  When the first participant, including "Alice",
   requests to be added to the conference, an active conference and
   focus are created.  The focus is associated with the conference ID
   received in the request.  Any participants that have the authority to
   manipulate the conference would receive the conference object
   identifier of the active conference object in the response.

9.2.  Participant Manipulations

   There are different ways to affect a participant state in a
   conference.  A participant can join and leave the conference using
   call signaling means only, such as SIP.  This kind of operation is
   called "1st party signaling" and does not affect the state of other
   participants in the conference.

Top      Up      ToC       Page 31 
   Limited operations for controlling other conference participants (a
   so called "3rd party control") through the focus, using call
   signaling only, may also be available for some signaling protocols.
   For example, "Conferencing for SIP User Agents" [RFC4579] shows how
   SIP with REFER can be used to achieve this functionality.

   In order to perform richer conference control, a user client needs to
   implement a conference control protocol client.  By using a
   conference control protocol, the client can affect its own state, the
   state of other participants, and the state of various resources (such
   as media mixers) that may indirectly affect the state of any of the
   conference participants.

   Figure 9 provides an example of one client "Alice" impacting the
   state of another client "Bob".  This example assumes an established
   conference.  In this example, "Alice" wants to add "Bob" to the
   conference.

                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    | Active     ||
   |        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
   +--------+  Add, "Bob" >           | |Server     |    |            ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
    "Carol"                           |                  '       '    '|
   +--------+  NOTIFY <"Bob"="added"> |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |NOTIFY <"Bob"="added">|+------------+                  |
      +--------+                      +--------------------------------+
        "Bob"

         Figure 9: Client Manipulation of Conference - Add a Party

   Upon receipt of the conference control protocol request to "add" a
   party ("Bob") in the specific conference as identified by the
   conference object ID, the conferencing system ensures that "Alice"
   has the appropriate authority based on the policies associated with
   that specific conference object to perform the operation.  The
   conferencing system must also determine whether "Bob" is already a
   user of this conferencing system or whether he is a new user.

Top      Up      ToC       Page 32 
   If "Bob" is a new user for this conferencing system, a Conference
   User Identifier is created for Bob.  Based upon the addressing
   information provided for "Bob" by "Alice", the call signaling to add
   "Bob" to the conference is instigated through the focus.

   Once the call signaling indicates that "Bob" has been successfully
   added to the specific conference, per updates to the state, and
   depending upon the policies, other participants (including "Bob") may
   be notified of the addition of "Bob" to the conference via the
   conference notification service.

9.3.  Media Manipulations

   There are different ways to manipulate the media in a conference.  A
   participant can change its own media streams by, for example, sending
   re-INVITE with new SDP content using SIP only.  This kind of
   operation is called "1st party signaling" and they do not affect the
   state of other participants in the conference.

   In order to perform richer conference control, a user client needs to
   implement a conference control protocol client.  By using a
   conference control protocol, the client can manipulate the state of
   various resources, such as media mixers, which may indirectly affect
   the state of any of the conference participants.

   Figure 10 provides an example of one client "Alice" impacting the
   media state of another client "Bob".  This example assumes an
   established conference.  In this example, the client, "Alice" whose
   Role is "moderator" of the conference, wants to mute "Bob" on a
   medium-size multi-party conference, as his device is not muted (and
   he's obviously not listening to the call) and background noise in his
   office environment is disruptive to the conference.

Top      Up      ToC       Page 33 
                                      +--------------------------------+
                                      |   Conferencing System          |
    "Alice"                           |                  +---------+--+|
   +--------+                         |                  |policies |  ||
   |        |CCP Request <            | +-----------+    +---------+  ||
   | Client |-------------------------->|Conference |    |Active      ||
   |        |  Conference Object ID,  | |Control    |~~~>|Conference  ||
   +--------+  Mute, "Bob" >          | |Server     |    |            ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
      "Carol"                         |                  '       '    '|
   +--------+  NOTIFY <"Bob"=mute">   |+------------+    '       '    '|
   |        |<-------------------------|Notification|<~~~|            ||
   | Client |.          .             ||Service     |    +-------+    ||
   +--------+--+          .           ||            |    |"Bob"  |    ||
      |        |<----------------------|            |    +-------+----+|
      | Client |  NOTIFY <"Bob"=mute">|+------------+                  |
      +--------+                      +--------------------------------+
          "Bob"

        Figure 10: Client Manipulation of Conference - Mute a Party

   Upon receipt of the conference control protocol request to "mute" a
   party ("Bob") in the specific conference as identified by the
   conference object ID, the conference server ensures that "Alice" has
   the appropriate authority based on the policies associated with that
   specific conference object to perform the operation.  "Bob's" status
   is marked as "recvonly" and the conference object is updated to
   reflect that "Bob's" media is not to be "mixed" with the conference
   media.

   Depending upon the policies, other participants (including "Bob") may
   be notified of this change via the conference notification service.

9.4.  Sidebar Manipulations

   A sidebar can be viewed as a separate Conference instance that only
   exists within the context of a parent conference instance.  Although
   viewed as an independent conference instance, it can not exist
   without a parent.  A sidebar is created using the same mechanisms
   employed for a standard conference, as described in Section 7.1.

   A conference object representing a sidebar is created by cloning the
   parent associated with the existing conference and updating any
   information specific to the sidebar.  A sidebar conference object is

Top      Up      ToC       Page 34 
   implicitly linked to the parent conference object (i.e., it is not an
   independent object) and is associated with the parent conference
   object identifier, as shown in Figure 11.  A conferencing system
   manages and enforces the parent and appropriate localized
   restrictions on the sidebar conference object (e.g., no members from
   outside the parent conference instance can join, sidebar conference
   cannot exist if parent conference is terminated, etc.).

                            +--------------+
                            |  Conference  |
                            |    Object    |
                            |  Identifier  |
                            +--------------+
                                   |
                                   |
                                   |
             +---------------------+---------------------+
             |                     |                     |
     +-------+-------+     +-------+-------+     +-------+-------+
     |    Sidebar    |     |    Sidebar    |     |    Sidebar    |
     |  Conference   |     |  Conference   |     |  Conference   |
     |    Object     |     |    Object     |     |    Object     |
     |  Identifier   |     |   Identifier  |     |   Identifier  |
     +-------+-------+     +-------+-------+     +---------------+

                   Figure 11: Conference Object Mapping

   Figure 11 illustrates the relationship between a conference object
   and associated sidebar conference objects within a conferencing
   system.  Each sidebar conference object has a unique conference
   object identifier, as described in Section 6.2.1.  The main
   conference object identifier acts as a top level identifier for
   associated sidebars.

   A sidebar conference object identifier follows many of the concepts
   outlined in the cloning tree model described in Section 7.1.  A
   sidebar conference object contains a subset of members from the
   original conference object.  Properties of the sidebar conference
   object can be manipulated by a Conference Control Protocol using the
   unique conference object identifier for the sidebar.  It is also
   possible for the top level conference object to enforce policy on the
   sidebar object (similar to parent enforceable, as discussed in
   Section 7.1).

Top      Up      ToC       Page 35 
9.4.1.  Internal Sidebar

   Figure 12 provides an example of one client "Alice" involved in
   active conference with "Bob" and "Carol".  "Alice" wants to create a
   sidebar to have a side discussion with "Bob" while still viewing the
   video associated with the main conference.  Alternatively, the audio
   from the main conference could be maintained at a reduced volume.
   "Alice" initiates the sidebar by sending a request to the
   conferencing system to create a conference reservation based upon the
   active conference object.  "Alice" and "Bob" would remain on the
   roster of the main conference, such that other participants could be
   aware of their participation in the main conference, while an
   internal-sidebar conference is occurring.

Top      Up      ToC       Page 36 
                                      +--------------------------------+
                                      |   Conferencing System          |
                                      |                  +---------+--+|
                                      |                  |policies |  ||
                                      |                  +---------+  ||
                                      |                  |Active      ||
                                      |                  |Conference  ||
   "Alice"                            |                  +-------+    ||
   +--------+                         |                  |"Alice"|    ||
   |        |CCP Req <createSidebar,  |                  +-------+    ||
   |        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
   | Client |-------------------------->|Conference |    +-------+    ||
   |        |    confUserID>          | |Control    |~~~>|"Carol"|    ||
   |        |<--------------------------|Server     |    +-------+----+|
   |        |CCP Response             | |           |           |      |
   +--------+  <sidebarResvConfObjID, | |           |           |      |
                          confID>     | |           |           V      |
                                      | |           |    +---------+--+|
                                      | |           |    |policies |  ||
                                      | |           |~~~>+---------+  ||
                                      | |           |    |            ||
                                      | +-----------+    |            ||
    "Alice"                           |                  | Sidebar    ||
   +--------+                         |                  | Reservation||
   |        |CCP Request <update,     | +-----------+    |            ||
   |        |    sidebarResvConfObjID,| |           |    |            ||
   | Client |-------------------------->|           |~~~>|            ||
   |        |  confID,confUserID,     | |           |    +------------+|
   |        |  video=parent,          | |           |           |      |
   |        |  audio=sidebar>         | |Conference |           |      |
   |        |                         | |Control    |           V      |
   |        |                         | |Server     |    +---------+--+|
   |        |CCP Response             | |           |    |policies |  ||
   |        |    <activeSideConfObjID,| |           |    +---------+  ||
   |        |<--------------------------|           |    |Active      ||
   +--------+    confID>              | |           |    |Sidebar     ||
                                      | |           |    |Conference  ||
                                      | +-----------+    +-------+    ||
                                      |                  |"Alice"|    ||
     "Bob"                            |                  |       |    ||
   +--------+  NOTIFY <"Bob"=added>   |+------------+    +-------+    ||
   |        |<-------------------------|Notification|<~~~|       |    ||
   | Client |                         ||Service     |    |"Bob"  |    ||
   +--------+                         ||            |    +-------+----+|
                                      |+------------+                  |
                                      +--------------------------------+

            Figure 12: Client Creation of a Sidebar Conference

Top      Up      ToC       Page 37 
   Upon receipt of the conference control protocol request to "reserve"
   a new sidebar conference, based upon the active conference received
   in the request, the conferencing system uses the received active
   conference to clone a conference reservation for the sidebar.  As
   discussed previously, the sidebar reservation is NOT independent of
   the active conference (i.e., parent).  The conferencing system also
   reserves or allocates a conference ID to be used for any subsequent
   protocol requests from any of the members of the conference.  The
   conferencing system maintains the mapping between this conference ID
   and the conference object ID associated with the sidebar reservation
   through the conference instance.

   Upon receipt of the conference control protocol response to reserve
   the conference, "Alice" can now create an active conference using
   that reservation or create additional reservations based upon the
   existing reservations.  In this example, "Alice" wants only "Bob" to
   be involved in the sidebar, thus she manipulates the membership.
   "Alice" also only wants the video from the original conference and
   wants the audio to be restricted to the participants in the sidebar.
   Alternatively, "Alice" could manipulate the media values to receive
   the audio from the main conference at a reduced volume.  "Alice"
   sends a conference control protocol request to update the information
   in the reservation and to create an active conference.

   Upon receipt of the conference control protocol request to update the
   reservation and to create an active conference for the sidebar, as
   identified by the conference object ID, the conferencing system
   ensures that "Alice" has the appropriate authority based on the
   policies associated with that specific conference object to perform
   the operation.  The conferencing system must also validate the
   updated information in the reservation, ensuring that a member like
   "Bob" is already a user of this conferencing system.

   Depending upon the policies, the initiator of the request (i.e.,
   "Alice") and the participants in the sidebar (i.e., "Bob") may be
   notified of his addition to the sidebar via the conference
   notification service.

9.4.2.  External Sidebar

   Figure 13 provides an example of one client "Alice" involved in an
   active conference with "Bob", "Carol", "David", and "Ethel".  "Alice"
   gets an important text message via a whisper from "Bob" that a
   critical customer needs to talk to "Alice", "Bob", and "Ethel".
   "Alice" creates a sidebar to have a side discussion with the customer
   "Fred" including the participants in the current conference with the

Top      Up      ToC       Page 38 
   exception of "Carol" and "David", who remain in the active
   conference.  "Alice" initiates the sidebar by sending a request to
   the conferencing system to create a conference reservation based upon
   the active conference object.  "Alice", "Bob", and "Ethel" would
   remain on the roster of the main conference in a hold state.  Whether
   or not the hold state of these participants is visible to other
   participants depends upon the individual and local policy.

                                      +--------------------------------+
                                      |   Conferencing System          |
                                      |                  +---------+--+|
                                      |                  |policies |  ||
                                      |                  +---------+  ||
                                      |                  |Active      ||
                                      |                  |Conference  ||
   "Alice"                            |                  +-------+    ||
   +--------+                         |                  |"Alice"|    ||
   |        |CCP Req <createSidebar,  |                  +-------+    ||
   |        |     activeConfObjID,    | +-----------+    |"Bob"  |    ||
   | Client |-------------------------->|Conference |    +-------+    ||
   |        |    confUserID>          | |Control    |~~~>|"Carol"|    ||
   |        |<--------------------------|Server     |    +-------+    ||
   |        |CCP Response             | |           |    |"David"|    ||
   +--------+  <sidebarResvConfObjID, | |           |    +-------+    ||
                          confID>     | |           |    |"Ethel"|    ||
                                      | |           |    +-------+----+|
                                      | |           |           |      |
                                      | |           |           V      |
                                      | |           |    +---------+--+|
                                      | |           |    |policies |  ||
                                      | |           |~~~>+---------+  ||
                                      | +-----------+    |            ||
    "Alice"                           |                  | Sidebar    ||
   +--------+                         |                  | Reservation||
   |        |CCP Request <update,     | +-----------+    |            ||
   |        |    sidebarResvConfObjID,| |           |    |            ||
   | Client |-------------------------->|           |~~~>|            ||
   |        |  confID,confUserID,     | |           |    +------------+|
   |        |  video=sidebar,         | |           |           |      |
   |        |  audio=sidebar>         | |Conference |           |      |
   |        |                         | |Control    |           V      |
   |        |                         | |Server     |    +---------+--+|
   |        |CCP Response             | |           |    |policies |  ||
   |        |    <activeSideConfObjID,| |           |    +---------+  ||
   |        |<--------------------------|           |    |Active      ||
   +--------+    confID>              | |           |    |Sidebar     ||
                                      | |           |    |Conference  ||
                                      | +-----------+    +-------+    ||

Top      Up      ToC       Page 39 
                                      |                  |"Alice"|    ||
     "Bob"                            |                  +-------+    ||
   +--------+  NOTIFY <"Bob"=added,   |+------------+    |"Bob"  |    ||
   | Client |<-------------------------|Notification|<~~~+-------+    ||
   +--------+         "Ethel"=added,  ||Service     |    |"Ethel"|    ||
                      "Fred"=added,>  ||            |    +-------+    ||
     "Ethel"                       +---|            |    |"Fred" |    ||
   +--------+  NOTIFY <"Bob"=added,|  |+------------+    +-------+----+|
   | Client | <--------------------+  +--------------------------------+
   +--------+  "Ethel"=added,"Fred"=added,>

             Figure 13: Client Creation of an External Sidebar

   Upon receipt of the conference control protocol request to "reserve"
   a new sidebar conference, based upon the active conference received
   in the request, the conferencing system uses the received active
   conference to clone a conference reservation for the sidebar.  As
   discussed previously, the sidebar reservation is NOT independent of
   the active conference (i.e., parent).  The conferencing system also
   reserves or allocates a conference ID to be used for any subsequent
   protocol requests from any of the members of the conference.  The
   conferencing system maintains the mapping between this conference ID
   and the conference object ID associated with the sidebar reservation
   through the conference instance.

   Upon receipt of the conference control protocol response to reserve
   the conference, "Alice" can now create an active conference using
   that reservation or create additional reservations based upon the
   existing reservations.  In this example, "Alice" wants only "Bob" and
   "Ethel", along with the new participant "Fred" to be involved in the
   sidebar; thus, she manipulates the membership.  "Alice" sets the
   media such that the participants in the sidebar don't receive any
   media from the main conference.  "Alice" sends a conference control
   protocol request to update the information in the reservation and to
   create an active conference.

   Upon receipt of the conference control protocol request to update the
   reservation and to create an active conference for the sidebar, as
   identified by the conference object ID, the conferencing system
   ensures that "Alice" has the appropriate authority based on the
   policies associated with that specific conference object to perform
   the operation.  The conferencing system must also validate the
   updated information in the reservation, ensuring whether members like
   "Fred" are already a user of this conferencing system or whether he

Top      Up      ToC       Page 40 
   is a new user.  Since "Fred" is a new user for this conferencing
   system, a conference user identifier is created for "Fred".  Based
   upon the addressing information provided for "Fred" by "Alice", the
   call signaling to add "Fred" to the conference is instigated through
   the focus.

   Depending upon the policies, the initiator of the request (i.e.,
   "Alice") and the participants in the sidebar (i.e., "Bob" and
   "Ethel") may be notified of his addition to the sidebar via the
   conference notification service.



(page 40 continued on part 3)

Next RFC Part