2.7.6 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-23

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-10.txt
  • - draft-ietf-mmusic-sdpng-trans-04.txt
  • - draft-ietf-mmusic-rfc2326bis-06.txt
  • - draft-ietf-mmusic-sdp-implem-00.txt
  • - draft-ietf-mmusic-sdp-bwparam-05.txt
  • - draft-ietf-mmusic-rtsp-nat-02.txt
  • - draft-ietf-mmusic-sdescriptions-03.txt
  • - draft-ietf-mmusic-offer-answer-examples-02.txt
  • - draft-ietf-mmusic-img-req-03.txt
  • - draft-ietf-mmusic-ice-01.txt
  • - draft-ietf-mmusic-img-framework-03.txt
  • - draft-ietf-mmusic-anat-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

    Minutes of the Multiparty Multimedia Session Control (MMUSIC) WG
    Reported by:	Jörg Ott
    Notes by:	Colin Perkins
    Colin Perkins, Jörg Ott
    The MMUSIC WG met once at the 59th IETF.  The meeting was chaired by Colin 
    Perkins and Jörg Ott.  Some 100 people attended the meeting.
    Jörg reviewed the agenda, with no changes being requested.  He also 
    provided a brief status update: Several WG documents are with the IESG now, 
    some of them waiting to be updated.  No RFCs were published since the last 
    Internet Media Guides
    Rod Walsh, Juha-Pekka Luoma, Yuji Nomura
    - draft-ietf-mmusic-img-req-03.txt
    Rod Walsh discussed the changes since the last version in the two above WG 
    documents.  The requirements document has seen various 
    clarifications and formal corrections.  The problem statement was 
    augmented to point to the holes existing IETF protocols leave in the 
    problem space.  The use cases were reordered, further cases covering 
    subscribe/notify requirements were added.  Delivery and description 
    requirements were clarified.  For the framework document, the 
    descriptions of SUBSCRIBE and NOTIFY operations were improved, the draft was 
    aligned with the requirements draft.  Finally, again, formal and 
    editorial corrections were made.
    Rod then presented the conceivable next steps: the documents are already in 
    WGLC, so there are considered pretty much complete.  Within the IMG 
    framework, three potential new areas of work have been identified: an IMG 
    transfer envelope, a multicast delivery protocol, and a subscribe notify 
    mechanisms.  Thoughts on all areas exist as individual drafts, and Rod 
    requests they be added to the MMUSIC or appropriate other WG charter (see 
    below).  There is quite some interest from other bodies (including 3GPP and 
    DVB) so this work should proceed.
    In the following, Pekka and Yuji outlined the suggested work items, 
    starting from the framework draft and filling in the components needed: The 
    transfer envelope is supposed to be an XML definition for a container that 
    can carry arbitrary metadata as contents 
    img-metadata-envelope-00.txt).  This could be done in MMUSIC.  The 
    multicast transport protocol should be designed as a specific 
    instantiation of the FLUTE protocol spec from the RMT WG, as suggested in 
    draft-luoma-mmusic-img-muppet-04.txt.  This work could be in MMUSIC or in 
    RMT.  The unicast subscribe/notifiy mechanisms could be based upon the SIP 
    event framework, but no draft exists here so far.  This could be done in 
    The presentation provoked some discussion on whether it would be 
    appropriate to think about using the SIP SUBSCRIBE/NOTIFY mechanism, as no 
    obvious relation can be seen to other SIP work.  It was noted that this 
    work is less about personal presence than about conveying state changes in 
    general, and it was requested that clear use cases and requirement be 
    drawn up and sent to the SIPPING list for discussion. Furthermore, it was 
    remarked that the XML encapsulation format will become much easier if all 
    data objects are labelled rather than allowing for generic XML to be 
    encapsulated, e.g. for diffs.  Yuji noted that a generic 
    encapsulation is necessary.
    There were no objections raised against continuing this work.  Colin and 
    Jörg were tasked to talk to the ADs and the chairs of the other 
    relevant working groups (particularly SIPPING and RMT) to determine where 
    which work should go and to initiate re-chartering MMUSIC 
    SDP Security Descriptions for Media Streams
    Flemming Andreasen
    - draft-ietf-mmusic-sdescriptions-03.txt
    Flemming briefly reviewed the overall structure of the draft and the 
    changes since the last revision: It consists of a core framework and 
    parameter definitions, a specific instantiation of this framework for 
    SRTP, procedures on how to operate with, and without, offer/answer 
    scheme, and a grammar.  Quite a few changes have been made to the draft 
    since -02: following consensus from the last IETF, support for 
    multicast and multipoint SRTP sessions was removed, so was the SRC 
    parameter. Rules for creating and removing crypto contexts are now more 
    explicit. Numerous additions were made to clarify the use with 
    offer/answer. Finally, the IANA registry structure was changed.
    Flemming pointed out one minor issue with offer/answer: with o/a, an 
    initial crypto context is established.  However, subsequent o/a 
    exchanges may not just modify codec parameters but also peer addresses (IP 
    address and/or port).  In this case, the new entity may not have 
    information about the current ROC value.  The solution is to reset the ROC 
    value to zero whenever any part of an address changes (at either end).
    A question was raised which changes would affect security; this seems to be 
    restricted to the case of a transport address or port change at either end.
    The group felt the document was ready for WGLC.
    SDP Security Preconditions
    Flemming Andreasen
    Flemming briefly introduced the problem to be addressed: during an 
    offer/answer exchange, the offerer and answerer exchange security 
    parameters.  When the answered has picked a scheme (possibly one out of 
    several offered) and the respective parameters, it can start sending media 
    right away.  The first packets of the secured media stream may reach the 
    offerer before the answer, so that the offerer does not know which 
    security description to use.  RFC 3312 provides a solution by means of 
    introducing preconditions which was suggested for this problem at the last 
    IETF.  In the meantime, no concerns were raised and no issues found so that 
    this work is believed to be useful and also ready.
    It was tentatively agreed to adopt this as a WG item, pending charter 
    SDP Connectivity Preconditions
    Flemming Andreasen
    Flemming introduced the problem to be addressed: various 
    circumstances (e.g. deployment of NATs, firewalls, etc.) may interfere with 
    packet transmission and may prevent media streams from flowing in either or 
    both directions, even though call signaling setup succeeds.  The 
    proposed approach is to re-use the precondition mechanism defined in RFC 
    3312 with a new precondition tag to indicate that a call shouldn't 
    proceed until connectivity has been verified.  To test whether media 
    stream connectivity (which is only defined for RTP) is available, a 
    mechanism such as STUN or the proposed new RTP NOOP payload format can be 
    used (the draft doesn't mandate any particular connectivity check).
    Significant discussion arose concerning the relationship between this work 
    and ICE (the latter being used to ensure that there is 
    connectivity).  Commenters found that the term "connectivity" needs a more 
    precise definition in the draft to be able to take a binary decision of 
    whether or not a connectivity precondition is satisfied. A further issue was 
    raised in conjunction with SIP forking, as the initiator of a call may 
    receive packets from multiple destinations and may be unable to tell which 
    branch satisfied the precondition. Flemming believes the approach is 
    workable and took up the task to explain this in more detail in a 
    revised version.
    The chairs noted that there is clearly interest in the draft, but 
    chartering this as an MMUSIC work item again requires a charter 
    discussion first. 
    Interactive Connectivity Establishment (ICE)
    Jonathan Rosenberg
    - draft-ietf-mmusic-ice-01.txt
    Jonathan presented three issues and proposed solutions regarding the 
    current ICE draft.
    Issue 1 is may occur with a port restricted flow if the called entity does 
    not respond soon enough, e.g. with a 200 OK in the case of SIP (refer to the 
    slides for details of the message flow).  In this case, a STUN timeout may 
    occur at the callee because the caller does not receive the 200 OK and 
    start sending STUN packets itself (thereby creating the necessary 
    binding in its local NAT) so that media connectivity is not 
    established.  This is a race condition between the STUN timeout and the 
    answer from the callee.
    Jonathan has two solution proposals: solution 1 is to mandate an 
    immediate answer, this can be achieved in SIP e.g. with a 183 
    conveying the necessary addressing information back to the caller, and to 
    increase the STUN timeout.  Solution 2 is to mandate a second ICE cycle to 
    re-check  STUN-allocated addresses; this solution increases the 
    signaling overhead associated with session setup (not the setup delay!) but 
    eliminates the race condition in all cases.  Jonathan proposed solution 1 as 
    the appropriate solution.
    A comment was made that a connectivity precondition may solve this issue 
    which Jonathan argues against.  A suggestion was made to avoid a second 
    cycle with solution two, based upon the priority order of the 
    connection type.  Jonathan feels that basing this decision on the NAT type 
    determination is too risky, since it is difficult to determine the type of 
    NAT that is present.  A question was raised whether or not this use of 183 
    would interfere with "early media" via 183; this will be checked.  It was 
    also proposed to extend the timeout until the "200 Ok" in solution 1, and 
    there was some brief discussion of the implications of this. 
    No consensus was reached on issue 1.  Jonathan will send mail to the list 
    summarizing the issue and soliciting feedback.
    Issue 2 is on how to prioritize addressing information in ICE.  So far, the 
    intention is to minimize relaying and to prefer IPv6.  There are, 
    however, are other conceivable criteria, e.g. to maximize the number of 
    hops across security networks, minimize path latency, minimize number of 
    router hops, etc.  The issue is (a) whether one of these criteria needs to be 
    chosen and, if so, (b) which one.  Jonathan argues that this is in 
    essence a policy decision and ICE does not depend on any policy.  It works as 
    long as at least one uable address exists.  Nevertheless, there may be many 
    parties involved with different policies and preferences. With the work of 
    SIP/SIPPING on session policies (e.g. allowing service providers to 
    assert policies on media streams), the ICE address preference appears 
    simply as another policy. 
    Jonathan proposes to not fix address preferences but rather clarify, in the 
    ICE spec, that there are different axes of optimizations and, document the 
    existing algorithm.  Other specs shall be allowed to define 
    (informationally) other algorithms.  A reference session policy should be 
    described as a non-normative approach for finding out other policies. This 
    proposal was found reasonable.
    Issue 3 addresses the interaction between ICE and RTP NOOP (a 
    presentation on RTP NOOP was given).  The NOOP format appears to have some 
    commonalities with STUN: sent to RTP port, requests an immediate (RTCP) 
    response, and checks for connectivity and QoS between endpoints. The same 
    (except for QoS checks) can be said for STUN used by ICE. Jonathan 
    briefly described the differences: NOOP uses RTP and hence is cleaner for 
    RTP sessions; but ICE works for other protocols, too.  NOOP uses RTCP for 
    responses which are sent to different port and hence may not work 
    through many NATs.  ICE (STUN) also provides address allocation and uses 
    username/password for validation while NOOP would require SRTP. 
    The obvious options, given this commonality, are to either use only NOOP, to 
    use only STUN, or to use both.  There was a lot of discussion, trying to 
    understand and clarify the differences between the drafts, with no clear 
    conclusion.  It is plain that clarification of use cases, and of the 
    relationship and overlap between the various drafts, is needed.
    RTSP Update
    Magnus Westerlund
    - draft-ietf-mmusic-rfc2326bis-06.txt
    - draft-ietf-mmusic-rtsp-nat-02.txt
    - draft-zeng-mmusic-map-ice-rtsp-00.txt
    Magnus presented the current status of the RTSP core spec (see slides for 
    the details).  The spec has been progressing well.  Out of the 
    currently logged 40 bugs almost all are solved, with only six 
    unresolved ones.  The spec underwent major changes and 
    restructuring: the use of RTP was rewritten, the syntax is now compiled in a 
    single chapter, and a proposal on timing RTSP messages was included.  The 
    numerous minor updates are listed in the slides.
    Magnus discussed the open issues and their current status 
    (elaborated on in detail on the slides).  There was some discussion of 
    options for authentication to prevent session hijacking, including the 
    possibility to mandate use of RTSP over TLS, as an alternative to 
    cryptographically random session IDs. It was also noted that we need to 
    understand the use cases for destination redirection, to determine how big an 
    open issue this is.
    Finally, Magnus presented those resolved issues that did not yet make it 
    into the spec: RTSP proxies, use cases for RTSP, and the use of 
    implicit redirects.
    Everyone is encouraged to review the revised spec in detail and 
    comment!  The editors will edit in the remaining issues.  The 
    teleconferences held for discussing and resolving issues shall be 
    resumed.  The goal is to finish the RTSP core spec in 2004.
    Next, Magnus reported on the interactions between RTSP and NATs.  As per the 
    discussion during IETF-58, a requirement section was added and the usage of 
    ICE is now in a separate draft, and solution proposals (regarding 
    protocol changing mechanisms) were removed.
    The remaining open issues include to clarify the recommendations on 
    working with ALGs, with specific recommendation to be provided for 
    firewalls ALGs (which are different from NAT ALGs).  An appropriate 
    protocol modifying solution needs to be chosen.  Various high-level 
    proposals exist for the latter including using ICE (for a proposal exists 
    which is briefly presented), embedding STUN in an RTSP server, and using 
    symmetric RTP.  Interested parties are requested to write drafts; these 
    should be evaluated afterwards and a single solution should be 
    Temporal References within URIs
    Conrad Parker
    Conrad Parker motivated the work by the need to define links to time 
    points and regions within a real-time media resource (e.g. a movie) so that 
    pieces of interest can be referred to directly.  The draft on 
    rfc2396bis defines "?query" and "#fragment" to enable referring to a 
    subpart of a resource.  This is integrated with HTTP and other download in a 
    straightforward fashion: the server interprets the URI with the 
    additional parameters and returns only the selected piece of the 
    Conrad notes that in RFC 2326 the handling of query identifiers and 
    fragments is undefined.  He suggests specific interpretations of queries and 
    fragments for handlng by the server and the client, respectively. He 
    raises various issues, particularly how the mechanism can be kept 
    extensible. It was noted that, while there is a clear use case for 
    fragment requests, it is less obvious why queries are useful. Some 
    clarification was requested.
    Other short discussion suggests that -- rather than defining 
    individual specific extensions for RTSP URIs and extending those every now 
    and then -- it may be more appropriate if a generic header inclusion 
    mechanism is defined, as for SIP.
    				 - * -


    Internet Media Guides
    SDP Security Descriptions for Media Streams
    Security Preconditions for SDP Media Stream
    Connectivity Preconditions for SDP Media Stream
    The RTSP Core specification
    Time intervals in URIs