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.