Last Modified: 2005-01-24
| 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 | |
| Done | Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG. | |
| Done | Submit SDP security extension for Proposed Standard | |
| Done | Submit IMG requirements and framework for Informational | |
| Aug 04 | Submit revised SDP spec for Proposed (or Draft) Standard | |
| Done | Submit SDP Offer/Answer examples for Informational | |
| Aug 04 | Review work on IMGs and update charter accordingly | |
| Done | Submit SDP connection-oriented media draft for Proposed Standard | |
| Nov 04 | Submit SDPng transition scenarios for Informational | |
| Nov 04 | Submit SDPng base specification for Experimental | |
| Nov 04 | Submit ICE draft for Proposed Standard | |
| Feb 05 | Submit revised RTSP spec for Proposed or Draft Standard (as appropriate) | |
| May 05 | Submit RTSP NAT considerations draft | |
| Jul 05 | Consider update of SDP specification for draft standard | |
| Dec 05 | Submit updated SDP Offer/Answer examples draft for Informational |
| RFC | Status | Title |
|---|---|---|
| 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 |
| RFC3890 | Standard | A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) |
|
Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
==================================================================== Reported by Colin Perkins and Joerg Ott The MMUSIC working group met once at the 62nd IETF meeting (Minneapolis, March 2005). Topics under discussion included SDP extensions for BFCP, content labels and connectivity preconditions, the ICE methodology for NAT traversal, the SDPng specification, stream tracking for resource management, harmonisation between SDPng and MPEG-21, RTSP, and Internet Media Guides. The meeting was chaired by Joerg Ott and Colin Perkins. SDP Format for BFCP draft-ietf-mmusic-sdp-bfcp-00.txt Gonzalo Camarillo presented the SDP Format for BFCP. The specification for BFCP now has support for different hashing algorithms, meaning that the SDP format needs to be updated to use the sdescriptions format, not than the "k=" line. There have also been a number of clarifications to the draft regarding peer-to-peer use of BFCP (this work is ongoing). Gonzalo solicited input, noting that he expected the next revision to be complete. There were no comments. SDP Content Label draft-hautakorpi-mmusic-sdp-media-content-00.txt Jani Hautakorpi discussed the SDP Content Label. This is a media level attribute that can be used to label streams with semantic meaning, so receivers can automatically treat each media stream appropriately. It is expected that labels will be things like "main camera", "speaker" or "presentation slides" and will be partly interoperable with roles defined by H.239. There was an extensive discussion regarding the difficulty of assigning labels and explicitly defining their semantics, with Brian Rosen noting that it may be hard to come to agreement about labels and their meaning. Gonzalo Camarillo and Roni Even disagreed about the difficulty, noting that there is a need for these labels, and that products exist that implement similar mechanisms. Jonathan Rosenberg and Brian Rosen both commented that there is related work ongoing in the SIMPLE and XCON working groups, and similar concepts in SMIL, with which we may need to align. Henning Schulzrinne and others noted that there are many possible labels, but that we only care about a small number of simple cases, and an application that receives an unknown label is no worse than one which receives no label. Joerg Ott finally wrapped up the discussion by noting that there is a clear interest in this work, and encouraged people to read and comment on the mailing list. SDP Connectivity Preconditions draft-andreasen-mmusic-connectivityprecondition-02.txt Flemming Andreasen presented the draft on connectivity preconditions for SDP media streams, outlining the problem and changes since the previous version. An open issue is that the draft does not mandate any particular way of verifying connectivity, although it does recommend the RTP NOOP format. Should the draft mandate a mechanism and if so which mechanism? Colin Perkins noted that the RTP NOOP draft has expired and will need to be updated if that is the choice. Flemming and Gonzalo Camarillo wondered about the overlap between the connection and connectivity precondition drafts and whether they should be merged? There was discussion about the semantics of connection establishment versus those of connectivity. Jonathan Rosenberg, Magnus Westerlund, Gonzalo and Flemming discussed the need for a three-way handshake to define connectivity and how NAT traversal issues may affect this. There was no real conclusion: it is clear further discussion is needed on the list. ICE draft-ietf-mmusic-ice-04.txt Jonathan Rosenberg discussed the ICE methodology for NAT traversal, noting that the -04 draft has not been changed compared to the -03, but that there are a number of open issues. Changes that have been agreed and will be incorporated include a clarification of re-INVITE behaviour, a change to make implementation of TURN optional, setting the RTCP bandwidth parameter to zero if you are not using RTCP, and some discussion on issues regarding congestion caused by STUN traffic using session startup. Open issue #1: obfuscating ICE addresses. Is there a need to try to obfuscate IP addresses to prevent "helpful" NATs from rewriting the addresses and breaking ICE? Consensus: no. Open issue #2: RTP specificity. The candidate attribute is RTP specific but we may need candidate addresses for non-RTP transports. Propose to define a more generic candidate attribute, using the priority field to group candidate addresses (e.g. to group RTP and RTCP). Consensus was to make this change. Open issue #3: TCP alternates for UDP. Currently the only alternatives you can choose for UDP are other UDP addresses; we cannot fall back to a TCP connection if all UDP addresses fail. Propose to extend the ICE specification to allow fallback to TCP as a connection of last resort, and to document both how this affects performance and the implications this has for sites that block UDP at their firewall as a policy measure to prevent VoIP. Cullen Jennings was concerned that this has potential to start an arms race with firewall vendors and administrators, and worried about circumvention of firewall policy. Colin Perkins and Jon Peterson noted that certain proprietary applications also fallback to TCP: this is not an unknown technique, we need to compete with those systems to ensure our protcols remain valid and useful. It seems that there was rough consensus that use of TCP was not ideal, and concern that one may not wish to implement fallback to TCP as a default, but that in the current Internet it may be necessary to allow such a fallback as an option. There are a number of other open issues, concerning fallback to TCP and identification of RTP profiles, diagnosis of problems since the final IP address and port are never signalled, interaction with preconditions and middleboxes, dynamic RTP address changes, the ugliness of demuxing STUN and RTP, and interactions with SRTP. Jonathan noted that the root cause of all these problems is the single fact that a peer in the dialog starts sending media to the new address once the connectivity check succeeds without signalling that address. Proposal: separate these and always send media to the address/port in the "m=" and "c=" lines, and only send connectivity checks to the address/port in the candidate lines. When connectivity checks succeed, do a re-INVITE or UPDATE that "promotes" the candidate address/port to the "m="/"c=" lines. Note that this does not increase call setup time or post-dial delay. [see slides for a sample call flow, illustrating operation of the proposal]. There was considerable discussion of the details of the idea, with the consensus being generally in favour. The details will be defined on the mailing list, with an updated draft to be published documenting the new approach. Stream Tracking for Resource Management in the Network draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt Ingo Wolf presented a new proposal for streaming tracking for resource management in the network. This is a modification to SDP and SDPng to convey source addresses and ports, which is hoped can be used to signal stream details to middleboxes which can then attempt to ensure QoS. Cullen Jennings inquired the precise problem definition that the draft is supposed to solve and wanted to know why the proposed solution solved it. Ingo stated that the motivation is to provide an explicit grouping between source addresses of RTP and RTCP. However, Cullen argued that the draft seemed to be primarily about QoS with some missing information at present. Source port information are only one piece of these missing bits but there is a whole lot more. He wondered why the draft did not concern itself with these additional missing parameters. According to Ingo, this was beyond the scope of the draft -- which was understood, but this exactly raised the issue of what precisely the draft tries to address. Joerg Ott noted that SIP signalling provides a clear separation between the precondition work to signal that some sort of QoS is required and the mechanism used to establish the QoS. The two pieces are currently separate: this draft tries to combine them, but it is not clear that they belong together. Joerg noted that the draft assumes entities on the path have access to the content, and that source ports are accurate, but we have generally assumed the opposite in the IETF. Magnus Westerlund agreed with Joerg and Cullen, further noting that with NAT traversal being an increasing issue it is often the case that an end point is not aware of its address as seen by the peer endpoint. In summary, the added value of this proposal is unclear. Harmonization between SDPng and MPEG-21 draft-guenkova-mmusic-mpeg21-sdpng-00 Ingo Wolf presented further on a proposed harmonizatoin between SDPng and MPEG-21: He claimed that SDPng was transport-oriented while MPEG-21 DIA was technology-independent and focused on (media) presentation. He suggested an integration model in which all the SDPng containers are reused. The <cap>, <def>, <cfg> elements largely remain the same, only some adjustments are proposed to the RTP package. The <constraints> element is augments to cover Usage Environment Descriptions (UED) and should be used to address constraints all levels of abstraction. Important extensions include the reference to external definitions using the href attribute, the application of MPEG-7 media stream and codec spefications, and some revisions to name-value pair based mechanism for cross referencing definitions within an SDPng document. Ingo walked through a detalied example (see slides for the details). Steve Casner noted that the namespace for MPEG-21 has a huge overlap to the one defined in RFC3551. He further pointed out that to the extent that MPEG-21 identifies how transport is to be done, the RTP names identify actual payload formats. One cannot simply skip that identification as this is needed in additon to the codec identification. Brian Rosen agreed that one needs to explicitly specify the mapping. Colin noted that the key advantage of SIP/SDP is that peers can negotiate arbitrary MIME types. He questions the benefit from the proposal which is limited to a subset of the codecs that are supported through the MIME type mechanism and adds that the proposal does not support application/*, text/*, etc. Magnus Westerlund pointed out that the proposal allows to describe streams that cannot be transported, and Dirk Kutscher uttered similar concerns to Colin and Magnus. In summary, it is questionable how the approach presented relates properly to the work in MMUSIC, AVT, and other groups in the IETF at large. SDPng draft-ietf-mmusic-sdpng-08.txt Dirk Kutscher presented the latest draft on SDPng. After a brief recap of the motivation and the overall structure, he stressed which aspects are not (supposed to be) covered by the SDPng base spec: application-specific vocaublary, application semantics, vocabulary for expressing constraints across multiple configurations, and vocabulary for metadata. This additional information needs be either specified as extensions/packages (e.g., transport protocols, codecs, packetization formats) or defined in the context of the respective applications (e.g., semantics). The changes in the most recent version include a more explicit inclusion of broadcast scenarios (cf. SAP, IMG), correspondingly make the <cap> element for negotiation optional, and the addition of descriptions of further scenarios. A "status" attribute has been added for the <component> elements and a new child element <part> is now allowed for the <info> element that allows encapsulating arbitrary meta description formats. Open issues at this point include: the status element is currently overloaded (and part of the semantics will be moved to the RTP package), IANA considerations need to be written (a registry for package information needs to be set up), XLM schema and DTD definitions need to be done, and the examples need to be aligned with the spec. Finally, at some point, the spec needs a real name (other than "SDPng"). The group is encouraged to review the spec now and comment so that WGLC before 63rd IETF is possible. Next steps to take further include completing the RTP package definition, dealing with a security package, and providing for meta descriptions. Info Wolf noted that he wants to see more discussion about how people could extend SDPng. Colin Perkins agreed with that and encouraged further work to be put into this. RTSP draft-ietf-mmusic-rfc2326bis-09.txt Magnus Westerlund presents the current status and some issues with the current revision of the RTSP specification. Due to shortage of time, he skips most of the stuff and starts with the issue of explicit white spacing (slide #5): he reviews the RTSP rules for white spaces as separators between tokes. He wants to change the use of "," and ";" to explicitly allow for whitespaces around them for which he seeks input from the group. Another (related) issue are the RTSP headers that are currently defined with reference to RFC 2616. However, RFC 2616 does not use RFC 2234 BNF with explicit white spacing. His suggestion is to copy the syntax into RTSP and make the whitespaces explicit. The chairs urge people to review the draft and comment. Internet Media Guides Yuji Nomura shortly described the recent activities regarding IMGs. Due to lack of time, he keeps the presentation extremely short: He briefly summarizes the interim discussions on the IMG envelope to carry metadata: the authors and a few others have discussed the use of XML as envelope systax vs. MIME encapsulation. Both can be defined (or extended) to provide the right functions for IMG envelopes and allow the re-use of existing specifications. XML is expected to require more work and be not as efficient to encapsulate binary data but MIME is not a perfect match either. Open issues are related to the inclusion/representation of versioning information and a metadata URI, a validity period, and proper authentication of subsets of IMG metadata. For the next steps, input from the group is sought: a new draft on an IMG envelope based upon MIME may be defined, the other drafts will be updated. - + - |