Subject: MMUSIC summary

From: [email-masked] (Eve Schooler)
Date: Wed, 18 Dec 96 12:07:44 PST

Courtesy of Ruth Lang, here is a summary of the two MMUSIC sessions 
that took place at the San Jose IETF.

---------------------

Monday 12/9

Mark Handley described significant modifications made to the Session
Description Protocol.  He then introduced the topic of representing
session capabilities (i.e., options from which to choose to create a
session as opposed to an instantiatable session as SDP describes now).
A strawman extension to the syntax of SDP was introduced along with a
couple of examples.  Questions arose from the group which identified
that "potential sessions" were not a well-understood concept.  Mark
proposed that the current draft of SDP be submitted as a proposed
standard, and that work begin to extend SDP to support capability
description.  Henning Schulzrinne objected to the latter in favor of
adopting a new syntax rather than extending SDP.  He also said that he
would raise an objection to the former if advancing the current SDP
draft implied that compatibility with it would need to be maintained
by a new session description format/protocol.

Ross Finlayson spoke briefly about the work of the Calendaring and
Scheduling Working Group and his work to encourage this group to adopt
conventions that will make their event descriptions compatible with
SDP.  He also identified areas of potential incompatibility which
implied that participation by MMUSIC in this WG is needed to ensure
compatible results.

Mark Handley described the significant modifications made to the
Session Announcement Protocol to create draft-ietf-mmusic-sap.00 (a
previous PS I-D existed but the lack of a txt version caused a reuse
of 00 for the 2nd version of the document).  Open issues were
identified and discussed which included security, generation of a
unique ID (guid's suggested as an option), and restricting SAP to
carry only SDP packets.

Mark Handley presented a "new" protocol, the Session Initiation
Protocol, which represents the unification of Handley/Schooler's
Session Invitation Protocol and Schulzrinne's Simple Conference
Invitation Protocol (all 3 are co-authors on this new draft).  This
protocol is specified to be carried over UDP or TCP, uses an HTTP-like
syntax and HTTP 1.1 status codes.  Open issues identified include:
defining UDP<->TCP proxy behavior, supporting capability requests,
adding additional support for transfers between telephone and
Internet.

Pete Cordell of British Telecom presented a description of research
work (no implementation) to develop the Simple Universal
Call/Conference Establishment Sequence Protocol.  It is a single
protocol for session management (cf the modular approach employed in
the specification of MMUSIC protocols) intended to support the range
of tightly to loosely controlled sessions.  It's call model is based
on a "hello-hello" paradigm.  Due to lack of time, not much discussion
on this protocol ensued.

Tuesday 12/10

Scott Petrack (Vocaltec, Inc.) provided an overview of the VoIP (Voice
on IP) Forum.  This is an IMTC group whose goal is to ensure and
promote industry-wide interoperability of Internet voice
communications products.  They will define technical guidelines for
two-party voice and other audio communications for compatibility with
traditional telephone service networks via telephony/IP gateways.

Rob Lanphier (Progressive Networks) and Anup Rao (Netscape
Communication) provided an overview of the Real Time Stream Protocol
(RTSP) and illustrated its use with a couple of examples.  

Henning Schulzrinne (Columbia U.) provided an overview of RTSP'.  An
alternative proposal inspired by the Netscape/Progressive work which
is more compatible with existing MMUSIC protocols and philosophy.

Open issues for real-time streaming were discussed which included text
vs binary representation of the protocol, stream control vs device
control, metafile/session descriptions, joining into existing
conferences, and multi-client control of streams.

   Sidebar discussions after the session defined a direction to unify the
   two drafts into a single proposal with RTSP' as the identified
   starting point for the work.  Lanphier and Rao will discuss this
   direction with their respective companies.  The chairs encouraged that
   after these discussion and potential follow-up discussions with
   Schulzrinne and/or MMUSIC co-chairs that they provide a summary for
   the MMUSIC community on the future direction of the protocol.

Akira Amamo (Hiroshima City University) presented the CamCoder Control
Protocol targeted for the control of video cameras and VCRs.  It is a
text-based protocol designed after ftp.  Christian Huitema suggested
that the authors consider writing an SNMP MIB for this purpose.  A
difference-of-opinion discussion about text vs binary protocol for
this purpose was cut short due to lack of time in the session.

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 18 Dec 1996 15:39:10 -0800 (PST)

>Session Announcement Protocol
...
>Open issues were
>unique ID (guid's suggested as an option)

I recall someone mentioning at the meeting that there existed a proposal
(I-D?) somewhere for uniform 128(?)-bit Internet-wide global unique ids
(presumably host id+timestamp+fudge).  Does anyone have a pointer to this
proposal?

        Ross.

---

From: David Oran <[email-masked]>
Date: Wed, 18 Dec 1996 20:00:18 -0500

>(presumably host id+timestamp+fudge).  Does anyone have a pointer to this
I was the guilty party. I suggested that UUIDs (Universal Unique
Identifiers) might be a really good solution for things like session
identifiers, CODEC identifiers (not payload types), and the like because
they have nice properties (both spacially and temporally unique), have both
a binary and a canonical textual representation, and theere is plaatofrm
support for generating them since they're used on a wide variety of
platforms (any Unix that supports OSF/DCE, any ActiveX (nee. OLE) compliant
platform like NT, etc.)

I'm in the process of obtaining the latest spec and checking with the
owners if there's any problem in using it as the basis of an internet
draft. I don't think there will be a problem (other than the finding some
time to write up the beastie.

Dave Oran

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]

---

From: Arlie Davis <[email-masked]>
Date: Thu, 19 Dec 1996 11:55:11 -0500

Using UUIDs is an excellent idea.  I whole-heartedly reccomend doing so.

-- arlie

>-----Original Message-----
>From:	David Oran [SMTP:[email-masked]]
>Sent:	Wednesday, December 18, 1996 8:00 PM
>To:	Ross Finlayson; [email-masked]
>Subject:	Re: MMUSIC summary
>
>identifiers, 
>[...]