2.7.7 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 31-Jul-98

Chair(s):

Ruth Lang <rlang@sri.com>
Eve Schooler <schooler@cs.caltech.edu>
Mark Handley <mjh@east.isi.edu>
Joerg Ott <jo@tzi.uni-bremen.de>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Vern Paxson <vern@ee.lbl.gov>

Mailing Lists:

General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

- distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP),

- providing security for session announcements -- SAP Security,

- controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP),

- initiating sessions and inviting users -- Session Initiation Protocol (SIP), and

- managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332).

The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP.

Goals and Milestones:

Jul 97

  

Conduct WG Last Call for SAP Internet-Draft

Jul 97

  

Submit a revised Internet Multimedia Conferencing Architecture I-D.

Jul 97

  

Submit SDP to the IESG for consideration as a Proposed Standard.

Jul 97

  

Submit a revised SIP I-D.

Aug 97

  

Submit a revised ITU Interoperability Scenarios I-D.

Aug 97

  

Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.

Oct 97

  

Conduct WG Last Call for RTSP Internet-Draft.

Oct 97

  

Submit Internet-Draft on Internet Multimedia Conferencing Architecture.

Nov 97

  

Submit RTSP to IESG for consideration as a Proposed Standard.

Nov 97

  

Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC.

Jan 98

  

Conduct WG Last Call for SIP Internet-Draft.

Feb 98

  

Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 98

  

Conduct WG Last Call for SAP Security Internet-Draft.

Apr 98

  

Conduct second WG Last Call for SAP.

May 98

  

Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.

May 98

  

Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2326

PS

Real Time Streaming Protocol (RTSP)

RFC2327

PS

SDP: Session Description Protocol

Current Meeting Report

MMUSIC Minutes from the Chicago IETF

Reported by Eve Schooler, Mark Handley, and Joerg Ott

Colin Perkins
- made a brief presentation on changes to the SAP security specification made as a
result of comments on the mailing list.

Mark Handley
- will merge the security spec with the base spec and submit this to the IESG to
become an experimental standard before the next IETF.

An issue was raised whether these changes to the SAP specification required the
version number to change; the previous version of the draft had inadvertantly changed
the version number.

Mark Handley
- pointed out that implementations of the previous SAP security did not exist so
that the existing version number could be re-used.
- summarized the status of SIP: we have completed WG last call and submitted the
spec to the ADs.

The ADs felt that performing IETF last call over the IETF was a bad idea so delayed
that until after the IETF.

In the meantime a couple of errors had shown up in the SIP spec. Besides pure editorial
errors such as the consistent use of IETF standards terminology and the need for some
explanatory clarifications, a couple of functional errors were discovered.

Henning Schulzrinne described these errors and the proposed solutions including the
following:

- A new error code was added to allow distinction between a busy signal from one
(out of many) call legs from a (final) busy signal (on the single or all legs) of a call.
- An expiration field was added to the "Location" header to allow reporting
independent reporting of different expiration times for each location.

Finally, an open issue was reported with respect to the "Location" syntax: in SIP, a
"Location" header may be following by several URIs each which associated parameters --
the separator between them being commas and semicola, respectively. In case a URI
contains either of the separating character (which is unlikely but possible), this will result
in misinterpretation of the "Location" header.

Proposed solutions include quoting each URI, allowing only a single URI per "Location"
header, and using '<' and '>' as delimiters for the URI similar to the mail address format,
and changing the name of the header. The rough consensus was to change the name of
Location to Contact and to allow '<' and '>' as delimiters.

A new ID will be submitted as soon as the ID editor is accepting Ids again, and we will
ask the ADs to do IETF last call on this revised spec instead. The consensus in the
room was that the changes were small enough that we didn't need to repeat WG last call.

Colin Perkins
- presented a proposal for a local message bus for local area conference coordination,
similar to the
- LBL conference bus, CCCP and PMM.

Such a proposal was first made in MMUSIC at the 1994 Seattle IETF and has been
discussed occasionally since. There seemed to be a lot of interest in this proposal now.
It is not clear that this should be an MMUSIC work item though, as it has the potential
to be used for more general purpose local coordination. The rough consenus was that
work on this should continue, and that we should consider holding a BOF at the Orlando
IETF to see if the interest is general enough to form a new WG.

The authors of the Mbus documents agreed to consider the implications of a broadened
scope of the Mbus with respect to their design decisions as well as the potential overlap
with other WGs (or BOFs) in the IETF before deciding on requesting a BOF for the
43rd IETF.

Philip Hoschka
- presented a proposal for a syntactic mapping of SDP into SMIL (W3C's
Synchronised Multimedia
- Integration Language).

The rough consensus was that this was the wrong approach -- SDP is quite limited
and there is no reason why these limitations should be perpetuated in SMIL. Instead,
a description language much more powerful than SDP would be desirable in many
cases. It was also pointed out that providing SMIL definitions that follow what is in
SDP faces the problem of a SDP being a moving target: this would lead
to this part of SMIL always being slightly out-of-sync with SDP and may even result
in diverging specifications. Inclusion or referencing SDP as is was conceived a more
suitable alternative. However, we want to ensure that the IANA registry used for SDP
can also be used for SMIL so the two should share some common syntax.

Francois Menard
- presented some ideas for using XML in the context of SIP for conveying more
general information such as settlements.

This wasn't a specific proposal -- more a heads up for people to think about this possibility.

Kenji Fujikawa
- presented a proposal for SIP URLs.

Mark Handley
- presented the reasons why he thinks this is a bad idea.

Much discussion ensued which was curtailed because we ran out of time, but the
consensus appears to be that is this a bad idea and should not be persued. If you
absolutely need this information in a URL, use the data URL instead. But preferably
don't do it at all.

Slides

The Message Bus
Integrating SDP Functionality into SMIL
SDP URL Scheme
SIP: Changes based on WG last-call
Why SDP URLs are a Bad Idea

Attendees List

go to list