2.8.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-29

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 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 (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 families).

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

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

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
Jun 04  Submit IMG requirements and framework for Informational
Jun 04  Submit RTSP MIB for Proposed Standard
Aug 04  Review work on IMGs and update charter accordingly
Aug 04  Submit revised SDP spec for Proposed (or Draft) Standard
Aug 04  Submit SDP Offer/Answer examples for Informational
Aug 04  Review work on IMGs and update charter accordingly
Sep 04  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-18.txt
  • - draft-ietf-mmusic-sdp-comedia-08.txt
  • - draft-ietf-mmusic-kmgmt-ext-11.txt
  • - draft-ietf-mmusic-sdpng-trans-04.txt
  • - draft-ietf-mmusic-rfc2326bis-07.txt
  • - draft-ietf-mmusic-sdp-bwparam-06.txt
  • - draft-ietf-mmusic-rtsp-nat-03.txt
  • - draft-ietf-mmusic-sdescriptions-07.txt
  • - draft-ietf-mmusic-offer-answer-examples-04.txt
  • - draft-ietf-mmusic-img-req-07.txt
  • - draft-ietf-mmusic-ice-02.txt
  • - draft-ietf-mmusic-img-framework-08.txt
  • - draft-ietf-mmusic-anat-01.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

    Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes

    Reported by Colin Perkins and Joerg Ott

    The MMUSIC working group met once at the 60th IETF in San Diego. Subjects under discussion included various SDP extensions and new attributes, remote call control using Mbus, the ICE methodology for NAT traversal, and the RTSP specification update.

    Introduction and Status Update

    The meeting started with an introduction and status update by the chairs. We have had no RFCs published recently, although the SDP bwparam draft is with the RFC Editor. Several drafts are under IESG or Area Director review: the IMG requirements and framework, kmgmt and sdescriptions. The ANAT spec and the revised SDP spec have been reviewed by the IESG and are being updated in response to comments received. Working group last call is complete on the comedia spec and offer/answer examples, and both are expected to go to the IESG shortly.

    It was noted that the new charter and milestones have been accepted, although the milestones on the web-page appear to include both old and new milestones (this will be corrected). We have a milestone to decide on how to proceed with the IMG work, which may result in a charter update (this is under discussion between chairs, area director and IMG authors). Besides this, there are no further charter updates planned.

    Connection-Oriented Media Transport over TLS

    Jonathan Lennox discussed draft-ietf-mmusic-comedia-tls-01.txt. Aim is to provide privacy, authentication, and integrity for connection oriented media using TLS. TLS uses X.509 certificates, so there is a need to specify what identities should be asserted: host-based derived from SDP "c=" line; the certification that secured the SDP end-to-end (e.g. S/MIME or HTTPS, not SIPS); a URI-based identity derived from the protocol transporting the SDP, etc. There is also a need to support the use of self-signed certs by sending certificate fingerprints in SDP, since CA-signed certificates are expensive, hard to configure, etc. This concerned Jon Peterson, who is worried about the allowed identities and integrity validation of the SDP. There was some controversy if integrity validation should be required as a "SHOULD" or a "MUST" level feature, with Cullen Jennings arguing for "MUST", but Jon Peterson arguing in favour of the SSH model, with "SHOULD".

    An open issue is that this defines only TCP/TLS, not TCP/TLS/RTP/AVP. Similarly, nothing defines TCP/RTP/SAVP. What should be the preferred way of doing secure connection-oriented RTP? Steve Casner suggested that it might be appropriate to wait until there is a use case for SRTP over connection oriented media, rather than trying to specify it now.

    A related problem is the combinatorial explosion of RTP profile names. Steve Casner agreed that the explosion of names is a potential problem, but noted that the work needed to specify new profiles would limit them to those that are useful.

    Connection Establishment Preconditions

    Gonzalo Camarillo discussed draft-camarillo-mmusic-connection-precon-00. The motivation for this draft is that connections cannot be established until the bearer channel is ready, and some applications want to know that the connection is established and ready to transfer data, before alerting the user. This does not interact with QoS preconditions, since it represents a separate issue: the connection precondition cannot be met until the QoS precondition has been met.

    Magnus Westerlund asked if connection establishment is just for TCP, or if it can be used for any transport? Any, potentially, provided there is a notion of a connection.

    The consensus of the room was that this is appropriate as an MMUSIC work item.

    Alternate Offers/Capabilities in SIP/SDP

    Medhavi Bhatia presented draft-bhatia-mmusic-sdp-altcap-01.txt. This is an attempt to solve three classes of problem: better negotiation of codec capabilities, better negotiation when using encryption of SDPng, transparent transport of H.323 or other messaging through a SIP core. Proposal is to use MIME multipart entities in an offer/answer exchange, with content-ID and a (to be defined) Content-Reference header in each to allow an answer to indicate which MIME body in the offer is being responded to.

    Jonathan Rosenberg, Rohan Mahy and Jon Peterson commented on various aspects of the problem statement, and on the interoperability issues with how this relates to other solutions. There seemed to be consensus that the encrypted/non-encrypted issue was a real problem, but it was not clear that there was agreement on the other issues. Joerg Ott requested that the next revision to the draft include a more clear problem statement, so we can better decide how the solution fits.

    SDP for T.120

    Joerg Ott outlined draft-ott-mmusic-sdp-t120-00.txt. T.120 is a TCP based protocol used for various applications, such as shared white-board and application sharing. It can be signalled using H.323, but not with SIP/SDP. The draft proposes a simple approach to support this in SDP: use comedia for connection set-up, indicate desired T.120 applications via SDP attributes, and provide bindings of T.120 conferences to SIP dialogs. This is a straw-man proposal and won't progress without an expression of interest. Feedback is solicited from anyone using T.120 in the context of SIP.

    SDP Media Label

    Gonzalo Camarillo discussed draft-levein-mmusic-sdp-media-label-00.txt. The motivation here is to provide a means to label "m=" lines in an SDP session description so that they can be referenced by an external application. The scope is intended to be wider than an offer/answer exchange, for example to allow references from an XCON XML document. Gonzalo explained why existing attributes cannot be used: the "i=" line is for display purposes only, and the "a=mid:" provides "m=" line identifiers within the scope of an offer/answer exchange only. He also noted that there is a bidirectional requirement, where a server needs to reference a direction of a media stream.

    There was considerable discussion on this topic, relating to the choice of a semantic-free label rather than referencing a particular "m=" by it's position in the SDP file, or by using some existing attribute. It seems clear that there is interest in the problem, but that the authors need to clarify their rationale for this particular solution. The room consensus was to accept this as a work item.

    Mbus Extensions

    Rohan Mahy outlined draft-mahy-mmusic-mbus-sdp-00.txt. This proposes a way to signal an Mbus control session in SDP, bootstrapping between SIP devices that are geographically close but not topologically close. It solves the discovery and keying problems with Mbus, and works with NAT and firewall traversal (e.g. using STUN). It does not address the congestion issues present in wide-area use of Mbus.

    Rohan also outlined draft-mahy-mmusic-remotecc-00.txt. This takes the long expired draft-ietf-mmusic-mbus-call-control draft and proposes a split between call control verbs and notifications, and a re-factoring of the call control verbs. It was noted that the Mbus is defined for multipoint usage, and asked if it fits unicast call control? Yes, mostly: see the draft for details.

    After describing the work, Rohan solicited input on these drafts, and discussion of requirements. Comments should be sent to the mailing list.

    ICE: A Methodology for NAT Traversal

    Jonathan Rosenberg presented an update on draft-ietf-mmusic-ice-02.txt Due to the crowded agenda, he restricts his presentation to a key open issue: concerns were raised that, as specified today, STUN is run as a shim layer on top of other protocols (such as RTP). This requires multiplexing of RTP media and STUN packets -- which is not so difficult for RTP as it can be done by looking at the first two bits. On the upside, it allows STUN to be re-initiated mid-stream as needed. Jonathan also discusses possible options: 1) always require STUN (initially and for keep-alives). 2) Allow for other keepalive mechanisms but define STUN right now. 3) Not do STUN at all but solve the problem for RTP by SSRC muxing. 4) Separate initial and mid-call: Use STUN only for the initial check and then do RTP with no checks. He notes that such a separation may have issues with packet misordering and that no recovery (state loss, route flap) is possible.

    Discussion in the room clearly shows that there are concerns with the approach currently taken. It is proposed to consider initial and midstream checks independently. The initial check could also be performed using a connectivity precondition as defined for SDP O/A thereby avoiding the need to do muxing there. The importance of the midstream check is questioned (how likely is this?). Statements are made that the mid-stream case should be dropped. Another opinion was voiced that STUN appears to be the right choice for both initial and mid-stream. Jonathan notes that the mid-call stun doesn't allow you to continue operation in all cases. A question comes up that, if needed at all, whether or not mid-stream STUN is just an optimisation. Could one use another offer as an option? Jonathan would like to avoid such options.

    Whether initial or mid-stream, the need for muxing STUN and RTP arises. A point is made that there is a need to indicate that a stun server should run on the port. It would be helpful if the SDP could indicate something that was in the packets to help demuxing (rather than assuming you can do it using the first 2 bits) -- this would make the approach suitable beyond just RTP.

    Further points are made mid-stream may show up in RTSP when the client is in pause mode and therefore no RTP traffic is sent to it. There would be a need to either reply to mid-stream STUN or RTP noop packets. It is noted that a similar problem exists with SIP for calls with media on hold.

    A comment is made that we disapproved the ITU's muxing T.38 over UDP with RTP on the same port and hence we should not be pursuing a similar -- equally ugly -- approach. Jonathan points out that NATs are ugly and that they fundamentally require to run STUN on the same port (if only for the initial connectivity check). To avoid the necessity for de-muxing (for dealing with re-ordered packets) the idea is brought up to do a three or four phase exchange and rewriting STUN accordingly.

    The consensus of the group is that the initial STUN check is pretty much accepted. There is concern for running STUN mid-stream, and as a keep alive.


    Magnus Westerlund discussed RTSP (draft-ietf-mmusic-rfc2326bis-07.txt) starting by highlighting the major recent changes to the draft: use of TLS over TCP for RTSP has been defined ("rtsps" -- an example connection was shown), use of the authorisation mechanisms taken from HTTP has been clarified, and a new chapter has been added that defined use cases. Many minor changes were also enumerated (see slides).

    Open issues include: which keep-alive mechanism should be normative? should refusal by a server to perform media redirection have its own error code? should we change use of Accept-Language/Content-Language? are the current methods to prevent undesired media redirection okay? is the availability of protection against hijacking sufficient? are clarifications on how re-SETUP works needed? is there a need to specify implicit redirect? how can "#" and "?" in URIs be used? does proxy use need to be clarified? and, finally, are the changes sufficiently backwards compatible, or do we need to raise the RTSP version number?

    Magnus solicited review from the group, since the spec is getting into good shape. Editing work will continue between the meetings, and phone conferences may be organised to discuss particular issues. The aim is to have the spec ready to last call after the next meeting.

    RTSP NAT Traversal

    Thomas Zeng discussed draft-ietf-mmusic-rtsp-nat-03.txt. After giving a recap of the requirements, a new candidate solution was outlined: a variation of symmetric RTP using probe packets. Then, Thomas gave an overview of the five candidate solutions: STUN, ICE, symmetric RTP, variation of symmetric RTP, and TURN; and outlined some of their pros and cons. He noted that the ICE framework, while a more general solution than some of the others, is complex and depends on TURN which is not needed when the RTSP server is in the open -- expected to be the common case. Jonathan Rosenberg explained the motivation of supporting TURN: it ensures that the ICE method always works, even in all edge cases.

    It is clear that the working group needs to recommend a common RTSP NAT solution in order to meet market demand. The ICE method has potential, but there is a need to co-ordinate to ensure that the spec is completed in time, especially TURN, to also a need to define the mapping of ICE onto RTSP.


    Thomas Zeng outlined draft-zeng-mmusic-rtsp-announce-00.txt. This is a continuation of draft-zeng-rtsp-end-of-stream-00.txt (presented during IETF-58), with the aim of extending the ANNOUNCE mechanism to publish events such as end-of-stream with a new header. It can run both client to server and server to client. The specification of the method was briefly described. Anders Clemets expressed concern about overloading of methods, although since this is written as an extension and the ANNOUNCE method is removed from the core spec, this should not be too bad. The consensus of the room was that this should become a work item.


    Connection-Oriented Media Transport over TLS
    Connection-Establishment Preconditions
    Alternate Offers / Capabilities in SIP/SDP
    SDP for T.120
    SDP Media Label
    MBus Extensions
    Real-Time Streaming Protocol
    RTSP NAT Traversal Update