Last Modified: 2003-02-03
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||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?)|
|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|
|RFC3388||PS||Grouping of media lines in Session Description Protocol SDP|
Multipary Multimedia Session Control (MMUSIC) Working Group Minutes Reported by Colin Perkins The MMUSIC working group met once at the 56th IETF meeting in San Francisco. The group discussed connection oriented media, various SDP extensions, Offer/Answer examples, SDPng, Internet Media Guides, and RTSP. Introduction and Status Update Joerg Ott began the meeting with an introduction and status update. One RFC has been published since the last meeting (RFC 3388 on Flow Identification), and one draft is with the RFC Editor (draft-ietf-mmusic-reservations-flows-01.txt). The revision to SDP (draft-ietf-mmusic-sdp-new-12.txt) is under AD review, as are drafts in the RTCP attribute in SDP (draft-ietf-mmusic-sdp4nat-03.txt) and the SDPng Transition Strategies (draft-ietf-mmusic-sdpng-trans-03.txt). The SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-01.txt) are in working group last call, and comments are solicited. Joerg noted that the SDP specification has been revised due to Area Director feedback. Colin Perkins described the changes: a number of minor fixes to the ABNF, and significant updates to the description of the "k=" field and the IANA Considerations section. The registration requirements for attributes and other parameters have been significantly tightened with this revision, and comments are solicited regarding the degree to which these changes are appropriate. The SDP source filter draft (draft-ietf-mmusic-srcfilter-03.txt) is essentially complete, just needing editorial work. The chairs noted that they expect to issue working group last call on this in early April, and that anyone with comments should post them shortly. There is a new draft on SDP implementation status and interoperability (draft-ietf-mmusic-sdp-implem-00.txt), which is a first cut at the documentation needed to advance SDP to draft standard. Please read and comment. The working group has completed its charter, and a draft for a revised charter was sent to the mailing list prior to the meeting. This draft is under discussion between the chairs and area director, and comments are solicited from the group. It is expected that the revision will include work on SDP, SDPng, RTSP and Internet Media Guides. Conference Control has been ruled out of scope at this time. Connection-Oriented Media Transport in SDP David Yon discussed comedia (draft-ietf-mmusic-sdp-comedia-05.txt). The changes in -05 include removal of source address/port per discussion on the mailing list, and removal of the current security considerations in preparation for a revision in the next version (again, as discussed on the mailing list). David noted that the main security issue is session hijacking, which can be solved by using secure media streams. In the absence of this, the attack can be downgraded to a denial of service, if the endpoints follow the rules in Section 4(b) and (c) of the draft, using duplicate incoming connections as a signal of the attack (this works for TCP and bidirectional RTP). Jonathan Rosenberg noted that using double connect as an indication of an attack might fail in the presence of forking invites; this needs further consideration. Next steps are to come to closure on the RTSP issues discussed on the mailing list, and to fold in the expanded security considerations into -06. Colin Perkins confirmed that the "eid" would be implemented as a separate draft if needed. David expressed the hope that the -06 version would be ready for working group last call. SDP key management extensions Elisabetta Carrara discussed changes to the key management extensions work (draft-ietf-mmusic-kmgmt-ext-07.txt). The changes are primarily for clarification, and include a more detailed description of the interactions between SDP and the key management module, and rekeying. In addition, the IANA considerations section has been updated. The main issue previously noted was a bidding down attack, which Elisabetta described, but this has been solved in -07 by authenticating the list of proposed key management protocols in the SDP. Mark Baugher noted that another way to avoid the attack is to use only a single key management protocol, to avoid the possibility of bidding. Ran Canetti described how the attack is still valid in that case, since the bid down can be done over multiple INVITEs with different protocols meaning that the addition of authentication is the correct solution (even though it complicates the protocol). It was asked if Kerberos still works with the changes? Elisabetta said it should, but she would check to make sure. Colin Perkins noted that approval is needed from the transport area security advisor before this draft can advance, but that the changes appear to address the previously open issues. SDP Security Descriptions for Media Streams Mark Baugher discussed SDP security descriptions for media streams (draft-ietf-mmusic-sdescriptions-00.txt). The aim of this draft is to replace k= with an attribute, suitable for signalling SRTP parameters. The draft is intended for applications where the signalling channel is secure. If the signalling is hop-by-hop, as is common with telephony, the intermediate hops must be trusted to maintain security. Changes from (draft-baugher-mmusic-sdpmediasec-00.txt) apply parameters to media streams, not codecs (see discussion at the previous meeting); apply parameters to the SDP media level only (as a result of improving offer/answer); add an "application" parameter allowing separate descriptions for SRTP and SRTCP; define use with offer/answer and augment the ABNF. Next steps are to fix known problems, in particular the ambiguities with SDP direction attributes, to generalize offer/answer, and to generalize to transports beyond SRTP, and to get implementation experience. Magnus Westerlund noted that RTSP doesn't currently define a secure signalling channel. This will need to be fixed, if this work is to be used with RTSP. Steve Casner asked if the semantics were well defined if more than one of "k=", "a=keymgmt", and "a=crypto" are present? This is not legal, but appropriate behaviour needs to be specified. It was asked how a system should behave if the key is referenced by a non-secure URI? This is clearly not appropriate use. SDP attribute for qualifying media formats with generic parameters Flemming Andreasen discussed (draft-rajeshkumar-mmusic-gpmd-02.txt). This is intended to provide an alternative to "a=fmtp:", so that new parameters can be added to existing media formats. The example being a voice-band data parameter, to apply to codecs such as PCMU when used for modem or fax relay. Changes since -01 are to firm up the definition of the gpmd attribute, clarifying that it is intended for informative hints, and that lack of a gpmd parameters MUST NOT render the media format useless. Use with offer/answer has also been specified, as have registration procedures. Ruediger Kreuter asked if an echo cancellor parameter has been considered? Flemming replied that there are many ways of specifying this - see V.150 - how should it be specified? Colin Perkins noted that this should be a new extension draft, rather than being including in the gpmd draft, to avoid delaying the work. The chairs asked for comments, noting that they intend to issue a working group last call on this draft shortly. SDP Offer/Answer Examples Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-01.txt which provides examples of the use of the offer/answer model. There have been a number of minor corrections and clarifications since the -00 draft, and the plan is to continue collecting new scenarios and seek review and comment from implementors. If you are implementing SIP and offer/answer, you are urged to review the draft and send feedback. SDPng Update Dirk Kutscher presented an update on the SDPng work (draft-ietf-mmusic-sdpng-06.txt). Changes in -06 include a new document structure, new requirements for capability specifications, new capability negotiation rules, the removal of XML-Schema-based formal definitions and text on session-level information. Capability specifications are now required to support feature independent negotiation and must not require access to a package definition in order to process capability descriptions. This requires definition of a fixed set of basic types, encoding the type into values. In addition, names must be fully qualified. Capability negotiation rules have been updated to describe the general behaviour, leaving concrete behaviour implementation specific. Two alternative procedures are specified: an offer/answer based scheme and an RFC 2533 (conneg) style approach. Open issues include a concrete syntax definition, session level data, and possible use of libraries of definitions. Next steps are to give details on describing actual configurations and transport parameters, and a formal definition mechanisms for packasges. Other work items include specific package definitions (e.g. audio, video) and session level metadata. Internet Media Guides Rod Walsh outlined Internet Media Guides (IMGs), a potential new work item for the group. An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP, SDPng or some similar 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. This problem lends itself to solution by (extensions of) some existing mechanisms: SAP and SDP/SDPng. MMUSIC therefore seems the natural home for the work. Other groups (e.g. DVB-IPI, TV Anytime, and the IP datacast forum) have identified similar needs, but do not have the experience to solve the problem. The chairs presented some initial charter text discussing the problem (subject to modification/approval from the area directors) and asked if the working group considered this an appropriate work item? Strong support was received. RTSP Magnus Westerlund discussed changes to the Real Time Streaming Protocol (draft-ietf-mmusic-rfc2326bis-03.txt). The goal is to update and clarify the RTSP specification, with the aim of moving to draft standard RFC (a new proposed standard RFC may be required first, depending on the scale of the changes). The aim is to have the core specification completed by October 2003. The new version will be a minimal core specification, with extensions documents for NAT traversal, MUTE and UNMUTE and (possibly) a MIB, RECORD, secure RTSP, and RTSP over unreliable transport. Since the previous meeting, there have been 5 teleconferences discussing the spec (details announce on the mailing list or see http://rtsp.org/). A list of known bugs in the specification is also maintained at http://rtspspec.sourceforge.net/. Changes updates discussed recently include: - Non-persistent connection support is now mandatory - IPv6 support added - Accept-Ranges as proposed in the core spec - Byte ranges will be allowed - Via header will not be changed to include client address - Clarification of 304 "Not modified" - Clarification of redirection - Agreed feature extension mechanism - Strengthened requirements for Destination header - Added source and destination addresses to the Transport header - RTP-Info's base URL is a PLAY request URL - Clarified interleaved usage - A SETUP to change transport parameters leaves the previous state intact if it fails - Clarification that RTSP URLs are case sensitive - Range header now required in all PLAY responses - Range is formulated as start point (inclusive) to stop point (non-inclusive) - Use of PAUSE when in Ready clarified Open issues include how RTSP extensions registrations are to be handled, and what are the requirements for new extensions; can timed requests be removed; handling of multiple SSRCs in RTSP; and inclusion of a warning header. Input from those working with RTSP was sought, since there is a shortage of manpower on this effort. RTSP and NAT Magnus Westerlund discussed NAT traversal for RTSP (draft-ietf-mmusic-rtsp-nat-00.txt). The issue is not RTSP signalling itself, but how the media streams traverse the NAT, and how RTSP knows the correct external addresses to use after NAT traversal. Will also address cooperation with firewalls. The draft currently discusses use of STUN, symmetric RTSP, tunnelled media in TCP and application level gateways. Open issues exist with the use of STUN for symmetric NATs and symmetric RTP. Mark Baugher asked if the authors have considered potential issues with secure RTSP? May not be as simple as "just use SSL"? Philippe Gentric noted that the attacker is often the client, so a secure channel may not help security. Magnus asked for input, and is seeking a co-author to help complete the work. Stream Switching Control Philippe Gentric discussed draft-gentric-mmusic-stream-switching-00.txt, a new draft describing how a server can signal that it is switching from one version of a stream to another (for example, for coarse-grained rate adaptation, when the limits of adaptation of a particular codec are exceeded). Alan Duric was glad to see the work, but asked if Philippe considered the problem that routers may not be saturated due to bandwidth, but due to packet rate? Maybe we should add a feature to change packetization interval? Joerg Ott agreed that this is something to consider, it's just another change in the media format. Magnus Westerlund asked if you can do other things than switch streams for congestion control? Philippe said yes, streams can be adapted in various ways, but this doesn't need protocol supoprt from RTSP. Ross Finlayson agreed that the concept was useful, but was unsure that RTSP is the place to put the signalling? Will the TCP nature of RTSP delay the congestion control signalling? Maybe use RTCP? Colin Perkins noted that it is important to differentiate between indication of loss for a stream (RTCP) and signalling to switch to a different stream (RTSP). Anders Klemets also liked the idea, but not the details. We have standard ways of specifying alternates in SDP, maybe want to leave those details out of this spec? Given the interest, it was agreed to move forward with this discussion on the mailing