Last Modified: 2003-10-20
Multimedia communications protocols use a common platform for expressing media and 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. In spite of these, it is widely deployed.
- To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification.
- Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls, exchange of media session security keys.
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 (e.g. 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 Proposed Standard RFC. A requirements document will be devised that gathers the requirements from the areas in which SDP is currently deployed.
MMUSIC will continue to maintain and revise the specification of the Real Time Streaming Protocol (RTSP) based on implementation experience. The RTSP specification will be revised to include various fixes and clarifications. Depending on the changes, the revised RTSP specification will be re-issued as either a Proposed or Draft Standard RFC. A MIB will be considered.
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.
MMUSIC will investigate work on delivery mechanisms for IMGs, generalizing its work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly
The MMUSIC 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 may 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?)|
|Done||Submit SDP source filter extensions for Proposed Standard|
|May 03||Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.|
|Done||Submit revised SDP spec for Proposed (or Draft) Standard|
|Aug 03||Submit SDPng base spec profile for Proposed Standard|
|Oct 03||Submit IMG requirements and framework for Informational|
|Oct 03||Submit SDP Offer/Answer examples for Informational|
|Nov 03||Submit SDPng video profile spec for Proposed Standard|
|Nov 03||Review work on IMGs and update charter accordingly|
|Nov 03||Submit SDP security extension for Proposed Standard|
|Nov 03||Submit SDPng RTP profile spec for Proposed Standard|
|Nov 03||Submit SDPng audio profile spec for Proposed Standard|
|Apr 04||Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)|
|Jun 04||Submit RTSP MIB for Proposed Standard|
|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|
|RFC3524||PS||Mapping of Media Streams to Resource Reservation Flows|
|RFC3605||Standard||RTCP attribute in SDP|
2004.58th IETF: MMUSIC Minutes ------------------------- Reported by Tom Taylor <mailto:firstname.lastname@example.org> and Colin Perkins. MMUSIC met on Friday morning, November 14. The meeting was chaired by Jörg Ott <mailto:email@example.com> and Colin Perkins <mailto:firstname.lastname@example.org>. The agenda was accepted with two minor changes: a discussion of Source and Sink SDP attributes was added, and the discussion of SDP parameters for H.263 and H.261 options took place in AVT instead. Introduction and Status Update ------------------------------ Jörg Ott gave an introduction and status update. The working group has had one RFC published since the last meeting: the RTCP attribute for SDP (RFC 3605 <http://www.ietf.org/rfc/rfc3605.txt>), and draft-ietf-mmusic-sdpng-trans-04.txt is with the RFC Editor. The IESG has reviewed draft-rajeshkumar-mmusic-gpmd-03.txt and suggested some changes. The authors are considering these, and will produce an update. Colin Perkins has updated the revision to SDP (draft-ietf-mmusic-SDP-new-15.txt) to reflect IESG comments, implementing the changes suggested at the 57th IETF meeting. The working group was urged to review the draft to make sure the latest changes haven't broken anything. Some discussion took place: * There was a question on the time scale for SDP-new approval. The chairs expect an immediate WG review, then off to the IESG. Volunteers were requested for an in-depth review. They were asked to send an E-mail to Joerg to indicate that they were volunteering. * Jon Peterson <mailto:email@example.com> indicated that he was still worried about the "k=" line text. The problem is that the existing text has a normative dependency on informative text: "SHOULD NOT use in absence of <informative refs>". * There is a problem with the text media type: it's widely used, and referenced in RFC 2327 <http://www.ietf.org/rfc/rfc2327.txt>, but got missed from the original IANA registry for SDP top-level types. We could do it indirectly by putting it into SDP-new. Interested parties are asked to send text to be added to sdp-new for the purpose. Future SDP extensions are strongly discouraged by the WG charter. * Semantics are undefined for multiple "m=" lines with the same port and "c=" The interpretation should go into the SDP-new draft as a clarification. There are minor implications on the offer-answer examples. Gonzalo Camarillo <mailto:Gonzalo.Camarillo@ericsson.com> sent some text, but for a different case (hierarchical encoding). Flemming Andreasen <mailto:firstname.lastname@example.org> proposed that we simply prohibit this construct. The meeting agreed to the prohibition. The source filter (draft-ietf-mmusic-sdp-srcfilter-05.txt) and comedia (draft-ietf-mmusic-sdp-comedia-05.txt) drafts have been reviewed by the area director, and need to be updated. The new SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-05.txt) are with the area director, and an IETF last call is expected shortly. Internet Media Guides --------------------- Requirements: Yuji Nomura <mailto:email@example.com> discussed requirements for Internet Media Guides (draft-ietf-mmusic-img-req-00.txt). There are lots of changes in the latest revision of the requirements draft. A new background and motivations section has been added. The editor moved in the problem statement from the old framework draft, but shortened it. Congestion control has been added as a requirement. Security considerations were added. For the next revision: * requirements will be numbered * terminology will be modified for consistency * clarifications have been requested: many more receivers than senders; senders continually connected, not receivers; and the tradeoff between customization and scalability The revised draft is coming out in the next few weeks. The authors expect it to be ready for Last Call shortly after that. Framework: Pekka Luoma <mailto:firstname.lastname@example.org> discussed the IMG framework (draft-nomura-mmusic-img-framework-02.txt). This is an individual submission, since it missed the cutoff; a working group draft will be submitted shortly after the meeting. Changes from the last version are as follows: * The use cases in the latest version of the draft were extended to include content-oriented use cases. * A section has been added to discuss the applicability of existing protocols. * New section 6.3 summarizes the outstanding needs that existing protocols do not seem to supply: o need for a multicast transport protocol o need to specify how to use specific unicast transport protocols in this application o specification of the "metadata envelope", a new term for an existing concept in the framework that gives independence from transport protocol and metadata format o agreement on the basic metadata models (informative only) Next steps are an editorial cleanup and a new section outlining what pieces of the work are in IETF scope (the transport protocols and transfer envelope) and out of scope (the data models and application specific metadata). It was suggested that an IMG metadata identifier is needed, likely a URI to differentiate between complete specification, delta, and filter. Jörg suggested avoiding the term "metadata" altogether, since it causes confusion. Magnus Westerlund <mailto:email@example.com> remarked that this was not exactly a framework document. Colin suggested an offline discussion on this point. Magnus will comment by E-mail. Rod Walsh <mailto:firstname.lastname@example.org> indicated that whether changes use the same syntax as the original announcements is still an open question. It is not clear how reusable the syntax may be. Target is to have WG Last Call in December. Other issues Rod Walsh outlined some open technical issues and design choices relating to the IMG work: * There are a number of design choices for transport protocols; for multicast, ALC/FLUTE is a very good candidate. * The Subscribe (unicast) model can be handled by SIP and SIP events. * The Metadata Envelope could be: a. XML file/wrapper, or b. header extension of transport protocols. Both? * Data types and channelization: could correlate data type and transport channel? Or could divide delivery over multiple channels? There is a middlebox authentication and integrity issue, since a middlebox could invalidate the sender signature in some cases (by performing header modification). Various possible solutions exist: trusted middlebox; middlebox could inform the sender of its change and request re-signing; middlebox could sign the data. Jonathan Rosenberg <mailto:email@example.com> asked whether in this discussion "middlebox" connoted a NAT or firewall, or whether it simply meant some router in the abstract? Rod confirmed that the latter meaning was intended. Jonathan advised him not to call it a middlebox, to avoid confusion. Alternative IP versions for SDP ------------------------------- Gonzalo Camarillo <mailto:Gonzalo.Camarillo@ericsson.com> outlined the Alternative IP Versions Semantics for the SDP Grouping Framework (draft-camarillo-mmusic-alt-02.txt). The proposed IPV extension is backward compatible. Dual-stack hosts are strongly encouraged to implement IPV. The question is whether to make it a WG item? Flemming Andreassen suggested that text was needed to clarify the relationship to ICE. He noted that the key point of the extension is to avoid establishing multiple media streams. That said, could the extension be applied to abstract properties, beyond IPv4 vs IPv6? Gonzalo confirmed that it could. Jonathan Rosenberg affirmed that the draft does need text to make the relationship to ICE clear. It was suggested that IPV may not be the appropriate name. The consensus of the group was to make this a WG draft. Source and Sink SDP attributes ------------------------------ Gonzalo Camarillo <mailto:Gonzalo.Camarillo@ericsson.com> discussed SDP source and sink attributes (draft-camarillo-sipping-transc-3pcc-00.txt). This draft came from the transcoding design team in SIPPING. It deals with a problem in the routing of media types, which is really a service location problem. Jörg suggested that this was really a small subset of the XCON WG topic area. The draft raises a potential problem: signalling by SDP could conflict with other media policy mechanisms. Gonzalo agreed that the team would clarify whether should use the more general mechanism or whether this one is justified. Security Descriptions --------------------- Flemming Andreassen reviewed the changes in the latest revision of the security descriptions draft (draft-ietf-mmusic-sdescriptions-02.txt). The draft has been generalised into a core framework and an SRTP specific part, and numerous editorial changes and clarifications have been included. In detail, the changes are: * offer/answer highlights differences between unicast/multicast and the initial/subsequent offer * rekeying is addressed via offer/answer; everything can be changed * additional rules and considerations for communicating the SRTP SRC parameter * removed the SRTP "use" parameter, which is now inferred from context * added Window-Size Hint and <From,To> to SRTP profile * more rules for extensions... * updated IANA considerations and grammer There are still four open issues. Issue 1 was with multicast: * Shared vs. per-participant key? * When a key is shared, the streams need unique SSRCs per destination. * If per-participant keys are used, each participant has to convey his/her key separately. * How to support for hierarchical layered encoding schemes is another multicast issue. Flemming was not sure there is a single good solution. The proposal was made that multicast streams should be left for further study, and not included in this draft. Jon Peterson wondered if we had found the logical dividing line between unicast and multicast. Jonathan Rosenberg wanted to be sure the solution is mature before deciding this. Jörg indicated that he would like to progress the draft, since it addresses fairly urgent issues. There was agreement that it was reasonable to leave multicast for further study. Issue 2 was several problems with respect to the SRC parameter. Most of them are multicast based, hence can be left aside for now. There are still the questions of: * how many crypto contexts can sdescriptions establish? * handling SSRC collisions. There was a suggestion to remove the SSRC part and support single context only. However, Magnus Westerlund pointed out that you can get multiple SSRC from the same host. The decision was therefore to keep the SSRC part in the document for the moment. Issue 3 (on Flemming's slides) was purely multicast, and so was skipped. Issue 4 was the "Use" parameter which was removed, since it led to complexity and could be inferred from context. Is there any need for it? No feedback from the room - please read and comment. Flemming expects to provide an update by December. There are no other known issues. Should it go to WG Last Call? Need volunteers to give it a thorough review. Magnus volunteered on the spot. Jon Peterson is to organize as Security Area review. Security Preconditions ---------------------- Flemming Andreassen outlined draft-andreasen-mmusic-securityprecondition-00.txt on security preconditions. The problem: an ambiguity in security description selection. There is a need to block sending until the ambiguity is resolved. Should this be a WG work item? Gonzalo Camarillo suggested the WG look at RFC 3329 (Security Mechanism Agreement for the Session Initiation Protocol (SIP)) as a model to ensure not they are not introducing a security risk. Jon Peterson suggested the WG look at the possible use of security associations between hosts. He argued against the presence of security preconditions in RFC 3312 <http://www.ietf.org/rfc/rfc3312.txt> because of bootstrapping concerns. He was trying to recall detailed arguments: we had better look at the archives. Resolution: think about it a bit more. Interactive Connectivity Establishment -------------------------------------- Jonathan Rosenberg discussed ICE (draft-ietf-mmusic-ice-00.txt), which was accepted as an MMUSIC work item in Vienna. Since then, the draft has been rewritten to make it protocol independent: * generic session establishment protocol; * defined semantics in terms of that protocol; * ICE compliance defined in terms of mapping to generic protocol; * showed mapping for SIP (RTSP and H.323 are other possibilities, for future work) Another change is that it is necessary to know, through configuration, which is a public TURN relay (there may be non-public ones; public one is default). ICE now uses the TURN SEND mechanism to tell the relay to send a packet to a particular address-port; this can only be used before lockdown and is needed in inter-enterprise cases. Jonathan walked through a call flow. Magnus was concerned about a packet loss case after lockdown, before return to client. Jonathan will add a case to cover this. A question was asked: can a binding be removed? TURN can, but not ICE. Lockdown cannot be removed: keep things simple. In the rewrite, Jonathan removed the massive call flows section from the draft: SIP usage is not the point. Open issues include getting TCP to work (needs a connect method, and there is the issue: demultiplexing of STUN and data on the connection - perhaps try to avoid it by restricting functionality) and prioritization of addresses, basically pushing routing to endpoints. Is there a better way? Flemming Andreasen, without being specific, suggested that there may be something in the middle that can handle routing better. Issues to be addressed: * RTSP mapping? Jonathan lacks expertise and time... * Sequential send attempts: Magnus suggested to do the semantics only once, but Jonathan warned that we must not make assumptions about topology. * Use of multiple STUN servers? There was discussion on extra round trips. Jonathan indicated he would be pleased to see a better solution. There are tradeoffs: effficiency vs. reliability and safety. We can continue to think about optimizations (such as assuming the RTSP server is on the public network), but with great care. * Is it OK to have username/password in clear? * SDP ALT parameter conflict with 3GPP: Jonathan will fix. Jon Peterson noted that he wouldn't mind more warning from 3GPP. TheIESG is working on a liaison process to achieve this. RTSP ---- Magnus Westerlund presented a number of changes incorporated in the latest draft version of RTSP (draft-ietf-mmusic-rfc2326bis-05.txt). Further changes have been agreed, but are not yet documented: * Implicit Redirect using new 3xx code to get SDP for supporting terminals. A feature tag will associated with this for backward compatibility. * Address class in "c=" needs to be checked. * Caching of methods is unspecified * Aggregate control URI deriving will be unspecified * Clarify the usage of SDP "a=range" for TiVo type of devices * The server MAY close the TCP connection after receiving the 2xx message for a REDIRECT request * To write something about request to response time limitations. Keep the specification simple, details to be worked out. * ABNF to be collected in a single chapter * Issues with changing transport parameters using SETUP * Should the Location header work as base URI for requests with REDIRECT without SESSION header * Request/response time is not limited; needs clarification There are few open issues, but lots of editorial stuff to clean up. The team will try to edit out all known bugs by the end of year. A clean-up review can be held from January to March, with WG Last Call by March. The teleconferences will continue, starting on 3rd December. RTSP NAT -------- Thomas Zeng <mailto:zeng@PacketVideo.COM> discussed RTSP NAT traversal (draft-ietf-mmusic-rtsp-nat-01.txt). There is still lots of work to do on the -01 draft based on Vienna comments, but work on the core RTSP spec took priority. Current focus is to clarify the requirements: * MUST work for all flavors of NAT, including symmetric * MUST work for firewalls, including those with ALGs * SHOULD have minimal impact on clients in the open and not dual hosted * SHOULD be simple to use/implement * SHOULD be secure Jonathan cautioned on the wording of requirements with respect to firewalls: make sure the aim is to support administrative control. There is an issue with dual-hosted clients. Thomas proposed to add a mechanism to support them: many RTSP servers won't allow such clients, to prevent DDOS attacks. Jon Peterson suggested that the most important task at hand is to explain the problem in great detail. Moving forward the next revision will clarify "statement of intention" and provide list of requirements. Will also remove any solutions requiring protocol extensions to a separate draft. Jonathan noted that some mechanisms can be provided on the basis of "required to implement, not required to use" RTSP END-OF-STREAM proposal --------------------------- Thomas Zeng discussed the END-OF-STREAM proposal for RTSP (draft-zeng -mmusic-rtsp-end-of-stream-01.txt). Background: RTCP BYE is awkward; would like to be able to reuse SSRC. Lately the RTSP team has been finding a requirement to push various items to the client: END-OF-STREAM, session descriptions and updates, error events. Some earlier drafts have been written in the area. Strawman proposal: extend RTSP, adding a Server-to-Client method with feature tag. There was a recent suggestion to use ANNOUNCE for the End-of-Stream application. Should this be generalized for other information? Tom Marshall suggested using a SET parameter. Jörg didn't think the semantics felt right. Regarding the strawman proposal: Jörg would like to avoid having to respecify connection management for the Server-to-Client direction. This was more a matter that the client should keep the connection up to receive notifications. Thomas provided an example of possible syntax. Magnus expressed a concern with the "bytes" specification in Range; this is a conflict. The example will be cleaned up. The next step is expand scope of draft to cover ANNOUNCE as an extension of the core specification. Should this be a WG item? Magnus and Colin both suggested further work before making this decision. We can decide on the mailing list after the next revision. We might consider pulling back this capability into the main