Multiparty Multimedia Session Control WG (MMUSIC) ================================================= Wednesday, March 20 at 0900-1130 -------------------------------- CHAIRS: Joerg Ott Colin Perkins NOTES: Tom Taylor, Colin Perkins EDITED: Joerg Ott SLIDES: http://www.dmn.tzi.org/ietf/mmusic/ The MMUSIC WG met once at the 53rd IETF. The meeting was attended by some 150 participants. After routine announcements the chairs presented the proposed agenda which was accepted. Then they announced a joint lunch discussion for interested parties from MMUSIC and SIPPING on the general topic of conferencing on the same day right after the MMUSIC session. Furthermore, a lunch discussion is to take place on Thursday on RTSP. Agenda Bashing and Status Update -------------------------------- Presenters: chairs Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs presented a brief status update. Work on the following drafts has been finished and they have been or about about to be sent to the IESG: - draft-ietf-mmusic-fid-06.txt - draft-andreasen-mmusic-sdp-simcap-05.txt - draft-ietf-mmusic-sdp4nat-02.txt - draft-ietf-mmusic-sdp-offer-answer-02.txt - draft-ietf-mmusic-sdp-ipv6-03.txt The revised charter of the MMUSIC WG has been approved, with milestones through July and a review for continuation in the summer. Work regarding most of the currently defined milestones is still on schedule. The submission of therevised SDP spec and the SDPng motivations are late. SDP key management is in yellow status, not likely going to be on time. Revised RTSP Specification -------------------------- Presenters: Rob Lanphier , Magnus Westerlund Drafts: draft-ietf-mmusic-rfc2326bis-00.txt Slides: 53-mmusic-rtsp.{ppt,pdf,ps} The authors are working to go to Draft Standard. Originally submission of the revised spec was planned to be done May 2002. However, there is only a 30% chance of finishing specification by then. There is a delay on interop documentation. Authors are working on moving more complex/less implemented features out of core specification and into extensions. The design team has been holding open biweekly teleconferences since January 2002. So far ~68 bugs and 8 feature requests have been filed. Of the bugs, 20 have been closed, 5 have been classified as "large tasks", and most of the others have yet to be addressed. The feature requests have not been discussed in detail. Resolution of the following big issues has reached teleconference consensus, which the team would like the MMUSIC WG to confirm: * Clarification of aggregate/non-aggregate control - state machine has been reworked - removed automatic transition at end of clip - general sense that all transitions should be on the client side * Should we eliminate queued play? - tentative answer of the design team: yes * RECORD needs specification work from implementors - may drop for lack of participation * MUTE/UNMUTE proposal - replacing use of PAUSE for this purpose * Transport mode requirements - make support of persistent TCP mode required - non-persistent TCP mode required? (No, make optional and use SIP Supported: tag) * Registration of feature tags for optional features (need to audit the specification) Magnus Westerlund gave an overview of the simplified state machine. The model features separate non-aggregate and aggregate Ready and Play states. Transition between Initial, Non-Aggregate, and Aggregate modes can occur only when no media are playing out (i.e. in the Ready states). Question: Can resources be stranded if the server has no no automatic change of state after play? Rob responded: not too many resources are tied up at that point. The server can release resources specifically associated with the playout without changing state. So long as the client is there, the remaining resources will eventually be released. Queued play (multiple PLAY requests, with the server responsible for serializing them): makes the state machine much more complex. The proposal is to allow multiple ranges in PLAY as a substitute, to be specified as an extension to the core document. Henning Schulzrinne maintained that the Queued play mechanism does not really affect the state machine. Magnus replied that this was technically correct, but it raises other issues. Henning argued that removal from the core specification could remove functionality needed by every server. He was concerned that mapping of multiple ranges (the proposed substitute) might be difficult. This subject will be discussed further as part of Thursday's lunch meeting -- and subsequently on the list. RECORD: this is obviously a desirable feature, but implementors need to to contribute since the current mechanism is underspecified. One of the open questions is whether ANNOUNCE is required. If so, how does one pair the session ID with the announcement? Two people in the room identified themselves as candidates for this part of the work. The work is continuing by teleconferencing. Stephen Casner suggested that the current status might call for a Proposed Standard revision, allowing the group to finish interoperability testing in the ensuing 6 months. Henning Schulzrinne was concerned that this double effort might squander the energy of the participants and the IESG. Stephen clarified that the transition to Draft Standard would be procedural, requiring no revision to the specification itself. There is an urgent need to formulate a feature matrix. Volunteers were sought, but none were forthcoming at the meeting. MUTE/UNMUTE extension --------------------- Presenter: Aravind Narasimhan . Drafts: draft-sergent-rtsp-mute-00.txt Slides: 53-mmusic-rtsp-mute-unmute.{ppt,pdf,ps} The authors identify that RFC 2326 is ambiguous and incomplete regarding the implementation of features such as muting and unmuting individual media streams as well as a session as a whole. Particularly, aggregate/non-aggregate control interaction needs clarification. Currently, the PLAY and PAUSE methods are overloaded to achieve the desired functionality. The mute/unmute functionality seems an important (but optional) features. This feature specification has the support of the team at large, not just that of the authors. It fixes ambiguities and lack of completeness in RFC 2326. It is proposed to remove "mute" functionality from the core RTSP spec and turn it into an extension. As a result, won't be able to do pause of a single stream in an aggregately controlled presentation. The basic semantics of a new MUTE method are to temporarily suspend one stream while the presentation clock keeps running (so other streams can advance). The proposed UNMUTE method resumes delivery of a stream from current presentation NPT. In both methods, a Range: header (which must be open) is allowed to schedule MUTE commands. The authors also list a number of open issues to be addressed: * interation with queued PLAY, RECORD * UNMUTE response needs a Range header * what is the response to UNMUTE on an already UNMUTED stream? - 200 OK? 455 Method not valid in this state? Other? * effect on RTSP state machine if any? * IANA registration: "mute" options tag * definitions of terms, security considerations, acknowledgements. Humming indicates moderate support to take this up as a WG item with no one opposing. RTP Archiving, Delivery, and Playback extensions for SDP (RADPlay) ------------------------------------------------------------------ Presenter: Rob Lanphier Drafts: draft-lanphier-radplay-00.txt Slides: 53-mmusic-rtsp-radplay.{ppt,pdf,ps} The motivation for this proposal is to get around firewall blocking certain protocol traffic (such as media streaming). It enables HTTP-based delivery of RTP. The approach taken also solves numerous other problems including archiving, cache population, archive playback. The proposed mechanism defines a set of simple extensions to SDP: In addition to just providing the session description for one or more media streams as RTP session description(s), further attributes are defined that indicate the source file format of the media streams so that these can be retrieved (via download by means of e.g. HTTP) if setting up an RTSP/RTP-based media session does not succeed. Three extension attributes are proposed: a=srcfile -- URL for source media in on-demand playback a=dumpfile -- URL for "dump" of an individual stream a=dumpindex -- simple index to dumpfile In addition, the a=control can be used outside of RTSP session context to indicate SDP meta files. Rob showed an example featuring fallback from one possibility to the next. Melinda Shore commented that archiving is good, but violating firewall policy is not. We should resist proposals with that intent in the IETF. Henning Schulzrinne countered that the proposal was actually adapting to local policy, not bypassing it -- if streaming is not allowed, the proposal falls back to file transfer. It is easy to block the MIME type at firewall. This is a more explicit alternative to stealth approaches. Syntax comment: generalize to "alternate file" attribute. Rob responded that it was nice to have the tighter semantics presented, but the proposal was something to be discussed on list. The chairs' poll indicated reasonable support for doing this work as MMUSIC work item, with some opposition. Revised SDP spec ---------------- Presenter: Colin Perkins Drafts: draft-ietf-mmusic-sdp-new-06.txt Slides: 53-mmusic-sdp.{pdf,ps} The work on SDP has featured bug fixes. There have been two revisions since last meeting. Colin reviewed the changes in -05 and -06. To do: allow a=rtpmap to be a session-level attribute, as agreed on the list. Colin asked whether there should be a TTL parameter for IPv6 multicast. Gonzalo Camarillo noted that this parameter was removed from the IPv6 draft at IESG direction. Conclusion: it will be removed from text. Colin called for volunteers for interoperability testing. A few volunteers raised their hands. Keith Drage asked about the schedule for approval of the new document. 3GPP needs an RFC number for reference by June. Colin indicated that the schedule was constrained by interoperability testing. A viable alternative to meet 3G deadlines is not to go to Draft Standard right away but cycle at proposed. If going to draft is possible then this is the preferred approach. Key management with SDP ----------------------- Presenter: Fredrik Lindholm Drafts: draft-ietf-mmusic-kmgmt-ext-03.txt Slides: 53-mmusic-sdp-kmgmt-ext.{ppt,pdf,ps} The latest revision of the document has more added more rationale to text and has adopted the offer-answer model as basis for the key exchange. Furthermore, the ABNF has been updated to conform with latest SDP, RTSP. Scenarios and examples have been added. The following SDP extensions are proposed: keymgmt-prtcl = "keymgmt-prot:" prtcl-name prtcl-name = non-ws-string keymgmt-data = "keymgmt-data:" byte-string key-extra-auth = "keymgmt-auth:" byte-string For RTSP, additional extensions are required since SDP is not always passed between the peers when key management needs it: KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data stream-url = "url" "=" url ";" protocol = "Prot" "=" token ";" data = "Data" "=" quoted-string Colin noted the philosophical issue of whether parameters should be opaque or whether instead the semantics should be more explicit. Henning Schulzrinne commented that explicit semantics make interoperability debugging easier. Martin Euchner queried the scope of intended application of the extensions, and was satisfied with Fredrik's response. He raised an issue with NAT passage. Fredrik agreed the receiver cannot authenticate a NATted port. One person spoke against explicit semantics, except for the authentication part. Another person foresaw issues with encryption validity if the blob is broken up: The length of the attributes might cause problems for the containing signalling. Also, offer-answer may be able to carry other key management protocols, but a change in the messaging model might be needed. There is also need to think of support for future key exchange protocols with differing numbers of message exchanges. Peter Barany expressed his preference for explicit semantics, reflecting discussion from the compression group. It is possible the static dictionary would be enhanced. Some people noted problems connected with this. Carsten Bormann noted that the SIP dictionary would be generated soon. The stability of naming of attributes is of interest -- changes affect efficiency. Christian Huitema asked if we should SDP-level encryption or S/MIME. What changes would there be if SDP were carried in S/MIME? The response was that this would be good if one can assume S/MIME is always used. Tom Taylor noted the potential impact of that assumption on Megaco, which carries SDP embedded within the protocol rather than as a separate body. Joerg Ott indicated that the WG should do an analysis of the implications of S/MIME. Further discussion on the list is needed to close on these issues. SDP for connection-oriented media --------------------------------- Presenters: David Yon provided a status update. The following Drafts: draft-ietf-mmusic-sdp-comedia-01.txt Slides: 53-mmusic-sdp-comedia.{ppt,pdf,ps} 53-mmusic-agenda.{ppt,pdf,ps} Work is proceeding on the next revision of the draft (-02). Changes to go into this draft include a new section on symmetric RTP/AVP and minor syntax changes to match SDP-new. There are still issues with the attribute direction:reuse and direction:both still have issues. Joerg Ott took over to present some proposals to resolve the issues that the current comedia model is somewhat inconsistent with the use of SDP for RTP streams. The issues as he summarized them derived from the following points of inconsistency between the comedia model and SDP use for RTP streams: TCP requires explicit setup/teardown as an extra step at the transport layer (while for UDP only local state is created but not shared at the transport layer). TCP connections are bi-directional but are created asymmetrically while this process is symmetric for RTP/UDP. There are other differences from UDP, but with this draft we are looking at transport capability as opposed to transport use. It is important that the basic SDP handling not be changed for comedia: session descriptions must be self-contained and, as for RTP/UDP, resending same SDP should cause no change in state. The WG came up with a list of requirements in December, but the topic died. Joerg presented that list, with one possible addition. He asked whether it is required to allow multiple TCP connections as part of a single media stream. Joerg noted that the requirements may differ for non-SIP use. The WG may want to limit the scope of the draft. Gonzalo Camarillo didn't think multiple TCP connections would work. However, there are other means for grouping. Joerg summed up: the WG needs to continue work toward a general solution, meeting the requirements one by one. He suggested a conceptual approach based on "primitives". SDP for voice-band data ----------------------- Presenters: Rajesh Kumar Drafts: draft-foster-mmusic-vbdformat-01.txt Slides: 53-mmusic-sdp-vbdformat.{ppt,pdf,ps} The draft proposes a new MIME type to distinguish voice-band encoded data (VBD) (e.g. low-speed modems). One parameter is specified to indicate the underlying coding (PCMU, G.726-32, etc.), another to indicate the data rate. The MIME type approach was taken in response to comments on an earlier approach. The underlying coding parameter is required because there is a requirement to associate VBD with the underlying encoding. Stephen Casner observed that the indirect approach to the definition of encoding seemed to be the wrong approach, because it hides the codec at a level below where implementors would expect). However, we can't provide the required fmtp parameters to existing formats. Colin Perkins saw two choices: use attributes, or add parameters to specific encodings. Stephen suggested that one could have a=vbd: 98 where the 98 is then mapped to VBD/8000. As an alternative: define PCMU-VBD etc. Henning Schulzrinne judged this latter the cleanest solution, but not generalizable to the next attribute. Stephen suggested the possible addition of an attribute like fmtp, but not encoding specific. Suggestion: go off-line, do design work on such a media parameter. As a new attribute, this might or might not go into sdp-new. SDPng transition ---------------- Presenters: Joerg Ott Colin Perkins Drafts: draft-ietf-mmusic-sdpng-trans-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs created the document to prepare for a smooth transition from SDP to SDPng. They postulated the need for SDP and SDPng to co-exist for a number of years. They propose a protocol-specific approach, wherein one end could offer both protocols to the other end until SDPng support or non-support became clear. Different ways could be used to achieve this: both protocols in the same message, alternative message formats sent to different addresses, initial offer of SDPng with fallback to SDP, etc. They reviewed the approaches that might be taken for different protocols. Tom Taylor promised to contribute to the draft on behalf of MEGACO. Henning Schulzrinne remarked that SIP hasn't tackled basic issues of application of SDPng yet, so it is too early to worry about multipart/alternative. He also suggested the WG make sure that the transition strategy is not too closely tied to the current specific format. SDPng Update ------------ Presenters: Dirk Kutscher Drafts: draft-ietf-mmusic-sdpng-04.txt Slides: 53-mmusic-sdpng.{ppt,pdf,ps} The changes in the latest revision of the draft (-04) include the introduction of a generic syntax mechanism for reusing definitions: sdpng:use, sdpng:group, sdpng:prop. Also, capability negotiation is described now more extensively. The offer/answer model has been incorporated: typically, the answerer matches the offer against list of supported configurations. In formalizing the messages, there may be a problem with some applications (e.g. video) that need a lot of parameters. In such a case, representing each variant as an individual alternative is not practical (far too verbose). Here, a more expressive mechanism is needed (e.g. ranges) as well as algorithms to collapse descriptions. Dirk listed several desiderata for the resolution of these requirements: it must be simple, must no yield too large messages, must be usable with SIP, RTSP, MEGACO, and SAP, support single round-trip negotiation as in offer/answer, and should support multiparty negotiation as well. And the mechanism must be extensible. Dirk presented the conceptual overview of the proposed algorithm contained in the current draft that meets there requirements. Dirk also pointed out a number of open issues to be addressed: * In SDP, descriptions reflect originator viewpoint which often leads to ambiguities, particularly in multiparty scenarios. Should the descriptions reflect a global viewpoint? * SDPng currently has the concept of "external libraries" that may contain collections of definition to be (dynamically) imported. Is this useful? * Numerous requirements have been discussed for capability negotiation. Which (minimal) functionality is really needed? This requires further discussion! * Further on capability negotiation: what are actual semantics of descriptions and negotiation results? - e.g. range of parameters in final descriptions - are senders free to select values? - is signalling required? * SDPng provides mechanisms to label definitions and refer to them by those labels/names; the involved endpoints are likely to use different labels. For capability negotiation, all those references must be resolved; then the collapsing process yields a set of new description instances. How can those (likely rather verbose descriptions), be reduced to a new compact description instance? * Profiles need development, now they are just represented by examples. In particular, a full representation of AVP/RTP needs to be specified, security e.g. MIKEY, possibly QoS, etc. The next steps are to restructure the current spec iinto several documents: a framework document (Informational), the SDPng specification (Standards Track), and Profiles (Standards Track). A complete list of open issues needs to be discussed and resolve on list. Work on profiles needs to progress further. There is a C++ implementation of SDPng-03 using the expat parser. It is being updated to take in newer material. Henning Schulzrinne asked if they had examined schema definition languages and WSDL type definitions. Dirk responded that they had weighed this approached and found that it had complexity issues. He agreed with Henning on the basic concern. Henning identified a second issue: whether SDPng can express capabilities vs. preferences. SDPng and QoS ------------- Presenters: Chairs Drafts: draft-bos-mmusic-sdpng-qos-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs noted a number of activities relating to QOS signalling including manyfolks work on QoS relating to SIP, media authentication (also from the SIP context), reservation parameters derived from codec, dynamic mapping to RSVP, and diffserv traffic classes. A brief overview of the above draft was given: they identify types of end-to-end QOS information: traffic information, i.e. characterization of the packet traffic for a specific media flow, and sensitivity information that specifies the QOS level given the traffic information (and can be expressed in various ways). The chairs moved on to present a general overview of various QoS architectures showing different ways of how and where QoS may be requested, enforced, and/or provided in the network, including RSVP, diffserv, centralized resource control, among others. They pointed out a number of questions to ask before/when taking up QoS work in the context of the MMUSIC WG (for SDPng): - What have we missed so far? - Do we need QoS information beyond what can be derived from the current SDP? - Where would this information come from? - Is there a need to signal this inband? - Is this signaling session or application layer? - Do we need to synchronize endpoints on (changes in) QoS (profiles)? - How much complexity is acceptable? In summary, we need to determine what the real problem is and whether or not there is a real need to do QoS signaling in the control path The chairs pointed out that QoS, if signalng in the control path, is potentially just yet another dimension of potential and actual configuration. Similar approaches may need to be taken for other areas as well, e.g. security. If QoS is taken up (as part of SDPng), it should just be a specific instantiation of a generalized mechanism. MMUSIC and Electronic Program Guides ------------------------------------ Presenters: Chairs Yuji Nomura Drafts: draft-nomura-mmusic-pguide-requirements-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} 53-mmusic-epg.{ppt,pdf,ps} The chairs introduced the topic of Electronic Program Guides (EPGs): Various groups are looking at broadcasting over IP (DVB-IPI, set-top boxes running IP). Electronic program guides are a necessary part of this. Do we want to work on them? Possible work items are: - SDPng for Electronic Program Guides - SAP and other mechanisms for distributing them - minimal RTSP for retrieval Yuji Nomura presented a first requirements document. He gave a brief definition of program guide and outlined the basic protocol requirements: on demand retrieval, update notification, comprehensive description. He feels that SDPng does not match these requirements well today. He also points out that MPEG-7 offers a comprehensive set of description tools, and could be the basis (or input) for the work. Rob Lanphier asked if any file retrieval protocol would work. Henning Schulzrinne responded: the point is that candidates are available, but they are missing the update notification component. Joerg Ott saw some potential areas of activity fitting into the traditional scope of the Working Group. The was some support for taking up this work in the MMUSIC WG, nobody opposed. The Chairs will examine further for potential uptake.