Minutes of the AVT Working Group, IETF 71 The AVT Working Group met twice at IETF 71, on Tuesday at 15:20-17:20 and on Thursday at 15:10-16:10. Roni Even and Tom Taylor chaired. Colin Perkins was unable to attend the meeting in person, but was listening in and monitoring the Jabber connection. xx persons attended. Jim Failla and Stephan Wenger took notes. FIRST SESSION: Tuesday 15:20-17:20 1. Agenda and Status ================= Roni Even presented the charts giving Working Group status. These are available at http://www3.ietf.org/proceedings/08mar/slides/avt-0.pdf. The charts began with an agenda review, the IPR NOTE WELL statement, and then went on to document status. [Colin noted on Jabber that the Area Director has agreed that the Header Extension draft has solid consensus from the Working Group, so we will be re-issuing the request for publication after the authors issue a minor update.] ATRACS passed WGLC with minor comments -- the authors will submit an update, people can review for a week, then we will send it to the IESG. 2. Scalable Video Coding -- Thomas Schierl presenting. draft-ietf-avt-rtp-svc-08 ================================================== Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-6.pdf. The initial charts presented recent changes, then went on to mailing list comments. The next slide introduced the topic of decoding order recovery. There was a three hour meeting Tuesday morning, but the discussion did not reach a conclusion. The presenter expressed the desire to reach one now, at the meeting. It was still unclear in the morning's discussion whether mode 0 could be supported by CL-DON. The presenter reviewed the CL-DON solution, and then the use of classical RTP mechanisms for order recovery. Then he showed possible solutions based on the morning's discussion. However, he noted that there is still no consensus. Roni Even remarked at this point that we had had a design team working on this since last meeting. The design team is not a closed group -- it was announced on mailing list. The design team will continue until the open issues are resolved. Thomas moved on to present the four open issues charts. On the fourth chart, he asked if we need a generic draft for the sprop-spatial-resolution parameter. Roni had no comment. Colin remarked that this would be something more than RFC 4566 a=quality:, presumably. Roni expressed thanks to Mike Nilsson (absent) as well as all the other participants. Thomas Wiegand approached the microphone and gave his own summary of the proposals. He appealed for views from the floor, saying that there had been too much back-and-forth in the design team discussions. He noted that DVB and other SDOs have deadlines and would like to see this brought to a conclusion. Basically he asked for the ability to avoid using the technology they do not want. Roni noted that other SDO requirements are a matter for the Area Director. We have to have rough consensus, but can consult with the AD on how to proceed. Dave Oran introduced himself as an ex-AD and asked how long this debate has been going on. Stephan Wenger replied that at least a year ago he made a presentation on the order recovery problem. Stephan gave two choices then: put in some information -- a Nokia patented technology -- or go through a fairly complex and hard-to-understand specification process. The answer he got then was to go ahead with what he thought best. In short, we have been here before. Summing up, the two proposals are to add redundant information or not to do so. Nokia is not convinced the "classical" system would actually work under the constraints they face. Nokia already have a pile of patents -- this particular one is not important in the whole picture. Dave Oran remarked at this point that if there is an even split in the Working Group, we have no process for dealing with it. He asked whether IPR disclosures have been filed. They have been, by both sides and by BT. Colin noted offline the following IPR declarations: https://datatracker.ietf.org/ipr/736 https://datatracker.ietf.org/ipr/852 https://datatracker.ietf.org/ipr/832 https://datatracker.ietf.org/ipr/910 Dave noted that the differences in terms of disclosures are something to be considered by the Working Group. Thomas Wiegand proposed to tie the techniques to the modes -- classical for modes 0 and 1, CL-DON to mode 2. [Colin suggested that he should send text, then ask if there is consensus to accept it.] Stephan Wenger noted that packetization mode 2 is related to high-delay applications. One needs to buffer several pictures before doing meaningful decoding. It is also IPR-encumbered, but that is not to the point. The division between modes 0 and 1 and mode 2 is not the right dividing point. Timing requirements are definitely an issue. Nokia are not stalling the draft, as Thomas implied. They are simply not convinced it would work well without CL-DON. Roni asked for the timeline requirements. Thomas Wiegand said DVB need an RFC number for the SVC payload by December. It follows that we need a WGLC by summer. [Colin noted that WG last call can happen between meetings, of course.] Roni said that he had been hoping that based on work that day we could achieve a full consensus. We need to have a good description about what each of the methods means in terms of delay and other relevant characteristics. Thomas Wiegand asked why RTP does not already provide a method to do this synchronization. Roni responded that it does, using the timestamp. Thomas asked, then why add unnecessary IPR. Stephan remarked that RTP allows correct reconstruction of transmission order. (Roni added that this is different from the playback order.) Stephan continued, that there is a difference between the basic RTP capability and the problem here, where we have to sequence parts of packets. Thomas Schierl intervened at that point to say that this problem arises with mode 2, not mode 1. There was some back-and forth discussion on the difficulty of the operation. Stephan summarized: he was trying to make the case that there is more complexity than the classical RTP mechanism was designed for. Roni agreed -- otherwise there would be no discussion. Ye-Kui Wang noted two differences from the classical problem. First, different sessions are sent to different decoders in the classical model. Also, we are trying in this case to restore the order set by the coding specification. Randell Jesup remarked at this point that startup time is an issue. Ye-Kui agreed, this is an important point. Roni remarked that Magnus Westerlund would be presenting on RTCP extensibility on Thursday. This would be a good time to discuss start-up time. [Magnus pointed out on Jabber that Joerg Ott would be doing the presentation on that topic.] There was some discussion between Thomas Wiegand and Roni on what Nokia is saying. Thomas Wiegand asked again: if it is agreed that RTP method works, why not use it? [Colin remarked that RTP synchronization says nothing about the decoding order of the media. This is the point Stephan Wenger seemed to be trying to make earlier.] The Chairs cut off the line and discussion after Joerg Ott , who complained that our time is being wasted. 3. RFC 3984bis, Ye-Kui Wang presenting draft-wang-avt-rfc3984bis-00 ====================================== Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-1.pdf. Six charts described technical changes before the presentation moved on to open issues. On open issue 6 (meaning of the capability parameters), Roni remarked that the point is that we want the semantics to be consistent. Ye-Kui pointed out the relevant text in the draft. Roni repeated his point. Stephan Wenger noted that this one had been discussed a while ago in a WG meeting -- it was marked as an issue over a year ago. The presentation moved on to issue 7, level downgrading of parameter sets, which Randell Jesup raised on the list. Randell explained the problem at the mike: trying to change the level without having the right parameter set is problematic. The peers may have to renegotiate. The sender could send every parameter set for every level he could be downgraded to -- doesn't seem good. Randell is really open to suggestions, but thinks it unlikely you can just modify parameter sets on the fly. Roni amplified that the problem is when you specify new level, and you want to use different parameters. The first point with H.264 is that the decoder should be able scale to anything. In H.323 the parameter sets are sent inside the stream. This point has been raised before in connection with video switching. Stephan Wenger agreed that this discussion has occurred before, and he saw that no one had a better idea than the proposed solution. Roni remarked that it should be clear that what you ask for is full information including the parameter set. Stephan pointed out that things are not the same in H.264 as in H.241. Roni summed up: basically we need a way to ask for a new parameter set. Stephan agreed, OK, we need to choose something. Roni and Stephan agreed to present options to the list. Randell asked if we need to continue support for out-of band parameter sets? Do we need to support in-band parameter sets? If you are not downgrading the level, the problem is much simpler. He raised one other issue -- what do we allow to be downgraded? He is talking level 1B. Roni pointed out that H.241 says something on the subject. It is not part of the hierarchy, so 1B should be treated separately. [Tom Kristenmson remarked on Jabber that it may be an idea to include level 1B in this bis-draft. Randell continued. Downgrade is a real issue. Regarding the other issues: external meanings (issue 1) should be out of scope. Roni agreed. Regarding issue 3, Randell pointed out that different payload types have different packetizations. You can't say a property of a payload stream is a property of a payload type. Thomas Wiegand asked if we talking about a new profile here? Roni responded that we may have new SDP parameters. They should be approved in a separate draft. When we have an update to the main specification, we include the parameters in that document. Looking to the final chart: should this be a WG item? Several hands were in favour, none against. This will be a WG item (subject to confirmation on the list). We will merge it with the H.264 parameters draft. 4. RTP Payload Format for MVC Video, Ye-Kui Wang presenting draft-wang-avt-rtp-mvc-01 ======================================================== Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-2.pdf. The initial charts showed multiview application principles (as in last meeting). There was an update on the status of MVC standardization, a summary of the draft, and a list of changes since the initial draft. Ye-Kui asked if this could be a Working Group work item. Thomas Wiegand asked if are we going to repeat all the SVC stuff here? [Colin noted on Jabber, repeated to the room, that it would be desirable to have a single mechanism for cross-layer synchronization for all H.264 extensions, rather than a different one for each extension.] Stephan Wenger said he believes he asked for a sense of direction before. Should MVC be a delta on SVC, so we would end up having to read a whole cascade of documents? Stephan expressed the belief that we agreed on a stand-alone document. We can work on the delta, then do any necessary copy-paste. Roni said we don't have to worry for WG items. 5. Non compound RTCP, Ingemar Johansson presenting draft-ietf-avt-rtcp-non-compound-03 ================================================================================== Charts are at http://www.ietf.org/proceedings/08mar/slides/avt-4.pdf. The authors felt a need for a new definition of non-compound packet, as stated in the charts. Jonathan Lennox asked a question for clarification. Randell Jesup had no problem with either the previous or proposed definition. The authors are hoping the draft will be ready for a Working Group Last Call after they have cleaned it up. 6. RTCPHR - Alan Clark presenting draft-ietf-avt-rtcphr-03 ========================================================== Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-5.pdf. Alan noted that other SDOs are interested in HR. Roni observed that Colin had sent a note about this draft to the list. It needs to address the organization of measurements (architecture). Roni suggested Alan correspond with Colin. [Colin noted on Jabber: Alan said it himself - this is very application specific. We saw with RTCP XR that application specific metrics don't work well. Define a general metric, which can then be used for particular applications.] Roni asked for other comments. There were none. He noted that Joerg Ott's draft on guidelines for extension of RTCP could be a guide. SECOND SESSION: Thursday 15:10-16:10 Roni Even summarized the status of the basic DTLS-SRTP specification. It will be sent to WGLC after WGLC of media security requirements has been completed in SIP. 1. DTLS-SRTP Key Transport - Dan Wing presenting draft-wing-avt-dtls-srtp-key-transport-01 =============================================================== Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-8.pdf. The final chart on the voicemail storage and retrieval use case drew a comment from David Oran. He stated that the suggested configuration was fundamentally useless because the user cannot perform operations such as fast forward. SPEECHSC worked through this. The scenario is not realistic. [Randell Jesup remarked on Jabber that if message playback is done on the encrypted packets you have a problem because the sequence numbers/etc should change; you may not be able to simply replay encrypted packets in the more complex uses. The VM server *could* decrypt and then re-encrypt to send to reader.] Dan concluded by asking if there were WG interest in the work. Roni Even said that he was personally interested in the MCU application, i.e., encrypting separate streams with the same key. Eric Rescorla wondered whether this can be extended to DTLS and TLS. He and Dan got into a discussion with no clear result. 2. Why SRTP cannot be mandatory - Magnus Westerlund draft-perkins-avt-srtp-not-mandatory-00 ================================================================================= Magnus presented. Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-9.pdf. The first chart stated the issue: the question frequently arises, why SRTP is not made mandatory for RTP/RTCP. However, RTP is deployed in a wide variety of environments and applications, with varying requirements for the individual components of security and other relevant aspects. The next chart explained why this draft was written. The final chart summed up status and open issues. [Randell Jesup remarked on Jabber that at least pointers to the best practices, etc would be good.] Dan Wing commented that he liked the document, but it should add reference to practices that help enable security such as MMUSIC capability negotiations. Roni mentioned that some information on current practice is available from SIPIT. Dan continued: the document should not be saying "Don't use SRTP", but: "Here's how an RTP system can upgrade itself to SRTP". To him that is negotiation. Roni and Magnus responded. Dave Oran said that these are two different topics. How to do SRTP is a second document (pointing to Dan as the possible author). Dave continued: this document is right at the edge of saying too much, and he encourages the author not to go beyond that point. Sometimes, the problem of using SRTP is the environment, not the application. One example is when RTP is being carried over IPsec. Magnus commented that this was a matter of definition of application vs. environment. Dave remarked that "application" is a loaded word. Hannes Tschofenig sort of liked the document, but was concerned: how many "How to" books are going to be written? During IETF Last Call a lot of crazy comments fly around, and this document could help to improve that, but ... Roni and Magnus responded briefly. Magnus said the motivation was really to describe why SRTP is not needed sometimes. Stephan Wenger said that as he read it, this document is addressed to security people. The message is needed. Roni Even asked who would be in favour of making this a Working Group document. 20 hands were raised in favour, with none opposed. 3. RTCP guidelines - Joerg Ott draft-ott-avt-rtcp-guidelines-00 ============================================== Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-11.pdf. The draft is a first pass at the topic. The first chart gave motivation, the next chart reviewed what RTCP was capable of. The next chart discussed the RTCP feedback loop. [Randell Jesup remarked on Jabber, repeated to the room, that codec choices should be via negotiation or switching negotiated payload types. He couldn't see how RTCP is used for the purpose. Colin Perkins clarified that what was really meant was to negotiate as many codecs as possible, then switch between them freely based on RTCP feedback. Magnus pointed out in addition that in reality we are getting more codecs that actually vary rate and packetization within the same payload type.] The presentation continued with security considerations, then posed a preliminary set of RTCP guidelines. Dave Oran suggested adding that RTCP should be carried in the same traffic class as RTP, and that the implications of this should be discussed. [Randell Jesup remarked on Jabber,that with RTP/RTCP multiplexing it was even more likely they would be in the same traffic class, though not always guaranteed because intermediate nodes might re-mark them.] Roni Even asked how many had read the draft. About eight hands were raised. Roni noted that the draft should help to answer the questions that keep coming up on the list about timing and synchronization. [Randell Jesup remarked on Jabber, repeated to the room, that we should recommend that people not make a protocol/application depend on *ever* getting their RTCP packets through to the other end.] Stephan Wenger suggested that he would split the draft if he were author. One target those who really need to learn about RTP. The second topic is when and how appropriate it is to use RTCP. Joerg said the split might be appropriate after the document has grown a bit. Ingemar Johansson remarked that people should be warned against the use of RTCP for in-band signalling -- this topic is hopefully dead and buried. Roni agreed firmly that this was so, and we should not revive it. Joerg said as a last word that it would be good to have discussions on when it is useful to do extensions. [Colin extended his thanks on Jabber to Magnus and Joerg for presenting in his stead.] 4. Using SEED Cipher Algorithm with SRTP - Seokung Yoon presenting draft-ietf-avt-seed-srtp-00 ==================================================================================== Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-10.pdf. The presentation briefly reviewed the draft content and noted the changes since the initial Working Group draft. Eric Rescorla asked if they had considered adding Galois counter mode as well. After a little discussion with the presenter Eric explained that the draft presented a specific choice of cryptographic mode with a certain setting, and with a specific MAC algorithm. There are other modes and settings you could use as well. The draft should explain why the specific choice was made. Roni Even agreed. He called for WG feedback on draft, to get it ready for WGLC. There should be a new version before the next meeting.