MMusic WG Minutes/Slides

[[e-mail] (Eve Schooler)]

   Multiparty Multimedia Session Control Working Group (MMUSIC)
                   Minutes from the 35th IETF
		  Los Angeles, California, USA
			March 4-5, 1996

                             Chairs
                Mark Handley, [e-mail]
                      Ruth Lang, [e-mail]
                Eve Schooler, [e-mail]

MMUSIC met during two sessions at the 35th IETF, both of which were
multicast.  A summary of each of the talks given and a report of any
follow-up action items follows.  An on-line copy of these minutes and
the accompanying PostScript slides are available from
ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.96 and
slides.3.96.{tar, tar.Z}.  These notes were prepared by Ruth Lang.

Mark Handley (UCL) gave a presentation and solicited additional input
on open issues on the Session Description Protocol (sdp.3.96.ps). The
issues reviewed include expression of RTP profiles and payload types,
format lists, format groups, and a proposed change to the "media" and
"connection" lines which allow more general expression of connection
topologies and media relationships (e.g., for layered
encodings). Sufficient input was received to resolve some of the
issues, but discussion will continue on the mailing list on
others. Specifically, RTP profiles will be expressed on the "protocol"
line of the description (i.e., rtp/profile); supporting dynamic RTP
payload types was left as an open issue dependent on further
discussions in AVT regarding the definition of a registration
mechanism for them; the idea of re-introducing format groups was
discouraged in favor of retaining explicit descriptions of a group of
encodings; and changes to the "media2 and "connection" lines were
left as an open issue. A revised Internet draft will be issued soon
and the goal of issuing "last call" before the next IETF meeting was
set.

Mark Handley (UCL) gave a presentation on the design goals and issues
for a Session Directory Announcement Protocol (SDAP)
(sdap.3.96.ps). This protocol was originally envisioned to only
support wide-area multicast of SDP packets, but has been divided into
a wide-area (server to server) and local-area (client to server)
portions. The division was made to facilitate a segregation between
session directory management and maintenance functions (e.g.,
multicast address allocation) and user-oriented functions (e.g.,
instantiating tools). It was noted that the Service Location Protocol
could provide a means to locate directory servers, but lacked support
for asynchronous update. Mark has proposed to write an Internet-Draft
describing SDAP for review and discussion before the next IETF.

Mark Handley (UCL) provided an overview of the motivations for the
creation of the Internet Multimedia Conferencing Architecture document
(confarch.3.96.ps). This document describes the "big picture" which is
driving the development of the MMUSIC protocols, and the relationship
among the protocols in terms of a conference lifecycle.  Allison
Mankin (Transport Area Chair) encouraged that 1) the document be made
an Informational RFC with note that the document is intended to
change, and 2) MMUSIC formally ask the Security Area for a formal
consultation. Additional comments received included an encouragement
that this document be used to note the relationship between MMUSIC and
the ITU work on session control, and that the document should provide
descriptions of yet unchartered (by MMUSIC) technical challenges.

Ross Finlayson (Live Networks) gave a presentation aimed at motivating
more general thinking about the use of the MBONE as a general
groupware framework (groupware.3.96/1-10.ps). Some ideas Ross
suggested for further thought include: developing a way to share more
than just media (i.e., workspace sharing), a generalization in how
sessions are managed (e.g., multiple directories), use of object
inheritance models in describing sessions, supporting additional
persistence models in describing sessions (e.g., personal
directories).  Some discussion centered around the use of multiple
directories and their similarity to net news. No action items followed
from this presentation.

Rob Williams (Microsoft) and Eve Schooler (Cal Tech) each gave
presentations on the topic of User Location [(uls.3.96.ps) and
(userdir.3.96.ps) respectively].  Rob's presentation described a
service that has been developed at Microsoft for which an MMUSIC
Internet-Draft has been created.  This User Location Service provides
a means for users to build a common directory of information regarding
the running applications that can be used for collaboration. The User
Location Service I-D describes the client-side protocol for
add/delete/refresh/query operations to a database of tagged
records. Rob outlined several issues that the Internet-Draft does not
yet cover; examples include defining identifiers for common schema
elements, integration with DNS (seen as way to find User Location
Servers), and security. Eve provided an overview of a multicast-based
user directory she has developed. Goals of the effort are to enable a
simple method for registering user communities, combine dynamic and
static approaches of session management, and take advantage of other
user information on "closeness" to bound scope of media relations for
sessions. This user directory employs an announce/listen paradigm -
everyone using same multicast addr/port is loosely bound; the scope of
reception of the user announcement also defines the scope of reception
of the session itself. Eve has implemented a prototype which will be
released with the next release of MMCC. No specific action items were
generated as a result of these two talks. It was later identified by
the chairs that this topic is of interest to the working group and
that a more thorough review of the problem area and options for
providing such a service (e.g., based on already-developed Internet
protocols) was needed and will be scheduled as an agenda item for the
next IETF.

Eve Schooler (Cal Tech) presented the motivations for and specifics of
the Session Invitation Protocol (SIP) (sip.3.96.ps). This protocol is
targeted to complement the advertisement mechanism provided by tools
such as sd and sdr by enabling the joining of users (as compared to
users joining a session address). It can be used in the context of
both tightly- and loosely-controlled sessions and is intended for
transmission among peer user agents (or proxies for them). SIP uses
SDP as a means of describing the sessions for which an invitation is
being issues. It is meant to be conveyed over UDP and is therefore
minimally stateful -- request/response pair messages are mandatory,
but progress reports and acks are optional. Issues regarding the
choice of transport mechanism of UDP as compared to TCP or remote
procedure calls were discussed, and set-up delay imposed by
timer-based retransmissions were discussed.

Henning Schulzrinne (Fokus GMD) presented the motivations for and
specifics of the Simple Conference Invitation Protocol (SCIP)
(scip.3.96.ps). This protocol is also aimed at complementing
advertisement mechanisms but was developed with an eye towards
supporting telephony functionality. The models and goals of the two
protocols are similar, but SCIP can be contrasted with SIP by its use
of TCP as a transport mechanism, leveraged use of HTTP and SMTP, and
use of an alternate session description format (i.e., not SDP), etc.
Some discussion on UDP vs TCP (T/TCP) vs RPC etc. occurred but no
resolution was reached regarding a choice of a single transport
mechanism for conveyance of an invitation protocol. It is expected
that discussion of issues will be carried on the group's mailing list
and an effort to resolve differences between these two approaches will
be undertaken.

Carsten Bormann (Univ. Bremenn) provided an overview of the Simple
Conference Control Protocol (SCCP) which is a protocol between
conference control agents (horizontal) for orchestrating
tightly-coupled conferences (sccp.3.96.ps). The protocol is intended
to support managing a membership list including per-member
capabilities, application/media sessions, floor control, and
conductorship. It does not duplicate session advertisement or
invitation functions and supports session control only. The protocol
distinguishes protocol structure and protocol semantics (a document
describing the latter was proposed as a complement to SCCP), and is
intended to support bridging to T.120.  Design goals for the protocol
included simplicity and generality, but scalability to "large" groups
(e.g., IETF broadcasts over the Mbone) was excluded. No discussion
regarding the protocol occurred in the meeting due to lack of
time. The draft document circulated informally to the mailing list
will be revised and submitted as an Internet-draft.

Jim Toga (Intel) provided an overview of the ITU H.323 protocol and
highlighted its ability to operate over the Internet
(h323.3.96.ps). Specifically, H.323 supports having two (or more)
H.323 terminals be interconnected by an IP cloud. It supports the
establishment of tightly-controlled conferences which can be
centralized (hub) or distributed (peer-to- peer).  H.323 is based on
family of ITU protocols and interoperability among them is important.
Thus the standard contains many guidelines for interoperation via
gateways. No discussion regarding H.323's use on the Internet and
potential impact on protocols being developed by this group occurred
due to lack of time.  This will be carried on the mailing list.

Ed Ellesson (IBM) provided an overview of Internet Telephony and
highlighted the impact on conference control as well as other IETF- and
Internet-related areas (AVT, Integrated Services).  Ed proposed
questions such as whether solving issues regarding the lack of
interoperability among the Internet Telephone tools was the purview of
MMUSIC and pointed out that regardless, these tools in widespread use
would have a significant impact on traffic congestion on the Internet.
Ed offered to bring Internet phone vendors into the IETF for joint
discussions on this issue. Discussion regarding the seemed mismatch
between the bandwidth most Internet Telephone users have (e.g., 14.4
kb/sec) and the size of Internet protocols, whether the Internet should
work to accommodate this type of traffic flow (vs emphasize its ability
to carry multicast traffic), etc. occurred.  No specific conclusions
were reached in this meeting.