2.8.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-03

Joerg Ott <jo@ipdialog.com>
Colin Perkins <csp@isi.edu>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: mmusic@ietf.org
To Subscribe: mmusic-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mailman/listinfo/mmusic
Description of Working Group:
The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) was chartered to develop protocols to support Internet teleconferencing sessions.  These protocols are now reasonably mature, and many of them have received widespread deployment. MMUSIC is now focussing on the revisions of these in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO).

All types of multimedia communications are based upon a common platform for expressing media streams (session) descriptions. This is the session description protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions, and have led to recognition of several flaws in the protocol design for key applications of SDP. MMUSIC will revise the SDP specification suitable for publication as a draft standard to address minor revision and further support the current broad deployment. Work on an SDP MIB will be considered.

Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings: However, these are limited to, adding means for identifying and semantically grouping media sessions, providing limited expressiveness for simultaneous capabilities, use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls, and documenting the use of SDP in SIP as a separate document. Existing key exchange per media session in SDP will be cleaned up in a revision of that portion of RFCxxxx. Apart from these, which are explicitly agreed to by the Area Directors and shown in the milestones, only extensions within the existing framework of SDP will be done -- such as registering new codecs and defining parameters for them extending SDP to include new address families.

To address the more fundamental issues with SDP, a next generation of SDP -- referred to as SDPng -- has been in progress and will be continued towards a standards track document. A requirements document will be devised that gathers the individual requirements from the areas in which SDP is currently deployed. Work on an SDPng MIB will be considered.

MMUSIC will continue to maintain and revise the specification of the Real Time Streaming Protocol (RTSP) based on implementation experience.  The RTSP spec will be revised to include various fixes and clarifications. Depending on the changes, the revised RTSP spec will be re-issued as Proposed or go to Draft Standard.  A MIB will also be defined.

The WG's work items will be pursued in close coordination with other IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING, IPTEL, MEGACO). Where appropriate, new separate working groups will be split off (as has happened with the SIP WG).

The Working Group is also charged with addressing security issues related to the protocols it develops.

Goals and Milestones:
Done  Conduct WG Last Call for SAP Internet-Draft
Done  Submit a revised Internet Multimedia Conferencing Architecture I-D.
Done  Submit a revised SIP I-D.
Done  Submit SDP to the IESG for consideration as a Proposed Standard.
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.
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.
Done  Submit IPv6 Extensions to SDP for Proposed Standard
Done  Submit SIP's offer/answer use of SDP for Proposed Standard
Done  Submit SDP4NAT for Proposed Standard (Informational?)
FEB 02  Submit revised SDP spec for Proposed (or Draft) Standard
FEB 02  Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.
MAR 02  Submit SDP key management for Proposed Standard
APR 02  `Submit SDPng base spec and audio profile for Proposed Standard
MAY 02  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
JUN 02  Submit SDPng video profile spec for Proposed Standard
JUL 02  Submit RTSP MIB for Proposed Standard
JUL 02  Conclude WG
  • - draft-ietf-mmusic-sdp-srcfilter-03.txt
  • - draft-ietf-mmusic-sdp-new-12.txt
  • - draft-ietf-mmusic-sdp-comedia-05.txt
  • - draft-ietf-mmusic-sdpng-06.txt
  • - draft-ietf-mmusic-sdp4nat-03.txt
  • - draft-ietf-mmusic-kmgmt-ext-07.txt
  • - draft-ietf-mmusic-sdpng-trans-03.txt
  • - draft-ietf-mmusic-rfc2326bis-03.txt
  • - draft-ietf-mmusic-reservation-flows-01.txt
  • - draft-ietf-mmusic-sdp-implem-00.txt
  • - draft-ietf-mmusic-sdp-bwparam-01.txt
  • - draft-ietf-mmusic-rtsp-nat-00.txt
  • - draft-ietf-mmusic-sdescriptions-00.txt
  • Request For Comments:
    RFC2326 PS Real Time Streaming Protocol (RTSP)
    RFC2327 PS SDP: Session Description Protocol
    RFC2543 PS SIP: Session Initiation Protocol
    RFC2974 E Session Announcement Protocol
    RFC3108 PS Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections
    RFC3259 I A Message Bus for Local Coordiantion
    RFC3264 PS An Offer/Answer Model with SDP
    RFC3266 PS Support for IPv6 in SDP
    RFC3388 PS Grouping of media lines in Session Description Protocol SDP

    Current Meeting Report

    Multipary Multimedia Session Control (MMUSIC) Working Group Minutes
    Reported by Colin Perkins
       The MMUSIC working group met once at the 56th IETF meeting in San 
    Francisco. The group discussed connection oriented media, various SDP 
    extensions, Offer/Answer examples, SDPng, Internet Media Guides, and RTSP.
    Introduction and Status Update
       Joerg Ott began the meeting with an introduction and status update.  One 
    RFC has been published since the last meeting (RFC 3388 on Flow 
    Identification), and one draft is with the RFC Editor 
    (draft-ietf-mmusic-reservations-flows-01.txt). The revision to SDP 
    (draft-ietf-mmusic-sdp-new-12.txt) is under AD review, as are drafts in the 
    RTCP attribute in SDP 
    (draft-ietf-mmusic-sdp4nat-03.txt) and the SDPng Transition 
    (draft-ietf-mmusic-sdpng-trans-03.txt). The SDP bandwidth parameters 
    (draft-ietf-mmusic-sdp-bwparam-01.txt) are in working group last call, and 
    comments are solicited.
       Joerg noted that the SDP specification has been revised due to Area 
    Director feedback. Colin Perkins described the changes: a number of minor 
    fixes to the ABNF, and significant updates to the description of the "k=" 
    field and the IANA Considerations section. The registration 
    requirements for attributes and other parameters have been 
    significantly tightened with this revision, and comments are solicited 
    regarding the degree to which these changes are appropriate.
       The SDP source filter draft 
    (draft-ietf-mmusic-srcfilter-03.txt) is essentially complete, just 
    needing editorial work. The chairs noted that they expect to issue 
    working group last call on this in early April, and that anyone with 
    comments should post them shortly. 
       There is a new draft on SDP implementation status and 
    (draft-ietf-mmusic-sdp-implem-00.txt), which is a first cut at the 
    documentation needed to advance SDP to draft standard. Please read and 
       The working group has completed its charter, and a draft for a 
    revised charter was sent to the mailing list prior to the meeting. This 
    draft is under discussion between the chairs and area director, and 
    comments are solicited from the group. It is expected that the revision 
    will include work on SDP, SDPng, RTSP and Internet Media Guides. 
    Conference Control has been ruled out of scope at this time.
    Connection-Oriented Media Transport in SDP
       David Yon discussed comedia 
    (draft-ietf-mmusic-sdp-comedia-05.txt). The changes in -05 include 
    removal of source address/port per discussion on the mailing list, and 
    removal of the current security considerations in preparation for a 
    revision in the next version (again, as discussed on the mailing list).
       David noted that the main security issue is session hijacking, which can 
    be solved by using secure media streams. In the absence of this, the 
    attack can be downgraded to a denial of service, if the endpoints follow the 
    rules in Section 4(b) and (c) of the draft, using duplicate incoming 
    connections as a signal of the attack (this works for TCP and 
    bidirectional RTP). Jonathan Rosenberg noted that using double connect as an 
    indication of an attack might fail in the presence of forking invites; this 
    needs further consideration.
       Next steps are to come to closure on the RTSP issues discussed on the 
    mailing list, and to fold in the expanded security considerations into -06. 
    Colin Perkins confirmed that the "eid" would be implemented as a 
    separate draft if needed. David expressed the hope that the -06 version 
    would be ready for working group last call.
    SDP key management extensions
       Elisabetta Carrara discussed changes to the key management 
    extensions work 
    (draft-ietf-mmusic-kmgmt-ext-07.txt).  The changes are primarily for 
    clarification, and include a more detailed description of the 
    interactions between SDP and the key management module, and rekeying.  In 
    addition, the IANA considerations section has been updated. 
       The main issue previously noted was a bidding down attack, which 
    Elisabetta described, but this has been solved in -07 by 
    authenticating the list of proposed key management protocols in the SDP. 
       Mark Baugher noted that another way to avoid the attack is to use only a 
    single key management protocol, to avoid the possibility of bidding. Ran 
    Canetti described how the attack is still valid in that case, since the bid 
    down can be done over multiple INVITEs with different protocols meaning 
    that the addition of authentication is the correct solution (even though it 
    complicates the protocol).
       It was asked if Kerberos still works with the changes? Elisabetta said it 
    should, but she would check to make sure. 
       Colin Perkins noted that approval is needed from the transport area 
    security advisor before this draft can advance, but that the changes 
    appear to address the previously open issues.
    SDP Security Descriptions for Media Streams
       Mark Baugher discussed SDP security descriptions for media streams 
    (draft-ietf-mmusic-sdescriptions-00.txt). The aim of this draft is to 
    replace k= with an attribute, suitable for signalling SRTP 
    parameters.  The draft is intended for applications where the 
    signalling channel is secure. If the signalling is hop-by-hop, as is 
    common with telephony, the intermediate hops must be trusted to 
    maintain security.
       Changes from 
    (draft-baugher-mmusic-sdpmediasec-00.txt) apply parameters to media 
    streams, not codecs (see discussion at the previous meeting); apply 
    parameters to the SDP media level only (as a result of improving 
    offer/answer); add an "application" parameter allowing separate 
    descriptions for SRTP and SRTCP; define use with offer/answer and 
    augment the ABNF.
       Next steps are to fix known problems, in particular the 
    ambiguities with SDP direction attributes, to generalize 
    offer/answer, and to generalize to transports beyond SRTP, and to get 
    implementation experience.
       Magnus Westerlund noted that RTSP doesn't currently define a secure 
    signalling channel. This will need to be fixed, if this work is to be used 
    with RTSP.
       Steve Casner asked if the semantics were well defined if more than one of 
    "k=", "a=keymgmt", and "a=crypto" are present? This is not legal, but 
    appropriate behaviour needs to be specified. It was asked how a system 
    should behave if the key is referenced by a non-secure URI? This is 
    clearly not appropriate use.
    SDP attribute for qualifying media formats with generic parameters
       Flemming Andreasen discussed 
    (draft-rajeshkumar-mmusic-gpmd-02.txt).  This is intended to provide an 
    alternative to "a=fmtp:", so that new parameters can be added to 
    existing media formats. The example being a voice-band data 
    parameter, to apply to codecs such as PCMU when used for modem or fax 
       Changes since -01 are to firm up the definition of the gpmd 
    attribute, clarifying that it is intended for informative hints, and that 
    lack of a gpmd parameters MUST NOT render the media format useless. Use 
    with offer/answer has also been specified, as have registration 
    procedures.  Ruediger Kreuter asked if an echo cancellor parameter has been 
    considered?  Flemming replied that there are many ways of specifying this - 
    see V.150 - how should it be specified? Colin Perkins noted that this 
    should be a new extension draft, rather than being including in the gpmd 
    draft, to avoid delaying the work. 
       The chairs asked for comments, noting that they intend to issue a 
    working group last call on this draft shortly.
    SDP Offer/Answer Examples
       Alan Johnston outlined 
    draft-johnston-mmusic-offer-answer-examples-01.txt which provides 
    examples of the use of the offer/answer model. There have been a number of 
    minor corrections and clarifications since the -00 draft, and the plan is to 
    continue collecting new scenarios and seek review and comment from 
    implementors. If you are implementing SIP and offer/answer, you are urged to 
    review the draft and send feedback.
    SDPng Update 
       Dirk Kutscher presented an update on the SDPng work 
    (draft-ietf-mmusic-sdpng-06.txt). Changes in -06 include a new document 
    structure, new requirements for capability specifications, new 
    capability negotiation rules, the removal of XML-Schema-based formal 
    definitions and text on session-level information.
       Capability specifications are now required to support feature 
    independent negotiation and must not require access to a package 
    definition in order to process capability descriptions. This requires 
    definition of a fixed set of basic types, encoding the type into values. In 
    addition, names must be fully qualified.
       Capability negotiation rules have been updated to describe the 
    general behaviour, leaving concrete behaviour implementation specific. Two 
    alternative procedures are specified: an offer/answer based scheme and an 
    RFC 2533 (conneg) style approach.
       Open issues include a concrete syntax definition, session level data, and 
    possible use of libraries of definitions. Next steps are to give details on 
    describing actual configurations and transport parameters, and a formal 
    definition mechanisms for packasges. Other work items include specific 
    package definitions (e.g. audio, video) and session level metadata.
    Internet Media Guides
       Rod Walsh outlined Internet Media Guides (IMGs), a potential new work 
    item for the group. An Internet Media Guide (IMG) is a collection of 
    multimedia session descriptions expressed using SDP, SDPng or some 
    similar session description format. It is used to describe a 
    collection of multimedia sessions (e.g.  television programme 
    schedules).  The IMG must be delivered to a potentially large 
    audience, who use it to join a subset of the sessions described, and who may 
    need to be notified of changes to the IMG.
       This problem lends itself to solution by (extensions of) some 
    existing mechanisms: SAP and SDP/SDPng. MMUSIC therefore seems the 
    natural home for the work. Other groups (e.g. DVB-IPI, TV Anytime, and the IP 
    datacast forum) have identified similar needs, but do not have the 
    experience to solve the problem. 
       The chairs presented some initial charter text discussing the problem 
    (subject to modification/approval from the area directors) and asked if the 
    working group considered this an appropriate work item? Strong support was 
       Magnus Westerlund discussed changes to the Real Time Streaming 
    (draft-ietf-mmusic-rfc2326bis-03.txt). The goal is to update and clarify the 
    RTSP specification, with the aim of moving to draft standard RFC (a new 
    proposed standard RFC may be required first, depending on the scale of the 
    changes). The aim is to have the core specification completed by October 
    2003. The new version will be a minimal core specification, with 
    extensions documents for NAT traversal, MUTE and UNMUTE and 
    (possibly) a MIB, RECORD, secure RTSP, and RTSP over unreliable 
       Since the previous meeting, there have been 5 teleconferences 
    discussing the spec (details announce on the mailing list or see 
    http://rtsp.org/).  A list of known bugs in the specification is also 
    maintained at 
       Changes updates discussed recently include:
       	- Non-persistent connection support is now mandatory
    	- IPv6 support added
    	- Accept-Ranges as proposed in the core spec
    	- Byte ranges will be allowed
    	- Via header will not be changed to include client address
    	- Clarification of 304 "Not modified"
    	- Clarification of redirection
    	- Agreed feature extension mechanism
    	- Strengthened requirements for Destination header
    	- Added source and destination addresses to the Transport header
    	- RTP-Info's base URL is a PLAY request URL
    	- Clarified interleaved usage
    	- A SETUP to change transport parameters leaves the previous state 
    intact if it fails
    	- Clarification that RTSP URLs are case sensitive
    	- Range header now required in all PLAY responses
    	- Range is formulated as start point (inclusive) to stop point 
    	- Use of PAUSE when in Ready clarified
       Open issues include how RTSP extensions registrations are to be 
    handled, and what are the requirements for new extensions; can timed 
    requests be removed; handling of multiple SSRCs in RTSP; and inclusion of a 
    warning header.
       Input from those working with RTSP was sought, since there is a 
    shortage of manpower on this effort.
    RTSP and NAT
       Magnus Westerlund discussed NAT traversal for RTSP 
    (draft-ietf-mmusic-rtsp-nat-00.txt). The issue is not RTSP signalling 
    itself, but how the media streams traverse the NAT, and how RTSP knows the 
    correct external addresses to use after NAT traversal. Will also address 
    cooperation with firewalls.
       The draft currently discusses use of STUN, symmetric RTSP, 
    tunnelled media in TCP and application level gateways. Open issues exist 
    with the use of STUN for symmetric NATs and symmetric RTP. Mark Baugher 
    asked if the authors have considered potential issues with secure RTSP? May 
    not be as simple as "just use SSL"? Philippe Gentric noted that the 
    attacker is often the client, so a secure channel may not help 
       Magnus asked for input, and is seeking a co-author to help complete the 
    Stream Switching Control
       Philippe Gentric discussed 
    draft-gentric-mmusic-stream-switching-00.txt, a new draft describing how a 
    server can signal that it is switching from one version of a stream to 
    another (for example, for coarse-grained rate adaptation, when the limits of 
    adaptation of a particular codec are exceeded).
       Alan Duric was glad to see the work, but asked if Philippe 
    considered the problem that routers may not be saturated due to 
    bandwidth, but due to packet rate? Maybe we should add a feature to 
    change packetization interval? Joerg Ott agreed that this is something to 
    consider, it's just another change in the media format.
       Magnus Westerlund asked if you can do other things than switch 
    streams for congestion control? Philippe said yes, streams can be 
    adapted in various ways, but this doesn't need protocol supoprt from RTSP.
       Ross Finlayson agreed that the concept was useful, but was unsure that 
    RTSP is the place to put the signalling? Will the TCP nature of RTSP delay 
    the congestion control signalling? Maybe use RTCP? Colin Perkins noted that 
    it is important to differentiate between indication of loss for a stream 
    (RTCP) and signalling to switch to a different stream (RTSP).
       Anders Klemets also liked the idea, but not the details. We have 
    standard ways of specifying alternates in SDP, maybe want to leave those 
    details out of this spec?
       Given the interest, it was agreed to move forward with this 
    discussion on the mailing 


    Internet Media Guides
    Update of RTSP
    Stream Switching Control
    Connection-Oriented Media Transport in SDP
    SDP Attribute for Qualifying Media Formats with Generic Parameters (gpmd)
    SDPng Update
    SDP Offer Answer Examples
    SDP Security Descriptions for Media Streams