MMUSIC WG Minutes ----------------------- MONDAY, March 23, 2009, 0900-1130 Morning Session I ROOM: Continental 4 CHAIRS: Joerg Ott Jean-Francois Mule Reported by Joerg Ott 1. Agenda bashing and WG update (chairs) ---------------------------------------- The MMUSIC WG met once at the 74th IETF in San Francisco. The meeting was attended by 75 people. Jean-FranÁois MulÈ presented the agenda which was accepted by the working group. He proceeded to reviewing the Internet Drafts pushed out of the WG towards the AD and the IESG. In particular, since Minneapolis, draft-ietf-mmusic-qos-identification-03.txt was published as RFC5432. See slides for further details. Joerg Ott then discussed the status of the other WG drafts, noting that they are mostly progressing well. Reviews are needed for the draft on middleboxes in the media path. ICE TCP requires a new editor, preferably someone who has been working with ICE for a while and, as Jonathan Rosenberg added, someone who is intimately familiar with the socket interface and specific ICE implementations over TCP. 2. SDP Media Capabilities (Roni Even, 10) draft-ietf-mmusic-sdp-media-capabilities-07 ------------------------------------------- Roni Even presented the changes to the media caps draft. The draft extends the SDP capability negotiation mechanisms to media-related aspects, most importantly supporting non-trivial codec specifications including FEC, layered codecs, redundancy coding, and so on. Multiple revisions of the draft were issued since Minneapolis. Significant changes from version 04/05 include removing the definitions for bcap, ccap, icap, and kcap (to be spec'ed in another document), allowing capability renegotiation when modifying sessions and quite some editorial cleanup. The current version satisfies all the documented requirements, but the group is asked to double-check whether anything is missing. Roni called for further reviewers of this draft. A poll in the room revealed that only very few people are currently considering implementing this, but volunteers for reviewing were found. 3. RTSP 2.0 (Magnus Westerlund, Martin Stiemerling, 40) draft-ietf-mmusic-rfc2326bis-20 ---------------------------------------------------- Magnus Westerlund and Martin Stiemerling presented the updates to the RTSP-bis specification. He started out with a formal note that the new IETF copyright statement requires contacting and obtaining consent from all authors, yet not all have responded. On the technical and editorial side, quite a few major changes were performed in -20. The biggest editorial change was replacing the many references to the HTTP RFC with text so that the RTSP spec becomes self-contained, much more readable, and less ambiguous. While most references have adapted text, two sections, in fact, contain an exact copy of the HTTP text (18.1 and 18.2). Since this involved a major (re)write, good reviewers are needed to double-check that the outcome is correct. Furthermore, draft -20 includes clarifications to the model and use of GET_PARAMETER, covered by completely new text. The technical mechanisms are not new or modified, but they are described in a different way and additional text is provided to describe how headers are supposed to be used. For some headers, Accept-Ranges, Media-Range, Media-Properties, Range, and RTP-Info, GET_PARAMETERS may be used to retrieve their current values. As a follow-up of a long design discussion at the Stockholm interim meeting, the Speed header has now been properly defined (see slides). Specifically, speed ranges are allowed to enable buffer prefill. One skeptical comment raised from the audience was whether this should even be specified, considering that this would also need to be implemented. In the meeting, there was some interest in this feature, and further discussion will be taken to the list. A clarification question raised on the list on the use of sequence numbers was discussed, namely the addition that RTP sequence numbers need to be monotonically increasing, unless PAUSE and PLAY are used in a live stream. Some clarifying text was added (and gaps in the RTP sequence number space are now explicitly allowed). Finally, RTP and RTCP multiplexing is now documented as a optional feature, not mandated on either (client or server) side. Support for this feature can be indicated by the server in the SDP session description and, if so, may be requested by the client. A couple of open issues remain that require feedback from the group: -- The Server killing the session in ready state despite keep-alives. This was discussed on the list and new text was added; needs feedback. -- RTSP From header; what is needed? -- The possible interaction between speed/scale is not yet clarified in text; Speed/scale are seen to be orthogonal. But this needs a textual description. The authors announced that they are performing consistency checking now and that another update to be coming by the end of April. They make a call for reviewers, now! This is the last chance to make technical changes! 4. Middlebox Interactions for Signaling Protocol Comm. along Media Path (Hannes Tschofenig, 5) draft-ietf-mmusic-media-path-middleboxes-02 -------------------------------------------------------------------- Hannes Tschofenig reviews what this document is about and explains its history and context (no slides). The recap is primarily done to obtain reviewers for the document. Three volunteers are found: Martin Stiemerling, Jonathan Rosenberg, Cullen Jennings. The chairs will issue WGLC now. 5. FEC Grouping Semantics in SDP - RFC4756bis (Ali Begen, 10) draft-ietf-mmusic-rfc4756bis-01 ---------------------------------------------------------- Ali Begen presented the draft with the aim to head for WGLC soon. He briefly reviewed the basic motivation, most notably to achieve maximum flexibility for the FEC framework with respect to protection of and across individual streams (see the slides for details). He identified the currently missing semantics and presented the approach taken in the present draft. One question was raised on the relation to the SSRC attributes draft. Ali mentioned that this was brought up before and that the draft attempts to be broader than RTP. Jonathan Lennox and Ali Begen will check offline whether there are any issues and report the results to the list. Ali also raises the question whether RFC 4756 shall be obsoleted. Steve Casner points out that, if the draft is complete, RFC 4756 can be obsoleted. Ali will poll the list on this. The chairs ask the group to raise any comments on the list. They will be issuing WGLC soon. 6. SDP image attribute (Ingemar Johansson, 10) draft-ietf-mmusic-image-attributes-01.txt ------------------------------------------- Ingemar presented the SDP image attribute draft. The intention is to capture generic image attributes (generic in the sense of independent of a specific codec or format). Numerous clarifications were folded into the draft since the last revision and the known issues were addressed. The aim is now to head for WGLC. Ingemar discussed one potential issue, namely if it is a problem if an answerer replaces all offered parameters in its response because there is no good match -- and how the individual configurations are then negotiated (see slides for details, specifically also the simplified example from the 3GPP context). Quite some discussion about square pixels and aspect ratios ensued. It was commented , there may be some distortion on the screen depending on the pixel aspect ratio between the original picture size and the finally rendered one. It was noted that the 'sar' parameter is primarily intended to reduce the processing load on the receiver. Non-square pixels will require further consideration. 7. SCTP protocol identifier for SDP (Gonzalo Camarillo, 10) draft-loreto-mmusic-sctp-sdp-03.txt draft-ietf-tsvwg-dtls-for-sctp-00.txt ------------------------------------- Gonzalo presented SDP extensions to support SCTP. The draft defines two new protocol identifiers ('SCTP' and 'SCTP/TLS') as well as the use of the 'setup' and 'connection' attributes to establish SCTP associations. Since no-one so far has implemented SCTP/TLS and it has some issues, one suggestion is to remove it and use DTLS/SCTP instead, as documented in draft-ietf-tsvwg-dtls-for-sctp-00.txt. Gonzalo discussed the use of SDP and SCTP with multihoming (see the slides for details). Specifically, SCTP can exchange additional addresses in-band without signaling them via SDP. This creates an issues with SBCs that would not be aware of these additional addresses (and could block them). This could be resolved by using a 'main' address in the SDP c= lines and use re-INVITEs whenever a new set of addresses is chosen. While cumbersome and inefficient, this would make those addresses visible to SBCs. A quick inquiry revealed that there is limited interest in the audience; only a few people had read the draft. This will be progressed as an individual contribution for the time being.