Last Modified: 2004-01-23
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|
Minutes of the Multiparty Multimedia Session Control (MMUSIC) WG ======================================== ======================== Reported by: Jörg Ott Notes by: Colin Perkins General ------- Colin Perkins, Jörg Ott The MMUSIC WG met once at the 59th IETF. The meeting was chaired by Colin Perkins and Jörg Ott. Some 100 people attended the meeting. Jörg reviewed the agenda, with no changes being requested. He also provided a brief status update: Several WG documents are with the IESG now, some of them waiting to be updated. No RFCs were published since the last IETF. Internet Media Guides --------------------- Rod Walsh, Juha-Pekka Luoma, Yuji Nomura - draft-ietf-mmusic-img-req-03.txt - draft-nomura-mmusic-img-framework-03.txt Rod Walsh discussed the changes since the last version in the two above WG documents. The requirements document has seen various clarifications and formal corrections. The problem statement was augmented to point to the holes existing IETF protocols leave in the problem space. The use cases were reordered, further cases covering subscribe/notify requirements were added. Delivery and description requirements were clarified. For the framework document, the descriptions of SUBSCRIBE and NOTIFY operations were improved, the draft was aligned with the requirements draft. Finally, again, formal and editorial corrections were made. Rod then presented the conceivable next steps: the documents are already in WGLC, so there are considered pretty much complete. Within the IMG framework, three potential new areas of work have been identified: an IMG transfer envelope, a multicast delivery protocol, and a subscribe notify mechanisms. Thoughts on all areas exist as individual drafts, and Rod requests they be added to the MMUSIC or appropriate other WG charter (see below). There is quite some interest from other bodies (including 3GPP and DVB) so this work should proceed. In the following, Pekka and Yuji outlined the suggested work items, starting from the framework draft and filling in the components needed: The transfer envelope is supposed to be an XML definition for a container that can carry arbitrary metadata as contents (draft-luoma-mmusic- img-metadata-envelope-00.txt). This could be done in MMUSIC. The multicast transport protocol should be designed as a specific instantiation of the FLUTE protocol spec from the RMT WG, as suggested in draft-luoma-mmusic-img-muppet-04.txt. This work could be in MMUSIC or in RMT. The unicast subscribe/notifiy mechanisms could be based upon the SIP event framework, but no draft exists here so far. This could be done in MMUSIC or SIPPING. The presentation provoked some discussion on whether it would be appropriate to think about using the SIP SUBSCRIBE/NOTIFY mechanism, as no obvious relation can be seen to other SIP work. It was noted that this work is less about personal presence than about conveying state changes in general, and it was requested that clear use cases and requirement be drawn up and sent to the SIPPING list for discussion. Furthermore, it was remarked that the XML encapsulation format will become much easier if all data objects are labelled rather than allowing for generic XML to be encapsulated, e.g. for diffs. Yuji noted that a generic encapsulation is necessary. There were no objections raised against continuing this work. Colin and Jörg were tasked to talk to the ADs and the chairs of the other relevant working groups (particularly SIPPING and RMT) to determine where which work should go and to initiate re-chartering MMUSIC accordingly. SDP Security Descriptions for Media Streams ------------------------------------------- Flemming Andreasen - draft-ietf-mmusic-sdescriptions-03.txt Flemming briefly reviewed the overall structure of the draft and the changes since the last revision: It consists of a core framework and parameter definitions, a specific instantiation of this framework for SRTP, procedures on how to operate with, and without, offer/answer scheme, and a grammar. Quite a few changes have been made to the draft since -02: following consensus from the last IETF, support for multicast and multipoint SRTP sessions was removed, so was the SRC parameter. Rules for creating and removing crypto contexts are now more explicit. Numerous additions were made to clarify the use with offer/answer. Finally, the IANA registry structure was changed. Flemming pointed out one minor issue with offer/answer: with o/a, an initial crypto context is established. However, subsequent o/a exchanges may not just modify codec parameters but also peer addresses (IP address and/or port). In this case, the new entity may not have information about the current ROC value. The solution is to reset the ROC value to zero whenever any part of an address changes (at either end). A question was raised which changes would affect security; this seems to be restricted to the case of a transport address or port change at either end. The group felt the document was ready for WGLC. SDP Security Preconditions -------------------------- Flemming Andreasen - draft-andreasen-mmusic-securityprecondition-01.txt Flemming briefly introduced the problem to be addressed: during an offer/answer exchange, the offerer and answerer exchange security parameters. When the answered has picked a scheme (possibly one out of several offered) and the respective parameters, it can start sending media right away. The first packets of the secured media stream may reach the offerer before the answer, so that the offerer does not know which security description to use. RFC 3312 provides a solution by means of introducing preconditions which was suggested for this problem at the last IETF. In the meantime, no concerns were raised and no issues found so that this work is believed to be useful and also ready. It was tentatively agreed to adopt this as a WG item, pending charter discussion. SDP Connectivity Preconditions ------------------------------ Flemming Andreasen - draft-andreasen-mmusic-connectivityprecondition-00.txt Flemming introduced the problem to be addressed: various circumstances (e.g. deployment of NATs, firewalls, etc.) may interfere with packet transmission and may prevent media streams from flowing in either or both directions, even though call signaling setup succeeds. The proposed approach is to re-use the precondition mechanism defined in RFC 3312 with a new precondition tag to indicate that a call shouldn't proceed until connectivity has been verified. To test whether media stream connectivity (which is only defined for RTP) is available, a mechanism such as STUN or the proposed new RTP NOOP payload format can be used (the draft doesn't mandate any particular connectivity check). Significant discussion arose concerning the relationship between this work and ICE (the latter being used to ensure that there is connectivity). Commenters found that the term "connectivity" needs a more precise definition in the draft to be able to take a binary decision of whether or not a connectivity precondition is satisfied. A further issue was raised in conjunction with SIP forking, as the initiator of a call may receive packets from multiple destinations and may be unable to tell which branch satisfied the precondition. Flemming believes the approach is workable and took up the task to explain this in more detail in a revised version. The chairs noted that there is clearly interest in the draft, but chartering this as an MMUSIC work item again requires a charter discussion first. Interactive Connectivity Establishment (ICE) -------------------------------------------- Jonathan Rosenberg - draft-ietf-mmusic-ice-01.txt Jonathan presented three issues and proposed solutions regarding the current ICE draft. Issue 1 is may occur with a port restricted flow if the called entity does not respond soon enough, e.g. with a 200 OK in the case of SIP (refer to the slides for details of the message flow). In this case, a STUN timeout may occur at the callee because the caller does not receive the 200 OK and start sending STUN packets itself (thereby creating the necessary binding in its local NAT) so that media connectivity is not established. This is a race condition between the STUN timeout and the answer from the callee. Jonathan has two solution proposals: solution 1 is to mandate an immediate answer, this can be achieved in SIP e.g. with a 183 conveying the necessary addressing information back to the caller, and to increase the STUN timeout. Solution 2 is to mandate a second ICE cycle to re-check STUN-allocated addresses; this solution increases the signaling overhead associated with session setup (not the setup delay!) but eliminates the race condition in all cases. Jonathan proposed solution 1 as the appropriate solution. A comment was made that a connectivity precondition may solve this issue which Jonathan argues against. A suggestion was made to avoid a second cycle with solution two, based upon the priority order of the connection type. Jonathan feels that basing this decision on the NAT type determination is too risky, since it is difficult to determine the type of NAT that is present. A question was raised whether or not this use of 183 would interfere with "early media" via 183; this will be checked. It was also proposed to extend the timeout until the "200 Ok" in solution 1, and there was some brief discussion of the implications of this. No consensus was reached on issue 1. Jonathan will send mail to the list summarizing the issue and soliciting feedback. Issue 2 is on how to prioritize addressing information in ICE. So far, the intention is to minimize relaying and to prefer IPv6. There are, however, are other conceivable criteria, e.g. to maximize the number of hops across security networks, minimize path latency, minimize number of router hops, etc. The issue is (a) whether one of these criteria needs to be chosen and, if so, (b) which one. Jonathan argues that this is in essence a policy decision and ICE does not depend on any policy. It works as long as at least one uable address exists. Nevertheless, there may be many parties involved with different policies and preferences. With the work of SIP/SIPPING on session policies (e.g. allowing service providers to assert policies on media streams), the ICE address preference appears simply as another policy. Jonathan proposes to not fix address preferences but rather clarify, in the ICE spec, that there are different axes of optimizations and, document the existing algorithm. Other specs shall be allowed to define (informationally) other algorithms. A reference session policy should be described as a non-normative approach for finding out other policies. This proposal was found reasonable. Issue 3 addresses the interaction between ICE and RTP NOOP (a presentation on RTP NOOP was given). The NOOP format appears to have some commonalities with STUN: sent to RTP port, requests an immediate (RTCP) response, and checks for connectivity and QoS between endpoints. The same (except for QoS checks) can be said for STUN used by ICE. Jonathan briefly described the differences: NOOP uses RTP and hence is cleaner for RTP sessions; but ICE works for other protocols, too. NOOP uses RTCP for responses which are sent to different port and hence may not work through many NATs. ICE (STUN) also provides address allocation and uses username/password for validation while NOOP would require SRTP. The obvious options, given this commonality, are to either use only NOOP, to use only STUN, or to use both. There was a lot of discussion, trying to understand and clarify the differences between the drafts, with no clear conclusion. It is plain that clarification of use cases, and of the relationship and overlap between the various drafts, is needed. RTSP Update ----------- Magnus Westerlund - draft-ietf-mmusic-rfc2326bis-06.txt - draft-ietf-mmusic-rtsp-nat-02.txt - draft-zeng-mmusic-map-ice-rtsp-00.txt Magnus presented the current status of the RTSP core spec (see slides for the details). The spec has been progressing well. Out of the currently logged 40 bugs almost all are solved, with only six unresolved ones. The spec underwent major changes and restructuring: the use of RTP was rewritten, the syntax is now compiled in a single chapter, and a proposal on timing RTSP messages was included. The numerous minor updates are listed in the slides. Magnus discussed the open issues and their current status (elaborated on in detail on the slides). There was some discussion of options for authentication to prevent session hijacking, including the possibility to mandate use of RTSP over TLS, as an alternative to cryptographically random session IDs. It was also noted that we need to understand the use cases for destination redirection, to determine how big an open issue this is. Finally, Magnus presented those resolved issues that did not yet make it into the spec: RTSP proxies, use cases for RTSP, and the use of implicit redirects. Everyone is encouraged to review the revised spec in detail and comment! The editors will edit in the remaining issues. The teleconferences held for discussing and resolving issues shall be resumed. The goal is to finish the RTSP core spec in 2004. Next, Magnus reported on the interactions between RTSP and NATs. As per the discussion during IETF-58, a requirement section was added and the usage of ICE is now in a separate draft, and solution proposals (regarding protocol changing mechanisms) were removed. The remaining open issues include to clarify the recommendations on working with ALGs, with specific recommendation to be provided for firewalls ALGs (which are different from NAT ALGs). An appropriate protocol modifying solution needs to be chosen. Various high-level proposals exist for the latter including using ICE (for a proposal exists which is briefly presented), embedding STUN in an RTSP server, and using symmetric RTP. Interested parties are requested to write drafts; these should be evaluated afterwards and a single solution should be selected. Temporal References within URIs ------------------------------- Conrad Parker - draft-pfeiffer-temporal-fragments-02.txt Conrad Parker motivated the work by the need to define links to time points and regions within a real-time media resource (e.g. a movie) so that pieces of interest can be referred to directly. The draft on rfc2396bis defines "?query" and "#fragment" to enable referring to a subpart of a resource. This is integrated with HTTP and other download in a straightforward fashion: the server interprets the URI with the additional parameters and returns only the selected piece of the resource. Conrad notes that in RFC 2326 the handling of query identifiers and fragments is undefined. He suggests specific interpretations of queries and fragments for handlng by the server and the client, respectively. He raises various issues, particularly how the mechanism can be kept extensible. It was noted that, while there is a clear use case for fragment requests, it is less obvious why queries are useful. Some clarification was requested. Other short discussion suggests that -- rather than defining individual specific extensions for RTSP URIs and extending those every now and then -- it may be more appropriate if a generic header inclusion mechanism is defined, as for SIP. - * -