Subject: MUMS session control protocol survey response

From: Ruth Lang <[email-masked]>
Date: Mon, 12 Dec 1994 17:18:05 -0800

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

Protocol name:		MUMS protocol
Point of contact:	Rachel Jones -- [email-masked]
			LUTCHI Research Centre
			Dept. of Computer Studies
			Loughborough University of Technology,
			Loughborough, UK

General Description
-------------------------
1. Between what components is the protocol used?

The protocol flows between the session agents, which include the
conference agent (or session manager), the user agent, the media agent
and the floor agent. The protocol also flows between the presentation
managers (user access points), the communications manager(s) and the
task support modules.

2. Describe, at a fairly high level, the characteristics of session
control that are key to your protocol.

The protocol is intended to support a real-time flexible group-working
environment, with access to existing applications. It supports floor
control and a heterogeneous machine environment.

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

The protocol does not provide its own transport reliability; it is
assumed to be provided by a lower level protocol.

General Protocol Characteristics
---------------------------------------
4. Is the representation ASCII or binary?

The protocol is ASCII.

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

The model is peer-to-peer.

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?

All peers are, at the protocol level, considered equal. Asymmetry can
occur because of an imposed or negotiated "policy" for the session,
whereby protocol messages can be directed to a subset of peers.

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

The protocol currently uses TCP/IP.

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

The protocol relies upon both the ordered and reliable delivery of
messages provided by TCP/IP.

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?

Messages can be sent directly to peers and peers can subscribe to an
address and receive all messages sent to that address.

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

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

The current description format is as follows, where a process might be
a presentation manager (or user access point), a session agent, a task
support module or an application.

conf <id> [start|stop]
conf <id> [add|delete]  <process>

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

The protocol is currently used to describe pre-configured sessions.

12. How is a session identified? I.e., what is the session "handle"
and to what extent is it globally unique?

The session id is currently a text string. It is not globally unique.

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?

The environment assumes closed but changeable membership within the
environment. MBONE style tools can be integrated to support open
membership.

14. How are members name and/or identified? Are e-mail style addresses
used, numeric identifiers, etc.?

Participants are identified by machine location (IP address).

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 centralised or distributed manner?

The protocol controls the configuration of processes, and thus, the
configuration of participants and applications. It controls routing,
data flow and reflectors. The components operate in a hybrid
architecture under centralised control.

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

A mismatch can lead to failure.

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

The configuration and the policy can be negotiated by the participants.

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?

Policies are implemented explicitly and are dynamically
configurable. They can be enforced by a nominated participant or
negotiated by the participants. Policies include whether latecomers
are permitted, the floor policy and who is permitted to end the
session.

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?

The protocol has been implemented in Prolog to create a development
environment in which support for collaboration is available. A
demonstrator to support collaborating designers has been built with
the environment. The protocol is under continued development. The
implementation is not freely available.

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 the protocol uses a request-response model, indicate
the pairs. (If this information in a publicly available paper or
report, please provide a reference rather than detail here.)

For further information, please contact me.