Last Modifield: 05/23/2002
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.
|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|
|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|
Multiparty Multimedia Session Control Working Group Minutes Reported by Colin Perkins The MMUSIC working group met once at the 55th IETF meeting in Atlanta. We discussed SDP key management and media security descriptions, media format independent SDP parameters, SDP bandwidth modifiers, examples of the offer/answer model, Internet Media Guides, XML schema for video control and the revised RTSP specification. Agenda Bashing and Status update The meeting started with an introduction and status report by Joerg Ott. The SIMCAP draft has been published as RFC 3407, and the FID draft is in the RFC Editor's queue. The comedia, sdp4nat and SDPnew drafts are still with the IESG. The draft on reservation flows is completing its working group last call, and will be submitted to the IESG for publication as a proposed standard immediately after the meeting. There have been minor changes to the SDP spec, to address comments from the list. We are waiting for feedback from our area director before we can progress this further. There has been no recent update to the SDPng draft, but the authors are working on a new version that will have some internal reorganization, will focus on the offer/answer model, and will leave multiparty content-independent negotiation for a future extension document. The SDPng Transition draft (draft-ietf-mmusic-sdpng-trans-02.txt) has been revised, and is largely complete. Feedback is solicited, we plan to issue a working group last call shortly. The SDP Source Filter draft (draft-ietf-mmusic-sdp-srcfilter-02.txt) seems to be complete. Joerg asked if a working group last call would be appropriate? There were no objections, and a last call will be issued shortly. The comedia draft is, in principle, complete but concerns have been raised about applicability in the presence of middle-boxes. Joerg Ott outlined his understanding of the issues. Jonathan Rosenberg disagreed with Joerg's formulation: rather the issue is that there'a a strong coupling between session lifetime and connection lifetime, and problems reusing connections. This causes too much load and bad congestion state. Jonathan suggested updating the comedia spec to address these concerns. Allison Mankin asked if this needs just a relatively small change rather than an elaborate extension? Jonathan expected the changes to be small. Joerg Ott noted that we need to understand the muxing and binding mechanisms. Jonathan agreed, since right now there are problems due to NAT, firewalls, etc. Jonathan said he would produce a concrete proposal on what needs to be changed in comedia "within a month", else we will go ahead with the existing specification. Joerg noted that the working group charter is out of date. The chairs will work on updated milestones and charter, to be circulated to the list for comments. Suggested new work items may include Internet Media Guides and Floor Control, but these need to be discussed with the area directors before any decision is taken. MIKEY/Key Management with SDP Allison Mankin (Transport Area director) and Eric Rescorla (security advisor for the transport area) outlined their concerns with the key management model for SDP and the MIKEY draft. Eric's concern is the binding between MIKEY and SDP, which allows multiple key management protocols, such as IKE, S/MIME, etc. There is no protection against downgrade attacks during the protocol negotiation. Elisabetta Carrara noted that there is a recommendation in the draft to choose between appropriate crypto-suites, but this did not satisfy Eric. Jonathan Rosenberg said that his understanding is that using MIKEY with SDP is not sufficient, the SDP will be protected with S/MIME anyway and hence S/MIME provides the protection against downgrade attacks. Eric asked why, if you have S/MIME already, do you need MIKEY? Elisabetta noted that we don't commit to S/MIME, but Eric countered that, to have reasonable security, S/MIME or similar protection is needed in addition to MIKEY. Discussion continued for a while with no real resolution. Allison Mankin committed provide a written review of the draft, with detailed comments for discussion on the list. SDP Security Descriptions for Media Streams Mark Baugher outlined the new draft on SDP Security Descriptions for Media Streams (draft-baugher-mmusic-sdpmediasec-00.txt). This is an alternative means of exchanging keying material, to be used when the SDP message is securely delivered. Accordingly it is expected to be complementary to key management with MIKEY. Mark outlined the limitations of the existing "k=" line, described the proposed "a=crypto:" attribute, and outlined use with the offer/answer model. Jonathan Rosenberg asked unclear why you'd want to do separate security properties on a codec by codec basis since this seems to be the cause of a lot of complexity? Mark asked if this could become an MMUSIC work item. The chairs agreed that the work is a good thing to do, but need to figure out the correct home for it. SDP attribute for qualifying Media Formats with Generic Parameters Flemming Andreasen presented draft-rajeshkumar-mmusic-gpmd-01.txt, the format independent parameter that can apply to existing MIME types. He outlined the background to the draft, signalling voice-band data, and noted issues with the current draft: it is very open-ended and needs to be more limited in scope; it needs to specify interactions with the offer/answer model; and it needs a procedure for registration of new gpmd parameters. Jonathan Rosenberg recommend that parameter specifications suggest the actual interaction with offer/anser. He also suggested that we require new parameters to be standards track. A Transport Independent Bandwidth Modifier for SDP Magnus Westerlund outlined draft-westerlund-mmusic-sdp-bwparam-01.txt, on a new set of SDP bandwidth modifiers that signal session bandwidth in a transport independent manner. These are intended to solve problems due to NATs and protocol translation, that make the existing parameters less than useful. Steve Casner noted that biggest open issue is whether we really need to make the change at all? Magnus noted that the bandwidth can increase by 25% with IPv6, compared with the value currently signalled, a compelling argument for the new parameters. Steve disagreed, noting that the RTCP bandwidth doesn't have to be that accurate, and that this level of inaccuracy is unlikely to be problematic. He also said that a stronger point is bandwidth allocaton for links, where it seems likely that for tightly controlled channels, header compression will be used, so the difference between v6 and v4 goes away. SDP Offer Answer Examples Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-00.txt, giving a series of examples and scenarios for the use of offer/answer. The group expressed interest. Joerg Ott asked that the draft be expanded to give some pointers to why the examples are correct. A Framework for Internet Program Guides Yuji Nomura discussed draft-nomura-mmusic-pguide-framework-00.txt, a new framework for Internet Program Guides that has evolved out of the drafts that were discussed in Yokohama. There are a number of open issues: can this become a charter item of MMUSIC? Revision of requirements? Choice of protocol for announcements? Appropriate description format? There was much discussion of the naming of the work, with many people disliking the term "Internet Program Guide". It was decided to call the work "Internet Media Guides" from now on. Joerg Ott noted that many description formats could be used, and that we would not want to restrict ourselves to a single format. Similarly, we would not want to define a new format within MMUSIC, but instead use the existing solutions. Henning Schulzrinne asked that we take a step back to see what we learnt from SAP. Other things have happened in the space of event notification, and SAP hasn't been a clear success because of the service model, etc. We want to revisit, and see what we've learnt. The chairs noted that this work is not within the MMUSIC charter. They will work with the area director, to determine if MMUSIC is appropriate for this work, or if it should occur elsewhere. XML Schema for Media Control Orit Levin outlined draft-levin-mmusic-xml-media-control-00.txt, an XML schema for media control. Orit noted that several alternative approaches have been discussed previously (CODEC specific RTP/RTCP primitives, RTCP feedback as for loss recovery, SDP extensions) but rejected for various reasons. They therefore propose the use of an XML scheme conveyed using a reliable protocol. The primitive commands are "picture fast update", "GOB fast update", "MB fast update" and a "picture freeze" command. This is encapsulated in the SIP INFO method, and next steps are to define the encapsulation. Steve Casner noted that he is sure an XML schema can be defined for this purpose. A more critical question might be how it is transported, and if the result will work. Rohan Mahey noted "if I could go back in time and undo INFO, so it didn't exist, I'd be very happy". He noted the issue is that this is media oriented, and should be sent with the media. Asked if some form of RTCP based approach might be more appropriate? Henning Schulzrinne expressed concern about re-inventing SOAP on the sly. Besides asking whether this belongs in SIP or not, we don't need yet another RPC protocol. If it is an RPC mechanism we should ask how we can make exisitng RPC solutions work in this context? He also asked if there is a need for a traditionally reliable mechanism, and how it relates to other work on, for example, floor control? Nermeen Ishmail noted that there is a real problem of using SIP, since if you lose the control path, you lose the media. This leads towards using RTCP, but there is an interoperability problem with that since H.323 systems convey this information in the control path. Accordingly, we should steer away from RTCP, and use a media control protocol. There was concern that this would not work either, due to the latency of the control channel. Jonathan Rosenberg noted that this might be a perfect candidate for a SOAP protocol, signalled in SDP? Henning agreed that SOAP works today, but there is a need for a way of associating SOAP connections with a media stream, in SDP. Orit asked where should we do SOAP work, since it is unclear if MMUSIC is the appropriate forum? The answer seems to depend on the form of the final solution. RTSP Update Magnus Westerlund outlined recent changes to the revised RTSP draft (draft-ietf-mmusic-rfc2236bis-02.txt) and gave a pointer to the bug tracker at http://rtspspec.sourceforge.net/. He asked for the group to review the updated specification, and noted that teleconferences to discuss changes will resume shortly. He also outlined major open issues. This first open issue is redirect: shall the server be allowed to close a session as soon as the clients ACKs the REDIRECT? And what should be done with the 3xx codes? Magnus noted that the authors are lacking experience with RECORD. It seems that the spec needs significant clarifixation on how to use it, and that there are many open issues. Input was requested from someone who has implemented RECORD, otherwise the authors proposed to remove it from the base specification (leaving it as an extension document). Steve Casner said he was pretty sure that IP/TV used RECORD, and that this may provide implementation experience? Rob Lanphier explained that we need people to document what they're doing with RECORD, not just to list implementations. Henning Schulzrinne asked if the issues with RECORD might be somewhat similar to WEBDAV style protocols, and if experience in that field may be helpful? Other open issues exist with Appendix C, the Accept-Ranges header, the Via header, Negative Scale, TLS support, RTSP over UDP, etc. A bar BOF was scheduled for later in the week to discuss these, and discussion will continue via the mailing list and teleconferences.