2.7.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


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
Done  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-09.txt
  • draft-ietf-mmusic-sdp-new-25.txt
  • draft-ietf-mmusic-sdp-comedia-10.txt
  • draft-ietf-mmusic-sdpng-08.txt
  • draft-ietf-mmusic-kmgmt-ext-15.txt
  • draft-ietf-mmusic-sdpng-trans-04.txt
  • draft-ietf-mmusic-rfc2326bis-10.txt
  • draft-ietf-mmusic-sdescriptions-11.txt
  • draft-ietf-mmusic-offer-answer-examples-06.txt
  • draft-ietf-mmusic-img-req-07.txt
  • draft-ietf-mmusic-ice-05.txt
  • draft-ietf-mmusic-img-framework-08.txt
  • draft-ietf-mmusic-comedia-tls-04.txt
  • draft-ietf-mmusic-sdp-media-label-01.txt
  • draft-ietf-mmusic-rtsp-announce-01.txt
  • draft-ietf-mmusic-media-loopback-01.txt
  • draft-ietf-mmusic-sdp-bfcp-02.txt
  • draft-ietf-mmusic-securityprecondition-00.txt
  • draft-ietf-mmusic-connectivity-precon-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)
    RFC4091 Standard The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework

    Current Meeting Report

    Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes

    Reported by Colin Perkins

    The MMUSIC working group met once at the 63rd IETF meeting (August 2005, Paris). Topics under discussion included RTSP, ICE, SDP extensions for congestion status reports, buffer handling for mobility, media loopback, and content identification, requirements for IPsec negotiation, and Data Broadcasting Services. The meeting was chaired by Joerg Ott and Colin Perkins, and attended by approximately 160 people.


    Magnus Westerlund outlined the changes since the previous version of the RTSP specification (outlined in the slides), and discussed open issues.

    Open issue: the state machine is not useful, due to automatic transfers between states, and the weak synchronisation between client and server. Magnus suggested making the state changes explicit in the protocol, with notification messages to indicate transitions. Anders Klemets expressed concern about the complexity this may introduce, noting similarity with the ANNOUNCE method. Dave Singer wondered if the transition from playing to paused could be made explicit by adding a header to the play response to state "if you do nothing else, at this time you'll be in pause", and if this would be closer to current SDP.

    Open issue: should the Allow header be included in DESCRIBE and SETUP? Anders noted that, if you support all the "normal" methods, then there is no need for the Allow header. However, if you support only a subset of the methods, or if you support additional features, Allow header is strongly recommended. Magnus agreed, and will make Allow conditional on the presence of unusual/missing features.

    Open issue: the "minimal implementation" section is difficult to make consistent with the rest of the specification, and allows implementers to be fooled into thinking they know what is required without reading the rest of the specification. Since the new specification is clearer than RFC 2326, Magnus suggests removing this section. Anders asked for this to be kept, since the specification is so big. Dave Singer asked if the minimum implementation section should say to implement all the draft, and highlight the non-obvious points. Resolution: need to keep this section, but perhaps update its content.

    Magnus made a plea for reviewers, offering to buy a beer for anyone who does a complete review! Dave Singer wondered if a reviews could be solicited from ISMA or 3GPP, since they make heavy use of RTSP.

    Magnus concluded by presenting some initial thoughts of the use of ICE with RTSP, and outlining a possible call flow to show where the checks can fit into the RTSP negotiation.


    Jonathan Rosenberg summarised the changes in the latest version of the ICE specification (see slides). There are still five open issues which were discussed.

    Open issue 1 (STUN floods): general agreement with the proposed fix. Francois Audet noted that if the draft gives the impression hundreds of checks are needed, then people won't do the check at all - need to give reassurance in the draft, and perhaps explain that applications can stop after finding a working address. Dan Wing expressed concern about mid-call changes, and the effects these have jitter buffers in the applications. Dan also noted that STUN checks increase number of NAT bindings even when made mid-call, and may cause failures because of this load no matter when the STUN check is made.

    Open issue 2 (TCP or not TCP): lots of discussion, with Cullen Jennings, Dan Wing and Francois Audet arguing that inclusion of TCP support will delay the draft and introduce unnecessary coupling that might discourage implementers, and Jonathan Rosenberg, Magnus Westerlund, Dave Oran, and Jon Peterson arguing that TCP support should be included to compete with proprietary solutions. The sense of the room was to split TCP usage with ICE out into a separate draft, since the controversy surrounding the TCP support would delay the progression of the base ICE draft.

    Open issue 3 (default timers) was skipped due to lack of time. Please review and comment to the mailing list.

    Open issue 4 (STUN authentication and SIPS): no objection. Robert Sparks noted that the "sips is SHOULD use" is a requirement where people won't do it; the draft needs text making it very clear that this is essential.

    Open issue 5 (normative dependency on STUN). Propose to reference RFC 3489 instead of the 3489bis draft, due to questions over the timing of the 3489bis draft. No objections.
    Requirements for IPsec Negotiation in the SIP Framework

    Makoto Saito presented some requirements for using SIP as a key exchange protocol to negotiate IPsec parameters for media streams. Francois Audet wondered if the SDP key management work was appropriate for this task. Colin Perkins asked for clarification on the requirements: why is this solution appropriate, and why not use existing methods for negotiating IPsec keys? The chairs noted that it's unclear MMUSIC has the experience to review this work, and deferred a decision to take this as a work item until it has received more review.

    Requirement of service provider for the Data Broadcasting Service

    Lark Kwon Choi presented some requirements for the data broadcasting service over IP networks. There were several questions seeking to clarify the requirements and understand what was needed from MMUSIC, but no conclusion was reached during the session. Further discussion will happen on the mailing list.
    Congestion status precondition

    Corey Alexander presented a congestion status precondition, for use with the SDP preconditions framework and SIP. Discussion focusses on the SDP parameters, rather than on the mechanism for monitoring congestion (that was discussed in AVT and TSVWG).

    Dan Wing asked why, if an RTP payload format is used, it's not signalled in the SDP? Corey explained that the ECN probing format isn't media used in the session and so didn't need to be signalled. Dan expressed concern about this inconsistency. Jonathan Rosenberg noted that this is similar to STUN, which isn't signalled on the "m=" line either, since it's not a media format: maybe "a=candidate" lines would be a better fit, with STUN packets carrying the ECN probes rather than RTP packets?

    Joerg Ott wondered if congestion state is a persistent property that can be represented in the session state; ephemeral network characteristics are not usually considered appropriate to signal in SDP.

    Dave Oran asked if the existing SDP "qos" precondition couldn't be used as a congestion status precondition, treating unmarked ECN probes as evidence that the required QoS has been achieved?

    Colin Perkins concluded by noting that there is some clear concern over this proposal. Further discussion is needed on the mailing list, after the other aspects have been discussed in AVT and TSVWG.
    Buffer handling attributes

    Xu Ming Qiang presented SDP buffer handling attributes for mobility. Magnus Westerlund commented that the synchronisation issues are much greater than discussed here, and that it's not clear that the simple mechanisms described solve the problem. Dave Oran agreed, and would like to see the synchronisation and media slicing problem understood before we work on the signalling.
    SDP content attribute

    Jani Hautokorpi discussed the SDP media content attribute. This has been updated as a result of comments at the previous meeting, and there seems to be a reasonable amount of interest.

    Joerg Ott asked for clarification whether attributes are an enumeration of properties, or if there is just a single attribute per channel. Joerg also commented that the draft needs to clearly define the borderline for what makes a reasonable attribute.

    A decision regarding taking this as a work item was postponed to the mailing list.
    SDP media loopback

    Kaynam Hedayat discussed the SDP media loopback draft, summarising the changes since the previous version (introduction of an additional type of loopback: rtp-start-loopback). Joerg Ott asked that the attributes be named "loopback:..." rather than "...-loopback", but otherwise there were no comments.

    - + -


    Introduction and Status Update
    Requirements for IPsec Negotiation in the SIP Framework
    Requirement of service provider for the Data Broadcasting Service
    A Congestion Status Precondition for SIP
    Buffer Handling Media Attribute for Seamless Mobility
    SDP Content Attribute
    SDP Extension for Media Loopback