Multiparty Multimedia Session Control (mmusic) Charter

Current Meeting Report
Slides

2.8.8 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/23/2002

Chair(s):

J. Ott <jo@ipdialog.com>
Colin Perkins <csp@isi.edu>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>

Transport Area Advisor:

A. Mankin <mankin@isi.edu>

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 sessions. These protocols are now reasonably mature, and many of them have received widespread deployment. MMUSIC is now focussing on the revisions of these in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO).

All types of multimedia communications are based upon a common platform for expressing media streams (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 for key applications of SDP. MMUSIC will revise the SDP specification suitable for publication as a draft standard to address minor revision and further support the current broad deployment. Work on an SDP MIB will be considered.

Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings: However, these are limited to, adding means for identifying and semantically grouping media sessions, providing limited expressiveness for simultaneous capabilities, use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls, and documenting the use of SDP in SIP as a separate document. Existing key exchange per media session in SDP will be cleaned up in a revision of that portion of RFCxxxx. 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 -- such as 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 standards track document. A requirements document will be devised that gathers the individual requirements from the areas in which SDP is currently deployed. Work on an SDPng MIB will be considered.

MMUSIC will continue to maintain and revise the specification of the Real Time Streaming Protocol (RTSP) based on implementation experience. The RTSP spec will be revised to include various fixes and clarifications. Depending on the changes, the revised RTSP spec will be re-issued as Proposed or go to Draft Standard. A MIB will also be defined.

The WG's 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 will 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		Submit SDP to the IESG for consideration as a Proposed Standard.
Done		Submit a revised SIP I-D.
Done		Submit a revised Internet Multimedia Conferencing Architecture I-D.
Done		Conduct WG Last Call for SAP Internet-Draft
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?)
FEB 02		Submit revised SDP spec for Proposed (or Draft) Standard
FEB 02		Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.
MAR 02		Submit SDP key management for Proposed Standard
APR 02		`Submit SDPng base spec and audio profile for Proposed Standard
MAY 02		Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)
JUN 02		Submit SDPng video profile spec for Proposed Standard
JUL 02		Submit RTSP MIB for Proposed Standard
JUL 02		Conclude WG

Internet-Drafts:

- draft-ietf-mmusic-sdp-srcfilter-01.txt

- draft-ietf-mmusic-sdp-new-10.txt

- draft-ietf-mmusic-fid-06.txt

- draft-ietf-mmusic-sdp-comedia-03.txt

- draft-ietf-mmusic-sdpng-05.txt

- draft-ietf-mmusic-sdp4nat-02.txt

- draft-ietf-mmusic-kmgmt-ext-05.txt

- draft-ietf-mmusic-sdpng-trans-01.txt

- draft-ietf-mmusic-rfc2326bis-01.txt

Request For Comments:

RFC	Status	Title
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

Current Meeting Report

Multiparty Multimedia Session Control Working Group Minutes
===========================================================

Reported by Colin Perkins, Joerg Ott and Tom Taylor

The MMUSIC working group met from 9:00-11:30am on Thursday July 18th, at the 54th IETF meeting in Yokohama. The group discussed SDP source filters, SDPng, conference and media control, metadata and RTSP.

Introduction and Status Update

The meeting started with an introduction and status update from Joerg Ott. The group has had three RFCs published since the last meeting: A Message Bus for Local Coordination (RFC 3259), An Offer/Answer Model with the Session Description Protocol (RFC 3264) and Support for IPv6 in Session Description Protocol (RFC 3266). There are three drafts in IESG last call:

- draft-ietf-mmusic-fid-06.txt
- draft-andreasen-mmusic-sdp-simcap-05.txt
- draft-ietf-mmusic-sdp-new-10.txt

and several others which are close to completion:

- draft-ietf-mmusic-sdp-comedia-03.txt
- draft-ietf-mmusic-sdp4nat-02.txt
- draft-ietf-mmusic-kmgmt-ext-05.txt

The working group is making good progress on its charter milestones, with the exception of RTSP which proved over-optimistic (looking at year end for completion). We also have several potential work items:

- Dissemination of program scheduling info
- Conference control, including:
- floor control
- media control
- interactive real-time control

These are all currently out of scope of charter, and the correct home for this work has yet to be decided.

SDP Source Filters

The SDP source filter draft (draft-ietf-mmusic-sdp-srcfilters-01.txt) has been revived after two years. This is fairly straightforward, and suitable for supporting SSM. The Chairs urged people to read it, and comment.

SDP Key Management

The SDP key management draft (draft-ietf-mmusic-kmhmt-ext-05.txt) is basically done, but there is a philosophical argument over encoding key management attributes: are they encoded explicitly in SDP, or tunneled as an opaque blob within the SDP description? We need to resolve this issue, and pick a solution.

Henning Schulzrinne asked: what kind of blob is used? Is there a standard crypto key mgmt blob? Answer: current blob is aggregate of standard blobs. Henning suggested talking to a security advisor, to see how other protocols handle this. There was no resolution.

SDPng update

Dirk Kutscher presented SDPng (draft-ietf-mmusic-sdpng-05.txt). Changes in the -05 draft include consoldiation, removing the introductory and motivation sections, moving the examples and profile definitions to appendices, simplification and unification of reference mechanisms, and updates to the XML-schema.

The draft previously had different mechanisms for referencing. This version uses a general attribute, "ref", for elements that should be referenced, for example basic audio codec definitions and incremental definition by overwriting/extension of references. This is cleaner, but a small restriction on the previous semantics. There is an open issue: the new solution only allows for augmenting and changing definitions, it doesn't allow element content to be changed. Changing element content is more demanding for implementations, and has unclear semantics for overwriting a (partially) existing element tree; hence the proposal is to restrict extension to attributes.

A number of changes SDPng XML schema have occured: adapt the new referencing mechanism and fix bugs, changed some GIs. It was noted that XML Schema vs other schema definition mechanisms is not simple, but the authors couldn't find a better alternative. Accordingly they will stick to the XML schema.

The previous version of the draft contained sample definitions of two profiles: audio codec profile and RTP profile. These have been moved to an appendix in -05, and will eventually be published as separate drafts. It is expected that a guidelines document for profile writers will be needed, either separate or integrated into the main spec. Contributions on other profiles were solicited: complete the RTP profile, provide profiles for video codecs, metadata, and QoS.

There are a number of open issues: capability negotiations (work in progress) and requirements for using external definitions (in progress, but more implementation experience required).

The next steps are to provide guidelines for profile authors, re-submit SDPng base specification removing the profiles, and submit individual profile drafts.

Gonzalo Camarillo noted on list that we are reinventing some aspects, especially with respect to negotiation. Jonathan Rosenberg noted that RFC 2533 turns out to provide a fairly complete framework - found it adequate for caller preferences. Particularly desirable to have a common view of capabilities - lends itself to group.

Codecs and RTP payload formats in SDPng

Anders Klemets presented some thoughts on codecs and RTP payload formats in SDPng. He noted that there may be more than one RTP payload format for any given codec (e.g. MPA, MPA-ROBUST), and that it would be nice to minimize redundancy. The proposal is: don't tie the codec to a specific RTP payload format, instead add a new "format" attr in RTP: pt definition to convey the payload format along with pt= attribute for payload number (slides have an example).

It was noted that the bit rate of codec cannot always be deduced from "sampling" attribute (e.g. variable bit rate MP-3), and that the RTP payload format may add extra overhead, increasing the bit rate (e.g. FEC, RED). Anders therefore proposed adding bitrate attributes for the "rtp:pt" and "audio:codec" tags (slides have an exmaple).

Anders also noted that RTP session that use multiple payload formats make it impossible to determine the total bit rate of the session. He again proposed an additional bitrate attribute: the time for the rtp:session tag, for cases where bit rates not additive.

Some RTP payload formats don't have a codec, because they encapsulate others (e.g. parityFEC, RED, Interleaving). For such payload formats, some codec attributes need to be specified on the "rtp:pt" tag (e.g. "sampling" and "formatdata"). Slides have an example.

In addition, it is possible that we may need a "Bitspersample" attribute and a "language" tag for international content (the "constraints" section can specify how to choose among streams based on a language preference; or it could also be specified as metadata inside "conf" tag).

For video codecs, a "video:codec" tag could have several attributes:
- name
- encoding
- version (distinguish between codec revisions)
- bitrate
- imagewidth, ...

Considering SDPng usage with RTSP, a new "rtsp" tag at "component" tag level was suggested. There is no need for an "rtp:rtsp" tag, since the transport is negotiated in an RTSP SETUP command. A new "rtsp" tag in conference section will also be needed, to specify the presentation URL.

In summary, the proposal is to separate codec definitions from RTP payload fmt definitions. An open issue: specification for non-A/V media? This would require a separate SDPng profile for each, or the definition of a catch-all tag with scaffolding within which details can be defined (e.g. "application/codec"?).

Steve Casner noted that payload types and codecs are not independent, for example with the RED format, and hence he doesn't see motivation for separation.

Dirk Kutscher noted reservations on proposed formats -- might need to complete RTP profiles. Also not sure language specification is done right. Agreed it needs careful study. Noted that the meta section provides some capabilities

It was noted that, for network bitrate, need to make assumptions on what it includes precise. Henning Schulzrinne noted that the network level bitrate may not be known, may not know if header compression used. Anders: value may be in relative rather than absolute value. Henning: also, codec supports ranges of bandwidths -- may need ranges. On language, single stream may oftem support multiple languages, have to be able to express this. Final note: looking like reinvention of MPEG-7. Someone has to go through MPEG-7 and decide whether we should use it.

Steve Casner: re multiple bit rates - SDP can't express the ability to operate at different levels, can't negotiate. Want to express in such a way that negotiation is possible.

Some discussion of which bitrates needed. Henning Schulzrinne: pure encoded media rate is needed, of interest to codec.

It is expected that discussion will continue offline.

MMUSIC and Conference/Media Control

Joerg Ott introduced conference/media control, noting that the potential control areas include:

- navigating spatially in media streams
- conference/floor control
- commands/indications

The group must decide what fits on our plate/in our charter.
There are two drafts in this area that have been mentioned:

- draft-prandolini-mmusic-jpip-requirements-00.txt
- draft-even-mmusic-video-media-control-00.txt

plus there is work ongoing in SIPPING in this area.

Rohan Mahy presented the conference/media control work plan for the SIPPING working group. SIPPING is concentrating on tightly-coupled conferences:

- locally mixed
- central mixed (composed, decomposed)
- centrally controlled with distributed media (multi-cast, unicast)

The group is to address control, not media mixing. The goals are to establish a consistent goal/vision, capture high level requirements and scenarios, and discuss mechanisms and requirements for invitations, joining, leaving and membership control. These could be SIP and or non-SIP mechanisms. There will be a design team to work on requirements and framework, splitting out of scope work to hand to MMUSIC and/or AVT. It is expected that media-specific behaviour (media layout and presentation) and floor control (control access to shared limited resource) could be send to MMUSIC.

Steve Casner noted past history, and previous failures of this work. Henning Schulzrinne suggested that we have more tools now, and might succeed. There were some process concerns - finding home for the work. Joerg Ott welcomed discussuion on MMUSIC list, regardless of final disposition.

SDP attributes for Video Media Control

Roni Even discussed draft-even-mmusic-video-media-control-00.txt, on SDP attributes for video media control. This draft notes that SDP is a number video attributes considered crucial for some applications and proposes to add support for for frame rate and resolution dependency. There was agreement that these attributes are needed, and a number of minor fixes to the draft were suggested.

Another proposed requirement is for a receiver to request that the sender generate an "intra" (independent) picture, for example when switching to new video source, or picking a new video from a multicast channel. There is also a need for a freeze request to prevent display of garbage during switchover. Freeze request was accepted as valid in discussions on the mailing list, since it changes the state of stream. This leaves intra request as an issue for discussion.

There are several alternatives: SIP conference package, RTCP, RTP in a reverse channel, SIP INFO, SDP intra-only and intra+inter attributes, and an SDP "New stream" attribute. Roni argued that the only viable solution was a "new stream" attribute sent in SDP. There was much discussion on the subject, with no consensus that this new attribute was appropriate.

Jonathan Rosenberg suggested that this is part of a more general media control problem, and that the real point of the discussion is trade-off between a ashort term solution versus a more global solution. Henning Schulzrinne noted that RTCP is reliable over long enough time period, and that before discarding this option it is necessary to establish the timing requirments. Roni noted an architectural issue: the media switcher may not have access to RTCP. Orit Levin distinguished between the usual RTCP feedback and reporting and application controls like this one, noting that they have different requirements. She also expressed the opinion that the freeze and intra requests are the only thing in the way of good viewer experience. Jonathan Rosenberg again noted the need to understand architectural issues, and asked why the solution documented for H.261 cannot be generalised and reused?

There was much discussion over a "MUST" in specification: we cannot put a MUST on something which may cause congestion, and an application that responds to an intra-request in all cases has the potential to cause congestion (the draft needs to say "SHOULD" and note that there may be reasons, for example congestion control, why the intra-request will be ignored by the sender).

The discussion was curtailed due to lack of time with no consensus.
It continued during in the AVT session, later in the IETF (see the minutes of the AVT working group).

Metadata Update Protocol

Yuji Nomura outlined the metadata format and update notification protocol from draft-nomura-mmusic-pguide-requirements-00.txt and draft-nomura-cdi-mmusic-mupdate-00.txt. He briefly reviewed the requirements, introducing MPEG-7 DDL and its application by the TV Anytime Forum for electronic programme guides, and other activities such as DVB-IPI, iEPG, and proprietary EPGs such as those used in Replay TV and TiVo.

Yuji listed detailed requirements for such a protocol:

- on-demand retrieval
- simple update notification mechanism
- managing metadata status on a server and client
- delta description methods

The draft considers use of SIP event notification as such a protocol.
Looking for home for delta description work. Webi was closed, CDI is focussed on requirements definition.

Joerg Ott presented a slide on DVB-IPI, and noted that we don't want to acquire understanding of how to describe TV programmes, but asked if some sort of framework is needed to tie these things together?

Joerg showed two more slides comparing Nomura and DVB-IPI proposals.
He suggested a hybrid solution as a way forward. What is needed?

- Keep content format open: SDPng, MPEG-7, etc
- Define a content-indirection format
- Define retrieval and distribution models

MMUSIC may do the SAP and SDPng parts. Discussion was solicited on the mailing list.

Revised RTSP spec

Magnus Westerlund discussed RTSP (draft-ietf-mmusic-rfc2326bis-01.txt), starting with a list of changes in the -01 version: header table in chapter 12, updates HTTP references to RFC 2616, rewritten the state machine chapter, added PING method, added an considerations section, clarified usage of range with open start time, and clarified usage of pause point. Several issues were up for discussion: feature discovery, protocal extensions: IANA section, persistent connections, redirect, connection related feature tags, and OPTIONS method implementation requirements.

Magnus noted that the current extensibility and feature discovery uses Require, Proxy-Require and Unsupported headers. It cannot be used to check if the other party does support a feature. One proposal is to add a Supported header, borrowed from SIP. The problem is that, in RTSP this can lead to bloated message sizes. Another proposal is to create new header with semantics:

- requester is asking if the specified feature tags are suppported
- responder indicates which ones are supported

Comments were solicited on which solution is desired, and in which methods is the header allowed to be used?

The new IANA considerations section sets up registries for methods, headers, parameters and feature tags; and provides rules for usage. Comments were solicited on the appropriateness of these rules. Henning Schulzrinne suggested to get rid of X- headers, since they are a barrier to standardization: proprietary extensions okay, but a name ghetto is not. Need graceful path to standardization. Jonathan Rosenberg asked couldn't the process be same as for SIP?

The changes relating to persistent connections, new feature tags, and OPTIONS method implementation requirements were also noted, with little discussion. Issues relating to REDIRECT were noted (see the slides) and Jonathan Rosenberg again asked if the SIP solution couldn't be reused? The concern is about unnecessary divergence between RTSP and SIP, and how to avoid it. There may be issues due to existing implementations that limit the scope for convergence, though.

In the immediate future, we can expect a significant update in the -02 draft, to get with of all know contradications and fixed the resolved bugs. Also continue work on interop test preparation. As a point of clarification, it was noted that new methods must be in separate RFCs, since this is aiming for publication as a draft standard RFC.