NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Joerg Ott <jo@tzi.uni-bremen.de>
Colin Perkins <csp@isi.edu>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Allison Mankin <mankin@east.isi.edu>
General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail
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.
Done |
|
Conduct WG Last Call for SAP Internet-Draft |
Done |
|
Submit a revised Internet Multimedia Conferencing Architecture I-D. |
Done |
|
Submit SDP to the IESG for consideration as a Proposed Standard. |
Done |
|
Submit a revised SIP I-D. |
Aug 97 |
|
Submit a revised ITU Interoperability Scenarios I-D. |
Done |
|
Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol. |
Done |
|
Conduct WG Last Call for RTSP Internet-Draft. |
Done |
|
Submit Internet-Draft on Internet Multimedia Conferencing Architecture. |
Nov 97 |
|
Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC. |
Done |
|
Submit RTSP to IESG for consideration as a Proposed Standard. |
Done |
|
Conduct WG Last Call for SIP Internet-Draft. |
Done |
|
Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard. |
Done |
|
Conduct WG Last Call for SAP Security Internet-Draft. |
Done |
|
Conduct second WG Last Call for SAP. |
Done |
|
Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard. |
Done |
|
Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard. |
· Simple Conference Control Protocol
· A Message Bus for Local Coordiantion
· Describing session directories in SDP
· Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections
· TCP-Based Media Transport in SDP
· SDP: Session Description Protocol
· Connection-Oriented Media Transport in SDP
· Requirements for Session Description and Capability Negotiation
· An Mbus Profile for Call Control
· The Message Bus: Guidelines for Application Profile Writers
RFC |
Status |
Title |
RFC2326 |
PS |
Real Time Streaming Protocol (RTSP) |
RFC2327 |
PS |
SDP: Session Description Protocol |
RFC2543 |
PS |
SIP: Session Initiation Protocol |
RFC2974 |
E |
Session Announcement Protocol |
Minutes of the MMUSIC working group
===================================
Reported by Joerg Ott and Colin Perkins
Notes taken by Tom Taylor (thanks!)
The MMUSIC WG met once at the 50th IETF (Thu 1530-1730). The meeting was chaired by Joerg Ott and Colin Perkins and was attended by some 60 participants. It is noted that MMUSIC was scheduled in parallel to SIMPLE despite both WGs requested non-overlap with the other; this way core core contributors to both groups had to decide on one of them.
MMUSIC WG Update
----------------
Joerg Ott, jo@ipdialog.com
Joerg gave a brief update on the WG status: the ATM extensions for SDP are now with the RFC editor, the Multimedia Conferencing Architecture is going to historical. The Mbus transport will be re-submitted shortly and then be Last Called for Experimental. The work on RTSP is continuing; an update will be given at the next IETF in London.
As per discussion with the ADs, conference control (which has been on the charter with little interest from the community for many years) is considered out of the scope of MMUSIC. Joerg noted recently growing interest in this area; interested parties are requested to consult with the MMUSIC chairs and the Transport ADs for initiating work on this subject in the IETF. MMUSIC is not going to accept new work items but if there is sufficient interest, the WG chairs will work with the ADs to find another home for this work.
SDP revision
------------
(draft-ietf-mmusic-sdp-new-01.txt)
Colin Perkins, csp@isi.edu
Colin briefly summarized the revision process of SDP (RFC 2327); he has received little input on corrections to SDP since the last IETF.
The latest draft of the revised SDP has just been submitted. There are few changes since the last one, including:
"b=" modifiers
"m=" may have multiple ports if "c=" has multiple addresses
Both were motivated by RTP specification updates.
Colin was asked if there would be a grammar update since there are issues with IPv6 addresses and probably other errors as well. The answer is yes, if bugs are found.
For all corrections to the revised SDP spec, people are requested to provide detailed wording changes and send them to the list.
Simple Capability Negotiation for SDP
-------------------------------------
(draft-andreasen-mmusic-sdp-simcap-reqts-00.txt,
draft-andreasen-mmusic-sdp-simcap-01.txt)
Flemming Andreasen, fandreasen@microsoft.com
Flemming Andreasen presented his progress on the simple capability negotiation mechanism for SDP. As well known, the basic SDP does not provide means capability negotiation; Flemming's proposal adds such a feature in a minimal and backward compatible fashion. This shall allow for a smooth migration path of the installed base of devices using SDP. As agreed at the 49th IETF, Flemming has created a separate document in addition to the specification itself that more explicitly describes the motivation and summarizes the requirements for this work.
The simple capabilities specification document is considerd ready for WG Last Call which will be issued shortly.
SDP Media Flow Identifiers
--------------------------
(draft-ietf-mmusic-fid-00.txt)
Gonzalo Camarillo, Gonzalo.Camarillo@ericsson.com
Gonzalo Camarillo discussed the changes to the Flow ID specification. The "fid" attributes define media flows -- they allow to make up a single logical media flow from multiple RTP sessions, e.g. tones vs. voice. This permits switching behaviour based on codec currently in use. The current revision has incorporated input from the last IETF and has clarified definitions from previous draft.
The optimizations included for SIP session establishment will be removed from the next revision of the document since they are in conflict with the latest revisions of the SIP spec (SDP is no longer allowed in all three messages INVITE, 200 OK, and ACK). This will not alter the basic functioning of the fid attribute.
The fid attribute does not interact with the simple capability negotiation mechanism presented before -- but the fid attribute can be used to express alternatives.
The document will be redrafted after the IETF. The chair noted concerns with clarity of text which will be addressed. Gonzalo will resubmit the document in the weeks to come. A WG Last Call will follow.
As a general point with respect to SDP, Joerg urged that, besides the two current SDP additions that are close to finalization, no further modifications shall be made to SDP; instead, only SPDng shall be used to gain additional functionality.
SDPng Requirements and SDPng syntax
-----------------------------------
(draft-ietf-mmusic-sdpng-req-00.txt)
Dirk Kutscher, dku@tzi.uni-bremen.de
Dirk Kutscher discussed the (sligtly revised) requirements of SDPng; the document incorporates various comments received since the last IETF (during a Bar BOF, during the second MMUSIC WG session at the last IETF, and afterwards on the mailing list). Further comments received at this meeting will be included in the next revision. It was noted that the MEGACO WG is to contribute its own requirements on SDPng (which is likely to become a charter item of a new MEGACO WG charter).
Dirk then outlined a first cut at the XML-based syntax proposal for SDPng. This document did not make the Internet Draft deadline but will be submitted soon after the meeting in its initial revision.
XML has been chosen as as basis because it already provides the desirable language features -- a way to structure information, definition mechanisms allowing for formal validation, and a namespace concept -- so that there is little reason to develop a new language from scratch.
The overall structure follows the general model already presented at the last IETF, consisting of four sections:
(1) Optional definitions section
(2) Potential and act configs, corresponding to SDP m= lines and attributes
(3) Optionak Constraints section
(4) Session attributes, roughly ressembling SDP session definitions
The definitions section contains definitions of abstractions for later re-use e.g. codecs, redundancy schemes, transport mechanisms, etc. The configurations section combines definitions from the first section (and may, optionally, introduce new ones). Definitions and configurations are labelled for later referencing. The constraints section will allow to pose restrictions on the combinations of configurations (e.g. limit the number of instances a certain codec may be used or allow only certain combinations of codecs).
External packages may be used to formally provide "well-known" definitions of codecs, transport mechanisms, etc. -- e.g. include all the information currently in the RTP profile in terms of SDPng. External packages may also specify constraints and other rules to be imported by SDP definitions (so that the actual size of a message may be limited). A registry needs to be set up to allow independent development of SDPng packages. Registrations should also help avoiding name collisions in conjunction with using the XML namespace concept.
Two ways are conceivable to refer to certain (well-known) SDPng packages: in-line inclusion of the referenced definitions allows for self-contained messages and thus independence of prior external agreements; built-in definitions (in each implementation) in contrast will minimize the message size. A comment was made that concerns with size of SIP messages may eventually guide the selection.
SDPng packages may be specified either by means of DTDs or XML schemas. No decision has been taken on this issue yet.
Concern were expressed about the code size for an SDPng implementation. Joerg noted that a minimal message parser need not be full XML parser. It was also mentioned that the XML people have worked to keep size down and XML parsers already part of 3GPP.
Dirk went through an example of an SDP message covering all four sections (see slides).
The next steps on SDPng include working out the details of the definition mechanism, specifying the SDPng packages for the most common cases (presumably starting from the RTP profile), describing the mechanism for capability negotiation, and publishing the initial draft for SDPng as soon as possible.
A comment was made to consider the need to carry information about a conference, policy information, etc. Joerg pointed out that conference control is likely to be just another "media type" with a self-contained package description and thus all extension mechanisms to initiate and parameterize a conference control session are in place.
Again, concerns were raised on message size were raised, particularly from the experience with SIP, where the message size pushed from people from using UDP to using TCP. From this, a need for a minimal description for basic case was expressed. The authors noted that they are very much aware of this requirement.
There is quite some work to be done on SDPng. As stated above, the draft spec will be made available as soon as possible. Input on SDPng is solicited.
Agenda
The fid attribute
SDPng Model and Strawman Syntax
SDPng Requirements Update
SDP Simple Capability Negotiation