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.