Subject: Session Control Protocol Survey

From: Kevin Lew <[email-masked]>
Date: Mon, 28 Nov 1994 13:38:03 -0500

To whom it may concern:
	The following are answers to your survey questions about our session
control protocol, AVCCP.

---------------
Session Control Protocol Survey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Name of the Protocol:  Audio and Video Conferencing Control Protocol (AVCCP) 
Technical point(s) of contact including email address(es):
    Kevin Lew ([email-masked])
    Janey Hoe ([email-masked])

Current organization affiliation:
    MIT Laboratory for Computer Science
Organization affiliation where work was conducted:
    Hewlett-Packard Laboratories
    Media Technology Lab

General Description
-------------------

1) Between what components is the protocol used?  I.e., between media
   agents, between session managers, session manager to media agent,
   or other.

   We refer to a session manager and media agent collectively as a client.
   We refer to a resource manager as a conference server.
   AVCCP is used between a central resource manager and multiple
   session managers/media agents and between two resource managers.

2) Describe, at a fairly high level, the characteristics of session
   control that are key to your protocol.  I.e., what is the protocol
   trying to achieve and what special problems does it solve.  E.g.,
   process coordination, resource negotiation, media synchronization,
   floor control, topology management, etc.

   AVCCP was designed to place the burden of computation on resource
   managers rather than on session managers/media agents.  Thus, resource
   managers can run on machines with high processing speed, whereas
   session managers/media agents can run on slower computers, such as
   handheld devices.  AVCCP provides floor control mechanisms (as opposed
   to policies), process coordination, and resource negotiation.

3) Describe, at a fairly high level, the characteristics of session
   control that you do not care about or have (un)intentionally
   ignored.  See examples in 3.

   None.

General Protocol Characteristics
--------------------------------

4) Is the representation ASCII or binary?

   Control packets in AVCCP have both ASCII and binary fields.

5) Is the paradigm request/response (client/server model),
   peer-to-peer, or other?

   AVCCP uses a client-server paradigm.

6) Is it asymmetric or symmetric (e.g. do initiator's have special
   privileges or state information)?  Are all messages sent to all
   participants or are some sent to a subset?

   In general, AVCCP is symmetric.  However, since it provides mechanisms
   for floor control, it can be viewed as being asymmetric if an application
   implements a policy that uses these mechanisms to give a participant
   special privileges.

   Whether messages are sent to all or some participants depends on the
   service being used.

7) What transport protocol is used (TCP, UDP, multicast)?  Does it
   make use of other protocols such as RTCP?

   Our current implementation of AVCCP is built on top of TCP.  It does
   not use any other protocols.

8) Does your session control protocol rely on that protocol's model of
   transmission?  E.g., does it require reliable, ordered
   transmission or is multiparty state synchronization not a concern?

   AVCCP relies on reliable, ordered transmission.

9) Briefly describe the addressing model, if any.  I.e., how are
   messages routed to peers?  Are they sent directly, are multicast
   groups used, is message content/registration used, or other?

   In our current implementation, AVCCP sends messages directly to
   session managers/media agents and resource managers.  For some
   services, multicasting messages can be performed; however, in the current
   implementation, no multicasting is used.  (For naming and addressing,
   see questions 12 and 14.)

Session Control Characteristics
-------------------------------

10) How are sessions are described?  What does a session description
    specify -- people, resources, scheduling information, etc.?
    Optionally, include an example session description.

    A session is uniquely identified by a title.  In our current
    implementation, a machine address and port number are associated with
    the title.  A session description also specifies all participants.

11) Is the session description available and used outside of the
    context of the session control protocol?  If so, how
    (pre-scheduling, email-based initiation, etc.)?

    Yes, the session description is stored in a directory server, which
    registers resource managers and session managers/media agents.
		  
12) How is a session identified?  I.e., what is the session "handle"
    and to what extent is it globally unique?

    The protocol specifies that a session must be uniquely identified
    by an ID.  In our current implementation, a session is uniquely
    identified by a title, which has a machine address and port number
    associated with it.

13) Briefly describe the membership model and range of models
    supported.  Is the model open (potentially unknown participation
    and attendance -- lecture hall style), closed (well known and
    limited -- invitation only style), or other?

    AVCCP provides the mechanisms that can be used for both the open
    and closed membership models.

14) How are members named and/or identified?  Are email-style
    addresses used, numeric identifiers, etc.?

    AVCCP specifies that a participant must be uniquely identified by an ID.
    In our current implementation, a participant is uniquely identified
    by a user-specified name, which has a machine address and port number
    associated with it.  Thus, two participants with the same login
    and machine name can participate in a session, as long as the two
    participants use different names.  The directory server is responsible
    for ensuring that duplicate participant names do not occur.

15) Briefly describe "what" is being controlled within a session.
    Does the protocol control routing, data flow (e.g., floor
    control, channel selection), reflectors, end-user applications,
    etc.?  Are these entities controlled in a centralized or
    distributed manner?

    AVCCP controls resource managers and session managers/media agents
    in a distributed manner.

16) How is consensus achieved among parties exchanging this protocol?
    E.g., does initiator dictate policy, does a mismatch lead to
    failure, does negotiation occur when agreement can not be
    achieved?

    AVCCP provides mechanisms for session control, and leaves it up to the
    application to implement policies that use these mechanisms.  For
    example, to achieve consensus, an application can implement the
    Paxos algorithm (L. Lamport. "The Part-Time Parliament."  Digital
    Equipment Corp. Systems Research Center, Technical Report 49, September
    1989.)

17) What aspects of the conference are negotiable?  Members,
    protocols, data formats, resources, scheduling, policy, etc.?

    One of the services of AVCCP is dynamically configuring a client's
    reception characteristics of audio and video data.  The service
    is implemented by having the resource manager and the session manager/
    media agent that the participant uses negotiate session parameters.

18) What policies are implemented explicitly or implicitly (e.g., no
    latecomers permitted, only one video flow at a time, etc.)?  Is
    the choice of policy driven by system requirements, implementation
    constraints, resource limitations, etc?  Are the policies
    configurable?

    Again, AVCCP provides mechanisms that can be used by an application
    to implement policies.

Session Control Protocol Specifics
----------------------------------

19) What is the implementation status of the protocol (paper design,
    partially or fully implemented)?  What language was used to
    implement the protocol and how is it packaged (in a library,
    embedded in an application)?  Is the implementation freely
    available?

    We implemented a subset of AVCCP's services in C.  It is packaged in
    a library.  We also implemented an audio conferencing application that
    uses this prototype implementation of AVCCP on HP workstations with
    audio hardware.  These implementations are available upon request.

20) Describe, at a fairly high level, the basic directives of the
    protocol.  I.e., What are the protocol "commands" and what
    parameters are required?  If protocol uses a request-response model,
    indicate these pairs.  (If this information is contained in a
    publically-available paper or report, please provide a reference
    rather than detail here).

    Please contact the authors for a paper that defines AVCCP, describes
    the prototype implementation, and describes the audio application that
    uses the prototype implementation.