2.8.8 Multiparty Multimedia Session Control (mmusic)

Last Modified: 2003-06-16

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
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
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

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
that gathers the requirements from the areas in which SDP is currently

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
will be re-issued as either a Proposed or Draft Standard RFC. A MIB
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
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

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.
Jul 03  Submit revised SDP spec for Proposed (or Draft) Standard
Jul 03  Submit IMG requirements and framework for Informational
Jul 03  Review work on IMGs and update charter accordingly
Aug 03  Submit SDPng base spec profile for Proposed Standard
Oct 03  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
Oct 03  Submit SDP Offer/Answer examples for Informational
Nov 03  Submit SDPng video profile spec for Proposed Standard
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
Dec 03  Submit RTSP MIB for Proposed Standard
  • - draft-ietf-mmusic-sdp-srcfilter-05.txt
  • - draft-ietf-mmusic-sdp-new-13.txt
  • - draft-ietf-mmusic-sdp-comedia-05.txt
  • - draft-ietf-mmusic-sdpng-06.txt
  • - draft-ietf-mmusic-sdp4nat-05.txt
  • - draft-ietf-mmusic-kmgmt-ext-08.txt
  • - draft-ietf-mmusic-sdpng-trans-04.txt
  • - draft-ietf-mmusic-rfc2326bis-04.txt
  • - draft-ietf-mmusic-sdp-implem-00.txt
  • - draft-ietf-mmusic-sdp-bwparam-04.txt
  • - draft-ietf-mmusic-rtsp-nat-01.txt
  • - draft-ietf-mmusic-sdescriptions-01.txt
  • - draft-ietf-mmusic-offer-answer-examples-01.txt
  • Request For Comments:
    Real Time Streaming Protocol (RTSP) (RFC 2326) (195011 bytes)
    SDP: Session Description Protocol (RFC 2327) (87096 bytes)
    SIP: Session Initiation Protocol (RFC 2543) (338861 bytes) obsoleted by RFC 3261
    SIP: Session Initiation Protocol (RFC 2543) (338861 bytes) obsoleted by RFC 3262
    SIP: Session Initiation Protocol (RFC 2543) (338861 bytes) obsoleted by RFC 3263
    SIP: Session Initiation Protocol (RFC 2543) (338861 bytes) obsoleted by RFC 3264
    SIP: Session Initiation Protocol (RFC 2543) (338861 bytes) obsoleted by RFC 3265
    Session Announcement Protocol (RFC 2974) (40129 bytes)
    Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections (RFC 3108) (248037 bytes)
    A Message Bus for Local Coordiantion (RFC 3259) (84125 bytes)
    An Offer/Answer Model with SDP (RFC 3264) (60854 bytes)
    Support for IPv6 in SDP (RFC 3266) (8693 bytes)
    Grouping of media lines in Session Description Protocol SDP (RFC 3388) (39365 bytes)
    Mapping of Media Streams to Resource Reservation Flows (RFC 3524) (11249 bytes)

    Current Meeting Report

    archives.Minutes of the MMUSIC WG Meeting at the 57th IETF
    Reported by Joerg Ott and Colin Perkins
    Notes taken by Colin Perkins
    The MMUSIC WG met once at the 57th IETF.  The meeting was chaired by Colin 
    Perkins and Joerg Ott.  It was attended by some 90 participants.
    Status Update
    Joerg Ott reported on the status of the working and the general 
    progress since the 56th IETF in San Francisco:
    - The new charter was finally approved.
    - RFC 3524 was published on SDP extensions for reservation flows.
    - Two documents are with the RFC editor: SDP extensions for NAT 
    traversal and SDPng transition.
    - Two documents are with the IESG, and comments have been received:
       - draft-rajeshkumar-mmusic-gpmd-03.txt was felt to overlap with work on 
    capability negotiation carried out elsewhere; it was noted that this 
    probably applies to most of SDP except that SDP was first. The chairs and 
    authors will work with the IESG to sort this out.
       - draft-ietf-mmusic-sdp-new-13.txt received many comments which were 
    discussed in a separate slot (see below).
    - Two documents are under AD review:
       - draft-ietf-mmusic-sdp-comedia-05.txt
    - draft-ietf-mmusic-sdp-bwparam-04.txt is completing WGLC on 28 Jul 2003.
    - The SDP extensions for key management 
    (draft-ietf-mmusic-kmgmt-ext-07.txt) have been waiting for the MIKEY work to 
    complete which seems to progress.  A further revision is expected 
    shortly after the IETF.
    - The SDP implementation draft 
    draft-ietf-mmusic-sdp-implem-00.txt has not been revised yet, but Tom 
    Taylor is working on it.  He is trying to incorporate further 
    implementation experience from inside his company as well as from the 
    SIPit events.
    Two potential new work items have been discussed for MMUSIC:
    - Real-time fax 
    (draft-ietf-sipping-realtimefax-01.txt) from the SIPPING WG is to 
    provide implementers with guidelines on how to use registered SDP 
    attributes for ITU-T T.38.  This document actually contains two logical 
    parts: the use of offer/answer mechanics (which belongs to MMUSIC) and a 
    discussion of SIP-specific signaling (which belongs to SIPPING).  It is 
    suggested to investigate splitting the document to deal with each one in the 
    respective WG.  But it was pointed out that this document merely 
    contains examples only and hence should be done as a whole in just one WG.  
    To be resolved.
    - Interactive connectivity establishment (ICE) also from the SIPPING WG 
    (draft-rosenberg-sipping-ice-01.txt).  This is discussed later on the 
    Revised SDP 
    Colin Perkins reported on the changes incorporated in the latest 
    revision of SDP: It was attempted to clarify when the k= attribute may be 
    used.  Further clarifications include: RTP may be used with 
    non-consecutive port numbers and a=charset is only allowed as a session 
    level attribute.  Also, unregistered X- attributes and media format are 
    deprecated.  Finally, IANA considerations and references were updated.
    Colin further reported on issues raised on revision -13 on the mailing 
    list, as well as from the IESG review.
    - An ABNF inconsistency was found: a comment in the ABNF for 
    "token-char" allowed for a larger set of characters than the actual 
    definition.  One could either (1) change the comment to match the actual 
    grammar (and thus reduce the set of allowed characters) or (2) modify the 
    grammar to match the comment.  The group agreed to go with option (1), 
    pending a check against the use of SDP in RFC 3108. Tom Taylor 
    volunteered to find this out.
    - The use of b= with layered coding should be clarified as follows:
    When using the CT modifier with RTP, if several RTP sessions are part of the 
    conference, the conference total refers to total bandwidth of all RTP 
    sessions.  This was accepted in principle but it was also pointed out that a 
    bandwidth specification per layer would be helpful.  Further 
    discussion is needed on the mailing list.
    - Again with layered coding, it should be clarified which ports are 
    associated with an m= line.  The clarification proposal was accepted.
    - The k= is underspecified.  The most straightforward way would be to 
    deprecate the use of this field altogether.  Opinions from 
    implementers are sought.  It was reported that MS Messenger uses this 
    field; the details are unknown at this moment though.  As there are 
    implementation out there, just deprecating this field won't work. 
      Therefore, further work needs to go into the specification of using k=.  In 
    particular, when k= shall be used, a secure channel must be available and 
    endpoints need to be sure that no third party can eavesdrop on the key.  
    These issues, however, need to be specified by those using SDP rather than 
    SDP itself. 
      The k= field currently supports an algorithm indicator, but it should 
    also specify a key type.  This may be implied by the URI or the media 
    protocol used.  For more complex scenarios, e.g. when more than one key is 
    needed, either the sdescriptions work 
    (draft-ietf-mmusic-sdescriptions-01.txt) or the key management 
    (draft-ietf-mmusic-kmgmt-ext-07.txt) work should be used. 
      It was proposed that the security considerations section should change 
    "SHOULD NOT deliver the user into an interactive multimedia 
    session..." to "MUST NOT...".  It was found that this is an issue of user 
    authorization (e.g. the user may be able to pre-authorize the 
    automatic joining of certain interactive sessions) and needs to be dealt 
    with by the protocols using SDP. 
    - The suggestion to define a "IN" value for private address spaces was 
    rejected because systems 1) cannot tell whether they are in a private 
    address space (relative to their peers) and 2) this change would be not 
    backward compatible.
    - It will be clarified that UTF-8 normalization is not needed because 
    comparisons are not done on fields with UTF-8.
    - Proposal on a=inactive: it was agreed not to change the SDP spec here 
    (this is an issue for users of SDP, which may establish conventions for 
    use, not for SDP itself).
    - Wording should be added that u= and k= may include URIs that may be 
    dereferenced in some (but not all) cases.  Also, it should be noted a k= URI 
    may typically be an http or https URI.  Both suggested wording 
    additions were accepted.
    Colin will fold the comments and the discussion into the document and 
    produce a new revision out within a couple of weeks.
    SDP Security Descriptions 
    Dan Wing briefly reviewed the document and the changes from the 
    previous revision: a new syntax is proposed for the a=crypto attribute and 
    the offer/answer part is revised which may need further review. For the 
    next steps, Colin noted that an IANA considerations section is needed, 
    including a discussion of the registration procedures. Furthermore, 
    reviewers for finishing the document were sought: Tom Taylor, Magnus 
    Westerlund, and Martin Euchner volunteered. 
    Offer/Answer Examples 
    Alan Johnston presented the changes to the document: in particular, an 
    example for asymmetric use of a codec has been added. This is to be 
    achieved using two distinct m= lines with the same port number, one 
    indicating "sendonly", the other "recvonly". The proposed behavior caused 
    some discussion: it was felt that the mechanism was 
    underspecified and that (therefore) m= lines with the same port would be a 
    bad idea. Yet, the right approach to achieve the desired behavior seemed 
    unclear. Gonzalo Camarillo pointed out that the RFC3388 provided a 
    similar example, but with an explicit grouping (which is not present in 
    this draft). The applicability of RFC3388 to this problem was 
    discussed further. Orit Levin pointed out that the intention clearly is to 
    use RFC 3388 but the question is what happens to the endpoints that don't 
    support RFC 3388. Gonzalo argued that this is already defined in RFC 3388. 
    The chairs stated that they would like to see the asymmetric codec 
    behavior with two m= line properly specified in a document. The present 
    offer/answer examples draft is meant to be illustrative; the example 
    should be kept in place (with added grouping) but the normative text for 
    this behavior needs to be someplace else. Flemming Andreasen suggested to 
    specify part of this practice in the revised SDP. 
    SDPng Update (draft-ietf-mmusic-sdpng-06.txt)
    Dirk Kutscher presented the latest progress on SDPng, addressing the open 
    issues from draft -06 (a new revision still needs to be submitted).  The 
    SDPng structure has been enhanced to decouple capability negotiation for 
    potential configurations from actual configuration (and the 
    respective session parameters).  While the capability model has been kept, 
    the syntax has been revised to exclusively rely on XML mechanisms 
    (rather than embedding own syntax conventions for attributes) -- which is 
    less efficient but much cleaner.  Dirk presented the new syntax using 
    several examples and also showed a formal schema definition.  A further 
    refinement from draft -06 is to remove the concept of libraries and use 
    inline definitions instead -- so that SDPng documents would be 
    self-contained. There was little discussion.  Steve Casner asked whether 
    this work was getting enough traction and questioned whether people were 
    really preparing for a transition.  Joerg Ott argued that people are 
    desparately holding onto SDP (which is perceived easier with one small 
    extension at a time) -- but that examples show that this getting more 
    complicated so that SDP is likely to have only a finite lifetime.  So it 
    would be nice to get broader review from the community on a 
    replacements for SDP. 
    RTP DoS Attacks 
    Interactive Connectivity Establishment 
    Jonathan Rosenberg introduced the RTP DoS problem: An attacker may easily 
    direct the RTP stream(s) from an unsuspecting source to any target by 
    providing the target's IP address in the SDP.  This works for SIP and RTSP -- 
    with RTSP providing limited protection by allowing unicast RTP streams only 
    to the address of the originator (but NATs make it worse as anyone behind 
    the same NAT can easily be attacked). As authentication mechanisms can at 
    most help identify the attacker (which may be very weak though), some kind of 
    handshake mechanism is needed so that sources do not start sending media 
    streams unless they know that the right receiver is actually waiting for it: a 
    request/response mechanism using the RTP ports is needed.  This is ICE (see 
    below) which has been chosen as a solution for SIP.  However, ICE has 
    broader applicability and may be appropriate for RTSP, too -- which needs to 
    be determined by the group.  Jonathan reviewed the properties of the ICE 
    approach and briefly walked through the basic ICE algorithm.  With ICE 
    being signaling protocol independent, MMUSIC is asked to take ICE up as a WG 
    ICE is felt to introduce quite some complexity for RTSP endpoints. If, 
    however, NAT traversal (which is an RTSP issue on its own, see below) and 
    security can be addressed by the same mechanism, it may be worth the 
    effort.  It is noted that even if we go for the ICE mechanism for RTSP 
    right now, this does not solve the problem as long as old RTSP servers are 
    still out there.
    Regarding the ICE proposal as a WG item Magnus Westerlund argued that if it 
    is accepted, one should split the draft into several parts: the SIP use, the 
    ICE mechanism, the use with offer/answer, etc. There was consensus in the 
    group to accept ICE as new WG item, and to fully document the RTP DoS 
    issues as an informational document.
    RTSP Update 
    Magnus Westerlund reported on the progress of the RTSP revision, 
    achieved by having a new co-editor joining the team, many 
    teleconference calls, and also quite some list discussion.  He 
    presented a number of changes from draft -03 (see the slides).  With this, 
    most known open issues are resolved, with only a few ones remaining (see 
    slides).  But many resolutions still need to be folded into an updated 
    revision of the draft.  When this is done, a second phase of editing on the 
    spec is needed: examples need to be fixed, the spec's consistency needs to be 
    checked as needs it overall readability, and, potential new open issues 
    need to be solved.  With all this, the revised RTSP spec will not meet the 
    October deadline as currently documented in the MMUSIC charter.  Magnus 
    suggests another six months would be appropriate to finalize the work.
    RTSP and NAT 
    Magnus Westerlund introduced the revised draft on RTSP and NATs, the 
    purpose of which is to describe how to traverse NATs and firewalls with 
    RTSP.  It documents several possible NAT traversal approaches and gives 
    recommendations regarding RTSP for firewalls.  Approaches requiring only 
    modifications on the client side STUN, TURN, and RTP/RTSP tunneled in 
    RTSP.  Application-Layer Gateways (ALGs) for RTSP will not require any 
    modifications -- but are generally discouraged. Magnus further 
    discussed open issues, particurlarly the goals for RTSP for NATs (i.e. what 
    type of scenarios should be achievable) as well as possible solutions 
    (symmetric RTP, STUN, ICE, DCCP).
    On the ALGs: The group generally agreed that ALGs are a bad thing and 
    should not be considered further (except for documentation purposes and to 
    communicate this clearly to outside the IETF -- and fast, as people start 
    deploying these).
    On the document's purpose: Commenters state that, currently, the draft does 
    not give conclusive resolution of what to do as an implementer, it is 
    merely an inventory.  It is proposed to pick some solution and write it up, 
    e.g. in the RTSP spec.  Magnus wants to resolve the structure of the 
    document and then settle on a solution: one for the server and one or more 
    for the client side.  Jonathan Rosenberg and Tom Marshal argue over the 
    number of client-side solutions to be documented: Jonathan wants only one 
    while Tom prefers to have multiple feasible solutions document.  In case 
    multiple ones are documented, Jonathan wants exactly one "MUST 
    implement" solution to ensure interoperability.
    There was some further discussion on technical aspects of possible 
    solutions, but no real conclusions were reached.
    Internet Media Guides (IMG)
    After a brief introduction by Joerg Ott, Rod Walsh presented the 
    progress on the IMG requirements document (which will be 
    re-submitted as WG draft by end of August). He briefly reviewed the 
    general topology and IMG distribution aspects and then went through the 
    requirement categories identified in the draft: IMG description 
    requirements and IMG transport requirements. The former primarily 
    address IMG envelopes for existing meta-data formats, the latter their 
    distribution in unicast and multicast, pull and push style scenarios. For 
    multicast push, SAPv2 is probably inadequate, so a successor is sought, 
    e.g. ALC from the RMT WG. It is pointed that additions to ALC need to be 
    specified separately; while Rod wants to use the RMT proposal FLUTE, 
    Lorenzo argues that this may not be 100% appropriate here; Lorenzo also 
    points out that possible tasks in the RMT WG need to happen quickly as the 
    group is trying to wrap up. For unicasting, client-initiated actions could 
    use HTTP while notifications from the server could use SIP mechanims. 
    Rod discusses on the scalability requirements IMG transport and 
    presents a conceptual overview showing the different pieces of an IMG 
    framework and outlines the achieved flexibility. He also addresses data 
    relationships and particularly security considerations as taken into 
    account in the requirements draft. 
    Rod finally discusses the way ahead: the requirements draft is pretty 
    close to finalization; the remaining efforts are mainly editorial and 
    consolidation. The aim is to go for WGLC soon. He also points to the 
    existing framework draft that will be revised by the end of August. 


    ICE and RTP DoS
    Internet Media Guides - Some Issues
    RTSP - Core
    RTSP & NATs
    SDP Security Descriptions for Media Streams
    SDP Specification Update
    SDP Offer Answer Examples
    SDPng Update