2.8.8 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


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 2004  Review work on IMGs and update charter accordingly
Done  Submit SDP connection-oriented media draft for Proposed Standard
Nov 2004  Submit SDPng transition scenarios for Informational
Nov 2004  Submit SDPng base specification for Experimental
Nov 2004  Submit ICE draft for Proposed Standard
Feb 2005  Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
May 2005  Submit RTSP NAT considerations draft
Jul 2005  Consider update of SDP specification for draft standard
Dec 2005  Submit updated SDP Offer/Answer examples draft for Informational


  • draft-ietf-mmusic-sdp-srcfilter-10.txt
  • draft-ietf-mmusic-sdp-new-25.txt
  • draft-ietf-mmusic-kmgmt-ext-15.txt
  • draft-ietf-mmusic-sdpng-trans-04.txt
  • draft-ietf-mmusic-rfc2326bis-11.txt
  • draft-ietf-mmusic-rtsp-nat-04.txt
  • draft-ietf-mmusic-sdescriptions-12.txt
  • draft-ietf-mmusic-offer-answer-examples-06.txt
  • draft-ietf-mmusic-img-req-07.txt
  • draft-ietf-mmusic-ice-06.txt
  • draft-ietf-mmusic-img-framework-08.txt
  • draft-ietf-mmusic-comedia-tls-05.txt
  • draft-ietf-mmusic-sdp-media-label-01.txt
  • draft-ietf-mmusic-media-loopback-02.txt
  • draft-ietf-mmusic-sdp-bfcp-02.txt
  • draft-ietf-mmusic-securityprecondition-01.txt
  • draft-ietf-mmusic-connectivity-precon-01.txt
  • draft-ietf-mmusic-sdp-media-content-00.txt
  • draft-ietf-mmusic-fec-grouping-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
    RFC4145 Standard TCP-Based Media Transport in the Session Description Protocol (SDP)

    Current Meeting Report

    Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
    Reported by Colin Perkins
       The MMUSIC working group met once at the 64th IETF meeting (Vancouver,
       November 2005).  Topics under discussion included ICE, RTSP, RTSP/SIP
       inter-working, and SDP connectivity preconditions, security for early
       media, identification of QoS mechanisms for preconditions, seamless
       session mobility, and codec specific parameters. The meeting was chaired
       by Joerg Ott and Colin Perkins and attended by some 140 participants.
       Jonathan Rosenberg discussed the updated ICE specification starting with
       a summary of the extensive changes since the previous draft (see slides 
       for details), then moving on to a detailed discussion of the key changes. 
       The specification of how to use TCP alternatives with ICE has been 
       moved into a separate draft. There was some detailed discussion of the
       new draft, in particular Cullen Jennings asked why it's not possible to
       run ICE TCP using the same port as the original candidate pair? This in
       turn led to a discussion of simultaneous open, with Cullen and Flemming
       Andreasen discussing whether simultaneous open could be made to work in
       ICE TCP, to facilitate operation through symmetric NATs. It was noted 
       that a BEHAVE compliant NAT will allow simultaneous open without a TURN 
       relay, but this is not allowed in ICE TCP (since some operating systems 
       may have problems with simultaneous open of TCP connections).  It was 
       suggested that change ICE TCP from "MUST open from different port" to
       "MUST open from different port and MAY attempt open from the same port"
       to resolve this issue.
       The consensus of the room was that it is appropriate to accept ICE-TCP 
       as an MMUSIC work item.
       Robert Sparks noted that the new ICE draft has many examples, some of
       which are rather complex, and suggested splitting them out into a new
       draft to simplify the base draft. Jonathan wasn't keen on this, seeing
       benefit in the examples, and they compromised by agreeing to move the
       complex example to an appendix, replacing it in the main text with a
       simpler example.
       The -06 version of ICE solves the race condition noted during the 62nd
       IETF meeting using a mechanism based on PRACK and UPDATE.  There was a
       heated discussion of this mechanism, with many people complaining that
       PRACK and UPDATE are complex and difficult to implement, and requesting
       an alternative ICE formulation which doesn't require them. Others noted
       that this mechanism was discussed in a previous working group session,
       and suggested that the complexity argument was overblown. There was no
       resolution to this discussion in the meeting, and after a review of the
       issues, an ad-hoc meeting was scheduled to discuss the issues in detail
       later in the week (notes from the side meeting were sent to the mailing
       list on 14th November 2005).
       Magnus Westerlund reviewed the changes in the latest version of the RTSP
       specification. The main changes are: changed version number from 1.1 to
       2.0; updated the ABNF to conform to RFC 4234 and noted that any "string"
       in ABNF is case-insensitive; clarified use of the Allow header in SETUP
       and DESCRIBE methods, use of the Transport header parameter "mode", and
       use of SET_PARAMETER payloads. The specification is considered largely
       complete, except that the minimal implementation section needs revising,
       and there is a need for editorial review and simplification.
       Anders Klemets asked if the use of the Range header in PAUSE commands is
       a candidate for simplification, since it's one of the more complex parts 
       of the specification. Magnus replied that this isn't under consideration
       since its removal would remove the ability to signal "play exactly this
       The scheduled discussion of how ICE can be used with RTSP did not take
       place, due to the overrun of the previous ICE discussion.
    RTSP/SIP inter-working
       Jonathan Rosenberg briefly discussed RTSP/SIP inter-working, skipping his
       prepared presentation due to lack of time, and noting that there appears
       to be interest in this subject, and that he'll put together an initial 
       draft. People who are interested in this work should contact Jonathan
       to contribute to the proposal.
    SDP Content Attribute
       Jani Hautakorpi briefly outlined the concept of the SDP content attribute 
       draft, and noted that the latest draft is now clearly delineated from the 
       work done in other working groups. It also includes pre-defined values of
       the attribute. 
       Magnus Westerlund suggested that the next version of the draft clarify
       that the content attribute is declarative in the offer/answer model, not
       subject to negotiation. Joerg Ott encouraged review, reminding the group
       that it will take a while to setup the IANA registry to accept further
       registrations, so it is desirable to ensure the initial list of labels 
       is appropriate and largely complete. 
    SDP Connectivity Precondition
       Flemming Andreasen discussed the SDP Connectivity Precondition.  This
       completed working group last call without substantive issues, but the
       authors felt a few changes were warranted, and submitted the -01 draft.
       Changes in this version include: the recommended baseline method of
       connectivity checks for datagram transport was changed from RTP No-op to
       ICE; procedures associated with using ICE to verify connectivity were
       clarified; and it was clarified that the semantics of the connectivity
       preconditions do not include verification of the peer identify. This
       draft will be updated to match future changes in ICE, and is intended 
       to progress in tandem with ICE (on which there is now a normative
    Early Media for SDP Security Descriptions
       Dan Wing and Rob Raymond discussed early media and security descriptions
       for SDP.  The issue here is that early media can't be secured until the
       SDP answer arrives, and this can potentially cause clipping.  A possible
       solution is to use security preconditions, but this adds additional call
       setup time and is complex to implement, therefore this draft proposes to
       include a key for the called party to use in the initial SDP offer. This
       doesn't require PRACK of preconditions, and so is simpler to implement.
       There are some open issues regarding use of MKI, early media forking,
       and retargeting.
       Dave Oran repeated a comment from the ICE discussion that PRACK will be
       needed eventually, and that implementers need to accept its complexity.
       He also agreed that this is the logical solution, should one not wish to
       implement PRACK. There was discussion regarding the usefulness of secure
       early media, with the general consensus that it was useful. There was no
       consensus on this particular proposal however: an approach going forward
       would be to consider the requirements and constraints, and how they are
       addressed by existing mechanisms, before completing the details of this
    QoS Mechanism Identification in SDP
       Gonzalo Camarillo discussed a new draft that proposes ways to indicate
       which QoS mechanism is to be used for media streams.  This can be used 
       with the QoS precondition and the SDP offer/answer model, for example,
       to negotiate either RSVP or NSIS. Gonzalo posed two questions: is there
       a need to agree on something else in addition to the mechanism to use
       (e.g. parameters for the mechanism), and if so should the draft discuss
       how to agree those parameters?
       Flemming Andreasen asked how things like within-network RSVP proxies
       interact with this sort of mechanism? Jonathan Rosenberg asked where the
       fallback to a different QoS scheme was handled? E.g. if one wishes to
       try NSIS then fallback to RSVP when not available, is that handled by
       the QoS layer or does it need to be signalled in SDP? These questions
       led to further requirements discussion, rather than consideration of the
       details of the draft.
       There was no clear consensus to accept this as an MMUSIC work item. The
       chairs noted that there was general interest in the concept though, and
       suggested that draft be further revised as an individual draft with more
       requirements discussion, and we can revisit the decision to accept this
       as a work item at next meeting.
    Requirements for IPsec Negotiation in the SIP Framework
       Makoto Saito discussed requirements for IPsec negotiation in the SIP
       framework. This draft discusses why one might want to use SDP offer/
       answer with sdescriptions/mikey to negotiate IPsec parameters, which
       can be applied to secure the media streams.
       Colin Perkins noted that IPsec can be used to secure arbitrary sessions,
       not just multiparty multimedia sessions, and wondered if SDP offer/answer 
       is an appropriate base for such negotiation, or if this is outside the 
       scope of MMUSIC? Others, including Jon Peterson, considered this in scope, 
       since it requires extensions to sdescriptons. Jon Peterson and Joerg Ott
       noted, however, that there is no obvious community interest in the work,
       and as a result it seems premature to consider it as an MMUSIC work item.
    SDP Extensions for Seamless Session Mobility
       Xu Mingqiang discussed requirements for seamless session mobility,
       aiming to transfer a streaming media session between devices without
       disruption to the playout. Compared to the version discussed at the
       previous meeting, this draft contains a more detailed requirements
       discussion, without presupposing a particular solution.
       Magnus Westerlund and Colin Perkins noted that the draft still confuses
       several problems that should be treated separately, for example moving
       sessions between users and synchronised playout. Further clarification
       of requirements is needed, treating problems individually, rather than
       with a systems focus.
    Codec Specific Parameter in SDP
       Peili Xu discussed adding general codec parameters to SDP. There are two
       requirements here: 1) a per-codec equivalent to "a=ptime:", rather than a
       media level parameter as currently defined; and 2) codec level transport
       addresses, to divert certain payload formats away from the addresses on
       the c= and m= lines, for example to insert a transcoder. 
       Magnus Westerlund noted that the second requirement can be solved using
       a separate signalled session incorporating the transcoder. Joerg Ott and
       Colin Perkins agreed, suggesting both requirements might be solved using
       existing protocols and mechanisms. Further clarification of requirements
       and the degree to which existing mechanisms apply is needed before this 
       draft can proceed.
    				   - + -


    SIP for Streaming
    SDP Content Attribute
    SDP Connectivity Precondition
    Early Media for Security Descriptions
    SDP QoS Mechanism Identification
    Requirements for IPsec negotiation in SIP
    SDP Session Mobility Attribute
    SDP codec parameters