2.7.8 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-24


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/mail-archive/web/mmusic/index.html

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group 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 to express
media and session descriptions: 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

- 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
(e.g. via the ICE methodology), and exchange of media session
security keys.

With the exception of these specific items, only extensions within
the existing SDP framework will be done (e.g. registering new codecs
and defining parameters for them extending SDP to include new address

To address the more fundamental issues with SDP, a next generation of
SDP, referred to as SDPng, will be needed. An initial proposal is now
available, and will be progressed to Experimental RFC while we gain
experience with implementations. An informational document will be
produced describing how the transition to a new session description
protocol can be managed, to prepare implementors for such a future

MMUSIC will maintain and revise the specification of the Real Time
Streaming Protocol (RTSP), including fixes and clarifications based
on implementation experience. The revised RTSP specification will be
re-issued as a Proposed Standard RFC. We will also document how RTSP
can be used in the presence of NAT boxes.

An Internet Media Guide (IMG) is a collection of multimedia session
descriptions expressed using SDP or some other 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

MMUSIC will investigate delivery mechanisms for IMGs, generalizing
our 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, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS).
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
Done  Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.
Done  Submit SDP security extension for Proposed Standard
Done  Submit IMG requirements and framework for Informational
Aug 04  Submit revised SDP spec for Proposed (or Draft) Standard
Done  Submit SDP Offer/Answer examples for Informational
Aug 04  Review work on IMGs and update charter accordingly
Done  Submit SDP connection-oriented media draft for Proposed Standard
Nov 04  Submit SDPng transition scenarios for Informational
Nov 04  Submit SDPng base specification for Experimental
Nov 04  Submit ICE draft for Proposed Standard
Feb 05  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
May 05  Submit RTSP NAT considerations draft
Jul 05  Consider update of SDP specification for draft standard
Dec 05  Submit updated SDP Offer/Answer examples draft for Informational


  • draft-ietf-mmusic-sdp-srcfilter-06.txt
  • draft-ietf-mmusic-sdp-new-24.txt
  • draft-ietf-mmusic-sdp-comedia-10.txt
  • draft-ietf-mmusic-sdpng-08.txt
  • draft-ietf-mmusic-kmgmt-ext-13.txt
  • draft-ietf-mmusic-sdpng-trans-04.txt
  • draft-ietf-mmusic-rfc2326bis-09.txt
  • draft-ietf-mmusic-sdescriptions-09.txt
  • draft-ietf-mmusic-offer-answer-examples-05.txt
  • draft-ietf-mmusic-img-req-07.txt
  • draft-ietf-mmusic-ice-04.txt
  • draft-ietf-mmusic-img-framework-08.txt
  • draft-ietf-mmusic-anat-02.txt
  • draft-ietf-mmusic-comedia-tls-02.txt
  • draft-ietf-mmusic-sdp-media-label-01.txt
  • draft-ietf-mmusic-connection-precon-01.txt
  • draft-ietf-mmusic-rtsp-announce-01.txt
  • draft-ietf-mmusic-media-loopback-00.txt
  • draft-ietf-mmusic-sdp-bfcp-00.txt
  • draft-ietf-mmusic-securityprecondition-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
    RFC3605 Standard RTCP attribute in SDP
    RFC3890 Standard A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)

    Current Meeting Report

    Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes

    Reported by Colin Perkins and Joerg Ott

    The MMUSIC working group met once at the 62nd IETF meeting (Minneapolis, March 2005). Topics under discussion included SDP extensions for BFCP, content labels and connectivity preconditions, the ICE methodology for NAT traversal, the SDPng specification, stream tracking for resource management, harmonisation between SDPng and MPEG-21, RTSP, and Internet Media Guides. The meeting was chaired by Joerg Ott and Colin Perkins.

    SDP Format for BFCP


    Gonzalo Camarillo presented the SDP Format for BFCP. The specification for BFCP now has support for different hashing algorithms, meaning that the SDP format needs to be updated to use the sdescriptions format, not than the "k=" line. There have also been a number of clarifications to the draft regarding peer-to-peer use of BFCP (this work is ongoing). Gonzalo solicited input, noting that he expected the next revision to be complete. There were no comments.

    SDP Content Label


    Jani Hautakorpi discussed the SDP Content Label. This is a media level attribute that can be used to label streams with semantic meaning, so receivers can automatically treat each media stream appropriately. It is expected that labels will be things like "main camera", "speaker" or "presentation slides" and will be partly interoperable with roles defined by H.239.

    There was an extensive discussion regarding the difficulty of assigning labels and explicitly defining their semantics, with Brian Rosen noting that it may be hard to come to agreement about labels and their meaning. Gonzalo Camarillo and Roni Even disagreed about the difficulty, noting that there is a need for these labels, and that products exist that implement similar mechanisms. Jonathan Rosenberg and Brian Rosen both commented that there is related work ongoing in the SIMPLE and XCON working groups, and similar concepts in SMIL, with which we may need to align. Henning Schulzrinne and others noted that there are many possible labels, but that we only care about a small number of simple cases, and an application that receives an unknown label is no worse than one which receives no label. Joerg Ott finally wrapped up the discussion by noting that there is a clear interest in this work, and encouraged people to read and comment on the mailing list.

    SDP Connectivity Preconditions


    Flemming Andreasen presented the draft on connectivity preconditions for SDP media streams, outlining the problem and changes since the previous version.

    An open issue is that the draft does not mandate any particular way of verifying connectivity, although it does recommend the RTP NOOP format. Should the draft mandate a mechanism and if so which mechanism? Colin Perkins noted that the RTP NOOP draft has expired and will need to be updated if that is the choice. Flemming and Gonzalo Camarillo wondered about the overlap between the connection and connectivity precondition drafts and whether they should be merged? There was discussion about the semantics of connection establishment versus those of connectivity. Jonathan Rosenberg, Magnus Westerlund, Gonzalo and Flemming discussed the need for a three-way handshake to define connectivity and how NAT traversal issues may affect this. There was no real conclusion: it is clear further discussion is needed on the list.



    Jonathan Rosenberg discussed the ICE methodology for NAT traversal, noting that the -04 draft has not been changed compared to the -03, but that there are a number of open issues. Changes that have been agreed and will be incorporated include a clarification of re-INVITE behaviour, a change to make implementation of TURN optional, setting the RTCP bandwidth parameter to zero if you are not using RTCP, and some discussion on issues regarding congestion caused by STUN traffic using session startup.

    Open issue #1: obfuscating ICE addresses. Is there a need to try to obfuscate IP addresses to prevent "helpful" NATs from rewriting the addresses and breaking ICE? Consensus: no.

    Open issue #2: RTP specificity. The candidate attribute is RTP specific but we may need candidate addresses for non-RTP transports. Propose to define a more generic candidate attribute, using the priority field to group candidate addresses (e.g. to group RTP and RTCP). Consensus was to make this change.

    Open issue #3: TCP alternates for UDP. Currently the only alternatives you can choose for UDP are other UDP addresses; we cannot fall back to a TCP connection if all UDP addresses fail. Propose to extend the ICE specification to allow fallback to TCP as a connection of last resort, and to document both how this affects performance and the implications this has for sites that block UDP at their firewall as a policy measure to prevent VoIP. Cullen Jennings was concerned that this has potential to start an arms race with firewall vendors and administrators, and worried about circumvention of firewall policy. Colin Perkins and Jon Peterson noted that certain proprietary applications also fallback to TCP: this is not an unknown technique, we need to compete with those systems to ensure our protcols remain valid and useful. It seems that there was rough consensus that use of TCP was not ideal, and concern that one may not wish to implement fallback to TCP as a default, but that in the current Internet it may be necessary to allow such a fallback as an option.

    There are a number of other open issues, concerning fallback to TCP and identification of RTP profiles, diagnosis of problems since the final IP address and port are never signalled, interaction with preconditions and middleboxes, dynamic RTP address changes, the ugliness of demuxing STUN and RTP, and interactions with SRTP.

    Jonathan noted that the root cause of all these problems is the single fact that a peer in the dialog starts sending media to the new address once the connectivity check succeeds without signalling that address. Proposal: separate these and always send media to the address/port in the "m=" and "c=" lines, and only send connectivity checks to the address/port in the candidate lines. When connectivity checks succeed, do a re-INVITE or UPDATE that "promotes" the candidate address/port to the "m="/"c=" lines. Note that this does not increase call setup time or post-dial delay. [see slides for a sample call flow, illustrating operation of the proposal]. There was considerable discussion of the details of the idea, with the consensus being generally in favour. The details will be defined on the mailing list, with an updated draft to be published documenting the new approach.

    Stream Tracking for Resource Management in the Network


    Ingo Wolf presented a new proposal for streaming tracking for resource management in the network. This is a modification to SDP and SDPng to convey source addresses and ports, which is hoped can be used to signal stream details to middleboxes which can then attempt to ensure QoS.

    Cullen Jennings inquired the precise problem definition that the draft is supposed to solve and wanted to know why the proposed solution solved it. Ingo stated that the motivation is to provide an explicit grouping between source addresses of RTP and RTCP. However, Cullen argued that the draft seemed to be primarily about QoS with some missing information at present. Source port information are only one piece of these missing bits but there is a whole lot more. He wondered why the draft did not concern itself with these additional missing parameters. According to Ingo, this was beyond the scope of the draft -- which was understood, but this exactly raised the issue of what precisely the draft tries to address.

    Joerg Ott noted that SIP signalling provides a clear separation between the precondition work to signal that some sort of QoS is required and the mechanism used to establish the QoS. The two pieces are currently separate: this draft tries to combine them, but it is not clear that they belong together. Joerg noted that the draft assumes entities on the path have access to the content, and that source ports are accurate, but we have generally assumed the opposite in the IETF. Magnus Westerlund agreed with Joerg and Cullen, further noting that with NAT traversal being an increasing issue it is often the case that an end point is not aware of its address as seen by the peer endpoint.

    In summary, the added value of this proposal is unclear.

    Harmonization between SDPng and MPEG-21


    Ingo Wolf presented further on a proposed harmonizatoin between SDPng and MPEG-21: He claimed that SDPng was transport-oriented while MPEG-21 DIA was technology-independent and focused on (media) presentation. He suggested an integration model in which all the SDPng containers are reused. The <cap>, <def>, <cfg> elements largely remain the same, only some adjustments are proposed to the RTP package. The <constraints> element is augments to cover Usage Environment Descriptions (UED) and should be used to address constraints all levels of abstraction. Important extensions include the reference to external definitions using the href attribute, the application of MPEG-7 media stream and codec spefications, and some revisions to name-value pair based mechanism for cross referencing definitions within an SDPng document. Ingo walked through a detalied example (see slides for the details).

    Steve Casner noted that the namespace for MPEG-21 has a huge overlap to the one defined in RFC3551. He further pointed out that to the extent that MPEG-21 identifies how transport is to be done, the RTP names identify actual payload formats. One cannot simply skip that identification as this is needed in additon to the codec identification. Brian Rosen agreed that one needs to explicitly specify the mapping. Colin noted that the key advantage of SIP/SDP is that peers can negotiate arbitrary MIME types. He questions the benefit from the proposal which is limited to a subset of the codecs that are supported through the MIME type mechanism and adds that the proposal does not support application/*, text/*, etc. Magnus Westerlund pointed out that the proposal allows to describe streams that cannot be transported, and Dirk Kutscher uttered similar concerns to Colin and Magnus.

    In summary, it is questionable how the approach presented relates properly to the work in MMUSIC, AVT, and other groups in the IETF at large.



    Dirk Kutscher presented the latest draft on SDPng. After a brief recap of the motivation and the overall structure, he stressed which aspects are not (supposed to be) covered by the SDPng base spec: application-specific vocaublary, application semantics, vocabulary for expressing constraints across multiple configurations, and vocabulary for metadata. This additional information needs be either specified as extensions/packages (e.g., transport protocols, codecs, packetization formats) or defined in the context of the respective applications (e.g., semantics).

    The changes in the most recent version include a more explicit inclusion of broadcast scenarios (cf. SAP, IMG), correspondingly make the <cap> element for negotiation optional, and the addition of descriptions of further scenarios. A "status" attribute has been added for the <component> elements and a new child element <part> is now allowed for the <info> element that allows encapsulating arbitrary meta description formats.

    Open issues at this point include: the status element is currently overloaded (and part of the semantics will be moved to the RTP package), IANA considerations need to be written (a registry for package information needs to be set up), XLM schema and DTD definitions need to be done, and the examples need to be aligned with the spec. Finally, at some point, the spec needs a real name (other than "SDPng"). The group is encouraged to review the spec now and comment so that WGLC before 63rd IETF is possible. Next steps to take further include completing the RTP package definition, dealing with a security package, and providing for meta descriptions.

    Info Wolf noted that he wants to see more discussion about how people could extend SDPng. Colin Perkins agreed with that and encouraged further work to be put into this.



    Magnus Westerlund presents the current status and some issues with the current revision of the RTSP specification. Due to shortage of time, he skips most of the stuff and starts with the issue of explicit white spacing (slide #5): he reviews the RTSP rules for white spaces as separators between tokes. He wants to change the use of "," and ";" to explicitly allow for whitespaces around them for which he seeks input from the group. Another (related) issue are the RTSP headers that are currently defined with reference to RFC 2616. However, RFC 2616 does not use RFC 2234 BNF with explicit white spacing. His suggestion is to copy the syntax into RTSP and make the whitespaces explicit.

    The chairs urge people to review the draft and comment.

    Internet Media Guides

    Yuji Nomura shortly described the recent activities regarding IMGs. Due to lack of time, he keeps the presentation extremely short: He briefly summarizes the interim discussions on the IMG envelope to carry metadata: the authors and a few others have discussed the use of XML as envelope systax vs. MIME encapsulation. Both can be defined (or extended) to provide the right functions for IMG envelopes and allow the re-use of existing specifications. XML is expected to require more work and be not as efficient to encapsulate binary data but MIME is not a perfect match either. Open issues are related to the inclusion/representation of versioning information and a metadata URI, a validity period, and proper authentication of subsets of IMG metadata. For the next steps, input from the group is sought: a new draft on an IMG envelope based upon MIME may be defined, the other drafts will be updated.

    - + -


    Introduction and Status update
    SDP Format for BFCP
    SDP Content Label
    SDP Connectivity Preconditions
    Stream Tracking for Resource Management in the Network
    Harmonization between SDPng and MPEG-21
    Internet Media Guides