2.8.7 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Joerg Ott <jo@acm.org>
Colin Perkins <csp@csperkins.org>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
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 and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. The group is now focussed on the revisions of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP,SIPPING, and MEGACO).

Multimedia communications protocols use a common platform for expressing media and 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. In spite of these, it is widely deployed.

- To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification.

- Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls, exchange of media session security keys.

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 (e.g. 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 Proposed Standard RFC. A requirements document will be devised that gathers the requirements from the areas in which SDP is currently deployed.

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

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.

MMUSIC will investigate work on delivery mechanisms for IMGs, generalizing its work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly

The MMUSIC 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 may 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?)
Done  Submit SDP source filter extensions for Proposed Standard
May 03  Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.
Done  Submit revised SDP spec for Proposed (or Draft) Standard
Aug 03  Submit SDPng base spec profile for Proposed Standard
Oct 03  Submit IMG requirements and framework for Informational
Oct 03  Submit SDP Offer/Answer examples for Informational
Nov 03  Submit SDPng video profile spec for Proposed Standard
Nov 03  Review work on IMGs and update charter accordingly
Nov 03  Submit SDP security extension for Proposed Standard
Nov 03  Submit SDPng RTP profile spec for Proposed Standard
Nov 03  Submit SDPng audio profile spec for Proposed Standard
Apr 04  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
Jun 04  Submit RTSP MIB for Proposed Standard
  • - draft-ietf-mmusic-sdp-srcfilter-05.txt
  • - draft-ietf-mmusic-sdp-new-15.txt
  • - draft-ietf-mmusic-sdp-comedia-05.txt
  • - draft-ietf-mmusic-sdpng-07.txt
  • - draft-ietf-mmusic-kmgmt-ext-09.txt
  • - draft-ietf-mmusic-sdpng-trans-04.txt
  • - draft-ietf-mmusic-rfc2326bis-05.txt
  • - draft-ietf-mmusic-sdp-implem-00.txt
  • - draft-ietf-mmusic-sdp-bwparam-05.txt
  • - draft-ietf-mmusic-rtsp-nat-01.txt
  • - draft-ietf-mmusic-sdescriptions-02.txt
  • - draft-ietf-mmusic-offer-answer-examples-01.txt
  • - draft-ietf-mmusic-img-req-00.txt
  • - draft-ietf-mmusic-ice-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
    RFC3524 PS Mapping of Media Streams to Resource Reservation Flows
    RFC3605StandardRTCP attribute in SDP

    Current Meeting Report

    2004.58th IETF: MMUSIC Minutes
    Reported by Tom Taylor 
    <mailto:taylor@nortelnetworks.com> and Colin Perkins.
    MMUSIC met on Friday morning, November 14. The meeting was chaired by 
    Jörg Ott 
    <mailto:jo@informatik.uni-bremen.de> and Colin Perkins 
    The agenda was accepted with two minor changes: a discussion of Source and 
    Sink SDP attributes was added, and the discussion of SDP parameters for 
    H.263 and H.261 options took place in AVT instead.
    Introduction and Status Update
    Jörg Ott gave an introduction and status update. The working group has had 
    one RFC published since the last meeting: the RTCP attribute for SDP (RFC 
    <http://www.ietf.org/rfc/rfc3605.txt>), and 
    draft-ietf-mmusic-sdpng-trans-04.txt is with the RFC Editor. The IESG has 
    draft-rajeshkumar-mmusic-gpmd-03.txt and suggested some changes. The 
    authors are considering these, and will produce an update.
    Colin Perkins has updated the revision to SDP 
    (draft-ietf-mmusic-SDP-new-15.txt) to reflect IESG comments, 
    implementing the changes suggested at the 57th IETF meeting. The working 
    group was urged to review the draft to make sure the latest changes 
    haven't broken anything. Some discussion took place:
    * There was a question on the time scale for SDP-new approval. The chairs 
    expect an immediate WG review, then off to the IESG. Volunteers were 
    requested for an in-depth review. They were asked to send an E-mail to 
    Joerg to indicate that they were volunteering.
    * Jon Peterson 
    <mailto:jon.peterson@neustar.biz> indicated that he was still worried 
    about the "k=" line text. The problem is that the existing text has a 
    normative dependency on informative text: "SHOULD NOT use in absence of 
    <informative refs>".
    * There is a problem with the text media type: it's widely used, and 
    referenced in RFC 2327 
    <http://www.ietf.org/rfc/rfc2327.txt>, but got missed from the 
    original IANA registry for SDP top-level types. We could do it 
    indirectly by putting it into SDP-new. Interested parties are asked to send 
    text to be added to sdp-new for the purpose. Future SDP extensions are 
    strongly discouraged by the WG charter.
    * Semantics are undefined for multiple "m=" lines with the same port and 
    "c=" The interpretation should go into the SDP-new draft as a 
    clarification. There are minor implications on the offer-answer 
    examples. Gonzalo Camarillo 
    <mailto:Gonzalo.Camarillo@ericsson.com> sent some text, but for a 
    different case (hierarchical encoding). Flemming Andreasen 
    <mailto:fandreas@cisco.com> proposed that we simply prohibit this 
    construct. The meeting agreed to the prohibition.
    The source filter 
    (draft-ietf-mmusic-sdp-srcfilter-05.txt) and comedia 
    (draft-ietf-mmusic-sdp-comedia-05.txt) drafts have been reviewed by the 
    area director, and need to be updated. The new SDP bandwidth 
    (draft-ietf-mmusic-sdp-bwparam-05.txt) are with the area director, and an 
    IETF last call is expected shortly.
    Internet Media Guides
    Yuji Nomura <mailto:nom@flab.fujitsu.co.jp> discussed requirements for 
    Internet Media Guides 
    (draft-ietf-mmusic-img-req-00.txt). There are lots of changes in the 
    latest revision of the requirements draft. A new background and 
    motivations section has been added. The editor moved in the problem 
    statement from the old framework draft, but shortened it. Congestion 
    control has been added as a requirement. Security considerations were 
    added. For the next revision:
    * requirements will be numbered
    * terminology will be modified for consistency
    * clarifications have been requested: many more receivers than senders; 
    senders continually connected, not receivers; and the tradeoff between 
    customization and scalability
    The revised draft is coming out in the next few weeks. The authors expect it 
    to be ready for Last Call shortly after that.
    Pekka Luoma 
    <mailto:juha-pekka.luoma@nokia.com> discussed the IMG framework 
    (draft-nomura-mmusic-img-framework-02.txt). This is an individual 
    submission, since it missed the cutoff; a working group draft will be 
    submitted shortly after the meeting. Changes from the last version are as 
    * The use cases in the latest version of the draft were extended to 
    include content-oriented use cases.
    * A section has been added to discuss the applicability of existing 
    * New section 6.3 summarizes the outstanding needs that existing 
    protocols do not seem to supply:
      o need for a multicast transport protocol
      o need to specify how to use specific unicast transport protocols in this 
      o specification of the "metadata envelope", a new term for an 
    existing concept in the framework that gives independence from 
    transport protocol and metadata format
      o agreement on the basic metadata models (informative only)
    Next steps are an editorial cleanup and a new section outlining what 
    pieces of the work are in IETF scope (the transport protocols and 
    transfer envelope) and out of scope (the data models and application 
    specific metadata). It was suggested that an IMG metadata identifier is 
    needed, likely a URI to differentiate between complete 
    specification, delta, and filter. Jörg suggested avoiding the term 
    "metadata" altogether, since it causes confusion.
    Magnus Westerlund 
    <mailto:magnus.westerlund@ericsson.com> remarked that this was not 
    exactly a framework document. Colin suggested an offline discussion on this 
    point. Magnus will comment by E-mail.
    Rod Walsh <mailto:rod.walsh@nokia.com> indicated that whether changes use 
    the same syntax as the original announcements is still an open 
    question. It is not clear how reusable the syntax may be.
    Target is to have WG Last Call in December.
    Other issues
    Rod Walsh outlined some open technical issues and design choices 
    relating to the IMG work:
    * There are a number of design choices for transport protocols; for 
    multicast, ALC/FLUTE is a very good candidate.
    * The Subscribe (unicast) model can be handled by SIP and SIP events.
    * The Metadata Envelope could be: a. XML file/wrapper, or b. header 
    extension of transport protocols. Both?
    * Data types and channelization: could correlate data type and 
    transport channel? Or could divide delivery over multiple channels?
    There is a middlebox authentication and integrity issue, since a 
    middlebox could invalidate the sender signature in some cases (by 
    performing header modification). Various possible solutions exist: 
    trusted middlebox; middlebox could inform the sender of its change and 
    request re-signing; middlebox could sign the data. Jonathan Rosenberg 
    <mailto:jdrosen@dynamicsoft.com> asked whether in this discussion 
    "middlebox" connoted a NAT or firewall, or whether it simply meant some 
    router in the abstract? Rod confirmed that the latter meaning was 
    intended. Jonathan advised him not to call it a middlebox, to avoid 
    Alternative IP versions for SDP
    Gonzalo Camarillo 
    <mailto:Gonzalo.Camarillo@ericsson.com> outlined the Alternative IP 
    Versions Semantics for the SDP Grouping Framework 
    (draft-camarillo-mmusic-alt-02.txt). The proposed IPV extension is 
    backward compatible. Dual-stack hosts are strongly encouraged to 
    implement IPV. The question is whether to make it a WG item?
    Flemming Andreassen suggested that text was needed to clarify the 
    relationship to ICE. He noted that the key point of the extension is to 
    avoid establishing multiple media streams. That said, could the 
    extension be applied to abstract properties, beyond IPv4 vs IPv6? 
    Gonzalo confirmed that it could. Jonathan Rosenberg affirmed that the 
    draft does need text to make the relationship to ICE clear. It was 
    suggested that IPV may not be the appropriate name.
    The consensus of the group was to make this a WG draft.
    Source and Sink SDP attributes
    Gonzalo Camarillo 
    <mailto:Gonzalo.Camarillo@ericsson.com> discussed SDP source and sink 
    (draft-camarillo-sipping-transc-3pcc-00.txt). This draft came from the 
    transcoding design team in SIPPING. It deals with a problem in the 
    routing of media types, which is really a service location problem.
    Jörg suggested that this was really a small subset of the XCON WG topic 
    area. The draft raises a potential problem: signalling by SDP could 
    conflict with other media policy mechanisms. Gonzalo agreed that the team 
    would clarify whether should use the more general mechanism or whether this 
    one is justified.
    Security Descriptions
    Flemming Andreassen reviewed the changes in the latest revision of the 
    security descriptions draft 
    (draft-ietf-mmusic-sdescriptions-02.txt). The draft has been 
    generalised into a core framework and an SRTP specific part, and 
    numerous editorial changes and clarifications have been included. In 
    detail, the changes are:
    * offer/answer highlights differences between 
    unicast/multicast and the initial/subsequent offer
    * rekeying is addressed via offer/answer; everything can be changed
    * additional rules and considerations for communicating the SRTP SRC 
    * removed the SRTP "use" parameter, which is now inferred from context
    * added Window-Size Hint and <From,To> to SRTP profile
    * more rules for extensions...
    * updated IANA considerations and grammer
    There are still four open issues. Issue 1 was with multicast:
    * Shared vs. per-participant key?
    * When a key is shared, the streams need unique SSRCs per 
    * If per-participant keys are used, each participant has to convey 
    his/her key separately.
    * How to support for hierarchical layered encoding schemes is another 
    multicast issue.
    Flemming was not sure there is a single good solution. The proposal was 
    made that multicast streams should be left for further study, and not 
    included in this draft. Jon Peterson wondered if we had found the 
    logical dividing line between unicast and multicast. Jonathan 
    Rosenberg wanted to be sure the solution is mature before deciding this. 
    Jörg indicated that he would like to progress the draft, since it 
    addresses fairly urgent issues. There was agreement that it was 
    reasonable to leave multicast for further study.
    Issue 2 was several problems with respect to the SRC parameter. Most of 
    them are multicast based, hence can be left aside for now. There are still 
    the questions of:
        * how many crypto contexts can sdescriptions establish?
        * handling SSRC collisions.
    There was a suggestion to remove the SSRC part and support single 
    context only. However, Magnus Westerlund pointed out that you can get 
    multiple SSRC from the same host. The decision was therefore to keep the 
    SSRC part in the document for the moment.
    Issue 3 (on Flemming's slides) was purely multicast, and so was 
    Issue 4 was the "Use" parameter which was removed, since it led to 
    complexity and could be inferred from context. Is there any need for it? No 
    feedback from the room - please read and comment.
    Flemming expects to provide an update by December. There are no other 
    known issues. Should it go to WG Last Call? Need volunteers to give it a 
    thorough review. Magnus volunteered on the spot. Jon Peterson is to 
    organize as Security Area review.
    Security Preconditions
    Flemming Andreassen outlined
    draft-andreasen-mmusic-securityprecondition-00.txt on security 
    preconditions. The problem: an ambiguity in security description 
    selection. There is a need to block sending until the ambiguity is 
    resolved. Should this be a WG work item?
    Gonzalo Camarillo suggested the WG look at RFC 3329 (Security 
    Mechanism Agreement for the Session Initiation Protocol (SIP)) as a model to 
    ensure not they are not introducing a security risk. Jon Peterson 
    suggested the WG look at the possible use of security associations 
    between hosts. He argued against the presence of security 
    preconditions in RFC 3312 
    <http://www.ietf.org/rfc/rfc3312.txt> because of bootstrapping 
    concerns. He was trying to recall detailed arguments: we had better look at 
    the archives.
    Resolution: think about it a bit more.
    Interactive Connectivity Establishment
    Jonathan Rosenberg discussed ICE 
    (draft-ietf-mmusic-ice-00.txt), which was accepted as an MMUSIC work item in 
    Vienna. Since then, the draft has been rewritten to make it protocol 
    * generic session establishment protocol;
    * defined semantics in terms of that protocol;
    * ICE compliance defined in terms of mapping to generic protocol;
    * showed mapping for SIP (RTSP and H.323 are other possibilities, for 
    future work)
    Another change is that it is necessary to know, through 
    configuration, which is a public TURN relay (there may be non-public ones; 
    public one is default). ICE now uses the TURN SEND mechanism to tell the 
    relay to send a packet to a particular address-port; this can only be used 
    before lockdown and is needed in inter-enterprise cases.
    Jonathan walked through a call flow. Magnus was concerned about a packet 
    loss case after lockdown, before return to client. Jonathan will add a case 
    to cover this. A question was asked: can a binding be removed? TURN can, but 
    not ICE. Lockdown cannot be removed: keep things simple. In the 
    rewrite, Jonathan removed the massive call flows section from the draft: SIP 
    usage is not the point.
    Open issues include getting TCP to work (needs a connect method, and there is 
    the issue: demultiplexing of STUN and data on the connection - perhaps try to 
    avoid it by restricting functionality) and prioritization of 
    addresses, basically pushing routing to endpoints. Is there a better way? 
    Flemming Andreasen, without being specific, suggested that there may be 
    something in the middle that can handle routing better.
    Issues to be addressed:
    * RTSP mapping? Jonathan lacks expertise and time...
    * Sequential send attempts: Magnus suggested to do the semantics only 
    once, but Jonathan warned that we must not make assumptions about 
    * Use of multiple STUN servers? There was discussion on extra round 
    trips. Jonathan indicated he would be pleased to see a better 
    solution. There are tradeoffs: effficiency vs. reliability and safety. We 
    can continue to think about optimizations (such as assuming the RTSP 
    server is on the public network), but with great care.
    * Is it OK to have username/password in clear?
    * SDP ALT parameter conflict with 3GPP: Jonathan will fix. Jon Peterson 
    noted that he wouldn't mind more warning from 3GPP. TheIESG is working on a 
    liaison process to achieve this.
    Magnus Westerlund presented a number of changes incorporated in the 
    latest draft version of RTSP 
    (draft-ietf-mmusic-rfc2326bis-05.txt). Further changes have been agreed, but 
    are not yet documented:
    * Implicit Redirect using new 3xx code to get SDP for supporting 
    terminals. A feature tag will associated with this for backward 
    * Address class in "c=" needs to be checked.
    * Caching of methods is unspecified
    * Aggregate control URI deriving will be unspecified
    * Clarify the usage of SDP "a=range" for TiVo type of devices
    * The server MAY close the TCP connection after receiving the 2xx 
    message for a REDIRECT request
    * To write something about request to response time limitations. Keep the 
    specification simple, details to be worked out.
    * ABNF to be collected in a single chapter
    * Issues with changing transport parameters using SETUP
    * Should the Location header work as base URI for requests with 
    REDIRECT without SESSION header
    * Request/response time is not limited; needs clarification
    There are few open issues, but lots of editorial stuff to clean up. The 
    team will try to edit out all known bugs by the end of year. A clean-up 
    review can be held from January to March, with WG Last Call by March. The 
    teleconferences will continue, starting on 3rd December.
    Thomas Zeng <mailto:zeng@PacketVideo.COM> discussed RTSP NAT traversal 
    (draft-ietf-mmusic-rtsp-nat-01.txt). There is still lots of work to do on 
    the -01 draft based on Vienna comments, but work on the core RTSP spec took 
    priority. Current focus is to clarify the requirements:
    * MUST work for all flavors of NAT, including symmetric
    * MUST work for firewalls, including those with ALGs
    * SHOULD have minimal impact on clients in the open and not dual hosted
    * SHOULD be simple to use/implement
    * SHOULD be secure
    Jonathan cautioned on the wording of requirements with respect to 
    firewalls: make sure the aim is to support administrative control.
    There is an issue with dual-hosted clients. Thomas proposed to add a 
    mechanism to support them: many RTSP servers won't allow such clients, to 
    prevent DDOS attacks. Jon Peterson suggested that the most important task at 
    hand is to explain the problem in great detail.
    Moving forward the next revision will clarify "statement of 
    intention" and provide list of requirements. Will also remove any 
    solutions requiring protocol extensions to a separate draft. Jonathan 
    noted that some mechanisms can be provided on the basis of "required to 
    implement, not required to use"
    RTSP END-OF-STREAM proposal
    Thomas Zeng discussed the END-OF-STREAM proposal for RTSP 
    -mmusic-rtsp-end-of-stream-01.txt). Background: RTCP BYE is awkward; would 
    like to be able to reuse SSRC. Lately the RTSP team has been finding a 
    requirement to push various items to the client: END-OF-STREAM, session 
    descriptions and updates, error events. Some earlier drafts have been 
    written in the area.
    Strawman proposal: extend RTSP, adding a Server-to-Client method with 
    feature tag. There was a recent suggestion to use ANNOUNCE for the 
    End-of-Stream application. Should this be generalized for other 
    information? Tom Marshall suggested using a SET parameter. Jörg didn't 
    think the semantics felt right.
    Regarding the strawman proposal: Jörg would like to avoid having to 
    respecify connection management for the Server-to-Client direction. This was 
    more a matter that the client should keep the connection up to receive 
    Thomas provided an example of possible syntax. Magnus expressed a 
    concern with the  "bytes" specification in Range; this is a conflict. The 
    example will be cleaned up.
    The next step is expand scope of draft to cover ANNOUNCE as an 
    extension of the core specification. Should this be a WG item? Magnus and 
    Colin both suggested further work before making this decision. We can 
    decide on the mailing list after the next revision. We might consider 
    pulling back this capability into the main 


    Internet Media Guides - Update and Open Issues
    The Alternative IP Versions Semantics for the SDP Grouping Framework
    SDP Security Descriptions for Media Streams
    Real-Time Streaming Protocol
    RTSP NAT Traversal Update
    Signaling End-Of-Stream in RTSP