Current Meeting Report
Jabber Logs

2.8.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/23/2002

J. Ott <>
Colin Perkins <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe your_email_address
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  Submit SDP to the IESG for consideration as a Proposed Standard.
Done  Submit a revised SIP I-D.
Done  Submit a revised Internet Multimedia Conferencing Architecture I-D.
Done  Conduct WG Last Call for SAP Internet-Draft
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-01.txt
  • - draft-ietf-mmusic-sdp-new-10.txt
  • - draft-ietf-mmusic-fid-06.txt
  • - draft-ietf-mmusic-sdp-comedia-04.txt
  • - draft-ietf-mmusic-sdpng-05.txt
  • - draft-ietf-mmusic-sdp4nat-02.txt
  • - draft-ietf-mmusic-kmgmt-ext-05.txt
  • - draft-ietf-mmusic-sdpng-trans-01.txt
  • - draft-ietf-mmusic-rfc2326bis-01.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

    Current Meeting Report

    Multiparty Multimedia Session Control Working Group Minutes
    Reported by Colin Perkins
    The MMUSIC working group met once at the 55th IETF meeting in Atlanta.  We 
    discussed SDP key management and media security descriptions, media 
    format independent SDP parameters, SDP bandwidth modifiers, examples of the 
    offer/answer model, Internet Media Guides, XML schema for video control and 
    the revised RTSP specification.
    Agenda Bashing and Status update
    The meeting started with an introduction and status report by Joerg Ott.  
    The SIMCAP draft has been published as RFC 3407, and the FID draft is in the 
    RFC Editor's queue. The comedia, sdp4nat and SDPnew drafts are still with 
    the IESG. The draft on reservation flows is completing its working group 
    last call, and will be submitted to the IESG for publication as a 
    proposed standard immediately after the meeting.
    There have been minor changes to the SDP spec, to address comments from the 
    list. We are waiting for feedback from our area director before we can 
    progress this further. There has been no recent update to the SDPng 
    draft, but the authors are working on a new version that will have some 
    internal reorganization, will focus on the offer/answer model, and will 
    leave multiparty content-independent negotiation for a future 
    extension document. 
    The SDPng Transition draft 
    (draft-ietf-mmusic-sdpng-trans-02.txt) has been revised, and is largely 
    complete. Feedback is solicited, we plan to issue a working group last call 
    The SDP Source Filter draft 
    (draft-ietf-mmusic-sdp-srcfilter-02.txt) seems to be complete. Joerg asked if 
    a working group last call would be appropriate? There were no 
    objections, and a last call will be issued shortly. 
    The comedia draft is, in principle, complete but concerns have been 
    raised about applicability in the presence of middle-boxes. Joerg Ott 
    outlined his understanding of the issues. Jonathan Rosenberg disagreed with 
    Joerg's formulation: rather the issue is that there'a a strong coupling 
    between session lifetime and connection lifetime, and problems reusing 
    connections. This causes too much load and bad congestion state.  
    Jonathan suggested updating the comedia spec to address these 
    concerns.  Allison Mankin asked if this needs just a relatively small 
    change rather than an elaborate extension? Jonathan expected the changes to 
    be small.  Joerg Ott noted that we need to understand the muxing and 
    binding mechanisms. Jonathan agreed, since right now there are problems due 
    to NAT, firewalls, etc. Jonathan said he would produce a concrete 
    proposal on what needs to be changed in comedia "within a month", else we 
    will go ahead with the existing specification.
    Joerg noted that the working group charter is out of date. The chairs will 
    work on updated milestones and charter, to be circulated to the list for 
    comments. Suggested new work items may include Internet Media Guides and 
    Floor Control, but these need to be discussed with the area directors 
    before any decision is taken.
    MIKEY/Key Management with SDP
    Allison Mankin (Transport Area director) and Eric Rescorla (security 
    advisor for the transport area) outlined their concerns with the key 
    management model for SDP and the MIKEY draft. Eric's concern is the 
    binding between MIKEY and SDP, which allows multiple key management 
    protocols, such as IKE, S/MIME, etc. There is no protection against 
    downgrade attacks during the protocol negotiation. 
    Elisabetta Carrara noted that there is a recommendation in the draft to 
    choose between appropriate crypto-suites, but this did not satisfy Eric.  
    Jonathan Rosenberg said that his understanding is that using MIKEY with SDP 
    is not sufficient, the SDP will be protected with S/MIME anyway and hence 
    S/MIME provides the protection against downgrade attacks. Eric asked why, if 
    you have S/MIME already, do you need MIKEY? Elisabetta noted that we don't 
    commit to S/MIME, but Eric countered that, to have reasonable 
    security, S/MIME or similar protection is needed in addition to MIKEY. 
    Discussion continued for a while with no real resolution.  Allison Mankin 
    committed provide a written review of the draft, with detailed comments for 
    discussion on the list.
    SDP Security Descriptions for Media Streams
    Mark Baugher outlined the new draft on SDP Security Descriptions for Media 
    (draft-baugher-mmusic-sdpmediasec-00.txt). This is an alternative means of 
    exchanging keying material, to be used when the SDP message is securely 
    delivered. Accordingly it is expected to be complementary to key 
    management with MIKEY. 
    Mark outlined the limitations of the existing "k=" line, described the 
    proposed "a=crypto:" attribute, and outlined use with the 
    offer/answer model. Jonathan Rosenberg asked unclear why you'd want to do 
    separate security properties on a codec by codec basis since this seems to be 
    the cause of a lot of complexity? 
    Mark asked if this could become an MMUSIC work item. The chairs agreed that 
    the work is a good thing to do, but need to figure out the correct home for 
    SDP attribute for qualifying Media Formats with Generic Parameters
    Flemming Andreasen presented 
    draft-rajeshkumar-mmusic-gpmd-01.txt, the format independent parameter that 
    can apply to existing MIME types. He outlined the background to the 
    draft, signalling voice-band data, and noted issues with the current 
    draft: it is very open-ended and needs to be more limited in scope; it 
    needs to specify interactions with the offer/answer model; and it needs a 
    procedure for registration of new gpmd parameters. 
    Jonathan Rosenberg recommend that parameter specifications suggest the 
    actual interaction with offer/anser. He also suggested that we require new 
    parameters to be standards track.
    A Transport Independent Bandwidth Modifier for SDP
    Magnus Westerlund outlined 
    draft-westerlund-mmusic-sdp-bwparam-01.txt, on a new set of SDP 
    bandwidth modifiers that signal session bandwidth in a transport 
    independent manner. These are intended to solve problems due to NATs and 
    protocol translation, that make the existing parameters less than 
    Steve Casner noted that biggest open issue is whether we really need to 
    make the change at all? Magnus noted that the bandwidth can increase by 25% 
    with IPv6, compared with the value currently signalled, a compelling 
    argument for the new parameters. Steve disagreed, noting that the RTCP 
    bandwidth doesn't have to be that accurate, and that this level of 
    inaccuracy is unlikely to be problematic. He also said that a stronger 
    point is bandwidth allocaton for links, where it seems likely that for 
    tightly controlled channels, header compression will be used, so the 
    difference between v6 and v4 goes away. 
    SDP Offer Answer Examples
    Alan Johnston outlined 
    draft-johnston-mmusic-offer-answer-examples-00.txt, giving a series of 
    examples and scenarios for the use of offer/answer.  The group 
    expressed interest. Joerg Ott asked that the draft be expanded to give some 
    pointers to why the examples are correct.
    A Framework for Internet Program Guides
    Yuji Nomura discussed 
    draft-nomura-mmusic-pguide-framework-00.txt, a new framework for 
    Internet Program Guides that has evolved out of the drafts that were 
    discussed in Yokohama. There are a number of open issues: can this become a 
    charter item of MMUSIC? Revision of requirements? Choice of protocol for 
    announcements? Appropriate description format? 
    There was much discussion of the naming of the work, with many people 
    disliking the term "Internet Program Guide". It was decided to call the 
    work "Internet Media Guides" from now on.
    Joerg Ott noted that many description formats could be used, and that we 
    would not want to restrict ourselves to a single format. Similarly, we 
    would not want to define a new format within MMUSIC, but instead use the 
    existing solutions.  
    Henning Schulzrinne asked that we take a step back to see what we learnt 
    from SAP. Other things have happened in the space of event 
    notification, and SAP hasn't been a clear success because of the service 
    model, etc.  We want to revisit, and see what we've learnt.
    The chairs noted that this work is not within the MMUSIC charter. They will 
    work with the area director, to determine if MMUSIC is appropriate for this 
    work, or if it should occur elsewhere.
    XML Schema for Media Control
    Orit Levin outlined 
    draft-levin-mmusic-xml-media-control-00.txt, an XML schema for media 
    control. Orit noted that several alternative approaches have been 
    discussed previously (CODEC specific RTP/RTCP primitives, RTCP feedback as 
    for loss recovery, SDP extensions) but rejected for various reasons. They 
    therefore propose the use of an XML scheme conveyed using a reliable 
    protocol. The primitive commands are "picture fast update", "GOB fast 
    update", "MB fast update" and a "picture freeze" command. This is 
    encapsulated in the SIP INFO method, and next steps are to define the 
    Steve Casner noted that he is sure an XML schema can be defined for this 
    purpose. A more critical question might be how it is transported, and if the 
    result will work. Rohan Mahey noted "if I could go back in time and undo 
    INFO, so it didn't exist, I'd be very happy". He noted the issue is that 
    this is media oriented, and should be sent with the media. Asked if some 
    form of RTCP based approach might be more appropriate?
    Henning Schulzrinne expressed concern about re-inventing SOAP on the sly. 
    Besides asking whether this belongs in SIP or not, we don't need yet 
    another RPC protocol. If it is an RPC mechanism we should ask how we can 
    make exisitng RPC solutions work in this context? He also asked if there is a 
    need for a traditionally reliable mechanism, and how it relates to other 
    work on, for example, floor control?
    Nermeen Ishmail noted that there is a real problem of using SIP, since if 
    you lose the control path, you lose the media. This leads towards using 
    RTCP, but there is an interoperability problem with that since H.323 
    systems convey this information in the control path. Accordingly, we 
    should steer away from RTCP, and use a media control protocol. There was 
    concern that this would not work either, due to the latency of the 
    control channel.
    Jonathan Rosenberg noted that this might be a perfect candidate for a SOAP 
    protocol, signalled in SDP? Henning agreed that SOAP works today, but 
    there is a need for a way of associating SOAP connections with a media 
    stream, in SDP. Orit asked where should we do SOAP work, since it is 
    unclear if MMUSIC is the appropriate forum? The answer seems to depend on 
    the form of the final solution.
    RTSP Update
    Magnus Westerlund outlined recent changes to the revised RTSP draft 
    (draft-ietf-mmusic-rfc2236bis-02.txt) and gave a pointer to the bug 
    tracker at He asked for the group to 
    review the updated specification, and noted that teleconferences to 
    discuss changes will resume shortly. He also outlined major open issues.
    This first open issue is redirect: shall the server be allowed to close a 
    session as soon as the clients ACKs the REDIRECT? And what should be done 
    with the 3xx codes? 
    Magnus noted that the authors are lacking experience with RECORD. It seems 
    that the spec needs significant clarifixation on how to use it, and that 
    there are many open issues. Input was requested from someone who has 
    implemented RECORD, otherwise the authors proposed to remove it from the 
    base specification (leaving it as an extension document). Steve Casner said 
    he was pretty sure that IP/TV used RECORD, and that this may provide 
    implementation experience? Rob Lanphier explained that we need people to 
    document what they're doing with RECORD, not just to list 
    implementations. Henning Schulzrinne asked if the issues with RECORD might be 
    somewhat similar to WEBDAV style protocols, and if experience in that 
    field may be helpful? 
    Other open issues exist with Appendix C, the Accept-Ranges header, the Via 
    header, Negative Scale, TLS support, RTSP over UDP, etc. A bar BOF was 
    scheduled for later in the week to discuss these, and discussion will 
    continue via the mailing list and teleconferences.


    A Framework for Internet Program Guides
    RTSP to Draft Standard
    Transport Independent SDP Bandwidth Parameter
    SDP Offer Answer Examples
    SDP attribute for qualifying Media Formats with Generic Parameters (gpmd)
    XML Schema for Media Control
    SDP Security Descriptions for Media Streams