Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mmusic/confctrl-minutes-92nov.txt

Text File | 1993-08-12 | 5KB | 135 lines

Editor's Note: The CONFCTRL BOF became the MMUSIC WG on 6/24/93.

CURRENT_MEETING_REPORT_


Reported by Eve Schooler/ISI and Dean Blackketter/Apple

Minutes of the Conferencing Control BOF (CONFCTRL)

One task of the initial BOF sessions was actually to find a suitable
definition for ``conference control'', since the topic has been bandied
about for some time in the Remote Conferencing BOF and the Audio/Video
Transport Working Group.  By broadly defining multimedia conferencing as
collaborations in two dimensions (members and media), we defined
conference control as the management and coordination of (multiple)
conference members in (multiple) media.

How does conference control pertain to the ongoing RemConf efforts for
an overall remote conferencing architecture, and in particular to the
developments in the AVT Working Group of a real-time transport protocol?
We agreed that there is a need for a session layer control protocol to
perform higher layer functions than the protocol proposed in the AVT
Working Group.  For example, three aspects of conference control might
include session, connection and configuration management; session
management entails who is involved in a conference, connection
management involves the topology of who is seeing whom in each media,
and configuration management is the negotiation of differences in
end-system capabilities.

We identified the beginnings of some design criteria for this protocol.
First, it should be kept simple, yet extensible.  We would like for it
to accommodate a range of session styles -- beyond the unmoderated
sessions already available through vat, dvc, nv et al.  We also
recognized the need to separate short-term from long-term functionality
goals.

We brainstormed about which functions MUST be supported versus which we
would like to have supported.  It falls out of our definition for
conference control that, at minimum, support is needed for both
membership and media control.  Membership control might include
admission policies (such as user identification, user payment, meeting
sponsorship), whereas media control might encompass capability
descriptions, synchronization policies, and floor control (media focus).
In both dimensions, session setup, maintenance and/or modification must
be supported.

Other features deemed important but probably of lower priority included
security (in the form of authentication and encryption), as well as
feedback channels for bandwidth balancing.  We also listed outside
services to which we expect a conference control protocol to interface:
a suite of directory services for cataloguing users, conferences, and
shared devices; bandwidth allocation and reservation mechanisms; and a
scheme for multicast address allocation.  Our assumption is that
eventually these outside services will be available.

To understand the range of capabilities to support in a conference

                                   1





control protocol, we explored the types of sessions that might arise.
Our wishlist included a continuum of session scenarios (although the
picture below only lists a sample from the full range and only crudely
approximates an ordering).  ``Secure'' variations on these meetings were
also discussed.



        impromptu
         hallway
         meetings        classroom        seminar      pay-per-view

    |-------|-------|--------|-------|-------|-------|-------|-------|

   pt2pt       arch design         panel          lecture           TV
   phone        review/          discussion/                     broadcast
    call     ``quilting bee''   presidential debate



Observations made about the spectrum were that there are different types
of participation (active and passive), that there are gradations of
identification policies (known vs anonymous participants), that there
may be extreme variations in the degree of interconnectivity among
participants, etc.

We discussed that for simplicity's (and implementation's) sake, we are
likely to need to select a small number of session types that the
protocol should support.  A rough breakdown into four general session
models was presented:


  1. Point-to-point calls.
  2. Small, tightly-controlled sessions:  N-way interconnectivity.
  3. Medium-sized, loosely-controlled sessions:  lighter-weight model.
  4. Very large, fixed sessions:  unidirectional broadcasts.


There was discussion that other standards bodies (CCITT) have explored
issues in some aspects of connection control (for B-ISDN). In addition,
existing prototype conferencing tools should be examined for leads on
tradeoffs regarding conference management.

Attendees

Dean Blackketter         [e-mail]
Wo Chang                 [e-mail]
Osmund de Souza          [e-mail]
Hans Eriksson            [e-mail]
Don Hoffman              [e-mail]
Oliver Jones             [e-mail]
Jim Knowles              [e-mail]
Bill Manning             [e-mail]

                                   2





Kathleen Nichols         [e-mail]
Jim Perchik              [e-mail]
Eve Schooler             [e-mail]
Henning Schulzrinne      [e-mail]
Scott Stein              [e-mail]
Thierry Turletti         [e-mail]
Abel Weinrib             [e-mail]



                                   3