Minutes from the Minneapolis MMUSIC meeting

[Colin Perkins <[e-mail]>]

Minutes of the MMUSIC working group
===================================

Reported by Joerg Ott and Colin Perkins
Notes taken by Tom Taylor (thanks!)

Slides can be retrieved from:
   http://www.dmn.tzi.org/ietf/mmusic/50/slides/mmusic-slides-pdf.zip
or http://www.dmn.tzi.org/ietf/mmusic/50/slides/mmusic-slides-ppt.zip

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, [e-mail]

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, [e-mail]

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, [e-mail]

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, [e-mail]

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, [e-mail]

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.