IETF 77 AVT Working Group Minutes AVT Session 1 Palos Verdes 1300-1500 Wednesday March 24, 2010. Roni Even and Keith Drage chairing. Note takers Ingemar Johansson and Tom Taylor . Audio archive at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77- ch7-wed-afnoon.mp3 A change of Working Group Chairs was announced. Tom Taylor will move to become AVT WG Secretary and MMUSIC Co-Chair. Keith Drage will replace Tom as AVT Co-Chair. Note Well notice presented. 13:00 Introduction and Status Update ==================================== Roni presenting, charts at http://www.ietf.org/proceedings/10mar/slides/avt-0.pdf. a. Agenda bashing No comments. b. Document status Three new RFCs, a number of documents in various stages following WGLC. c. Quick review of selected documents Charts summarizing: draft-ietf-avt-ecn-for-rtp-01 draft-ietf-avt-srtp-ekt-00 draft-johansson-avt-mcast-based-rams-02 draft-xia-avt-splicing-for-mpeg2ts-ps-00 draft-lennox-avt-srtp-encrypted-extension-headers-01 draft-ietf-avt-multicast-acq-rtcp-xr-00 Comments requested for ecn-for-rtp. Re EKT: list question, how to use DTLS-SRTP with multicast. Should that be in scope? No further comments on any of the drafts. The Chairs want to make sure that the three current RAMS drafs (RAMS, portmap and preamble) advance before accepting additional WG items. 13:15 AVT Restructure Robert Sparks ===================== Chart at http://www.ietf.org/proceedings/10mar/slides/avt-1.pdf. Shows a potential split into four areas: core maintenance, payload types, XR framework, AVT extensions. List comments: Comments on list don't question core maintenance. For continuity, payload specifications should be WG rather than experts' group. No comments on XR. Specific charters for applications like RAMS. Use DISPATCH. Roni Even: sees no reason to split AVT core and payload types. Participants in XR no longer appear at AVT. Fourth item: specifically for RAMS, DISPATCH for other stuff. Stephan Wenger : no need for maintenance -- isn't happening. Payload formats the major work of the last few years -- will be permanent, should be WG. Amounts to renaming of AVT. No support for XR group because of lack of support. Payload-independent work can be dealt with anywhere. Anything that requires intimate knowledge of payload structure should go into the payload group. That includes RAMS. Summing up: don't bother changing anything. Jonathan Lennox wondered where the audio level work would fit. Roni: would probably have to recharter to do it. Tom Taylor said he had had in mind that maintenance would include stuff like header extensions, SSM. Is Stephan saying in effect that there is no more of that to be done? Gonzalo Camarillo (Area Director): the argument that we can do everything in AVT is reminiscent of the SIPPING discussion. But that didn't work -- DISPATCH has increased energy levels and the pace of output. Roni: RTP payload is analogous to SIPCORE. The extensions stuff is DISPATCH work. Cullen Jennings (outgoing Area Director): AVT has much the largest workload in RAI. How can we split that up? OK, we've heard that the XR stuff is no longer of interest, no-brainer to take it off the table. Robert: understood that there is no further interest in extending the XR framework, but there may still be interest in doing new XR reports. Stephan Wenger: if it is split, watch the scheduling. Don't want to make experts unavailable who are not normally interested in payloads but can provide broader context, when they are called for. He prefers pragmatic solutions to discussions of architecture, but occasionally the architects are right. Bill ver Steeg : we must be able to call in experts when discussing obscure payload types. Keith Drage: Currently we don't really act as a WG in the way we handle payloads, in many respects. In the list discussion which should follow up this topic, should focus on the skills you need to assemble rather than simply saying this should be in a Working Group. Need to understand what you get from a WG that you don't get from a group of expert reviewers. Ingemar Johansson: 10-15 people are the major contributors on the list. Stephan Wenger: disagrees with Keith. Real problem is that payload contributors are drop-in, do their work, disappear. Need continuity, need to retain old hands. Robert Sparks: what would cause the experts to disappear? Stephan Wenger: people interested in the protocol (such as Stephan himself) are not interested in picky payload issues. If you segregate the stuff that is uninteresting to these people, they won't show Robert Sparks: What says that these people are available with the present structure? Jabber: Dave Oran : What you get from doing payload types in the AVT WG is a deep understanding of RTP. It is as dangerous to do payload types without an understanding of RTP as to not have an understanding of the codec. 13:30 Rapid Synchronization with RTP Multicast Sessions ======================================================= Base RAMS draft --------------- Ali Begen , charts at http://www.ietf.org/proceedings/10mar/slides/avt-2.pdf. The authors have noted the objection on the list to the IPR declarations. No alternative proposals for solution. They ask the Chair for guidance. Keith asked if anyone else objected. He explained the procedures associated with IPR. By show of hands, the sense of the room was that we proceed with the work as it is. This will be confirmed on the list. After presentation: Roni: reporting on Magnus's comments -- appear to be editorial. Ali: one more version, then WGLC. Agreed, need to move port mapping along. Jabber: Colin Perkins agreed there are no show stoppers, but with Magnus he questions the use of SSRC in RTP session management. Keith confirmed that WGLC would be reissued after the latest update. People having further comments should get them in before that happens. RTCP Port for SSM Sessions -------------------------- Ali Begen, charts at http://www.ietf.org/proceedings/10mar/slides/avt-3.pdf. Issue raised by Magnus, SSM (RFC 5760) requires multicast RTCP port to be derived from RTP port on m= line. Proposes new attribute to specify RTCP port. Joerg Ott remarked that issue would have been addressed more simply if it had been noticed before SSM was finished, by focussing on the RTCP receiver rather than sender. Ali had misunderstood some aspects of the SSM document. Roni urged him to make the motivation clear in this draft so that others would not have the same misunderstanding. Question: make attribute mandatory for RAMS? Update RFC 5760? Tom van Caenagem -- make more general -- unicast too. Magnus: make it applicable for multicast, not specifically SSM. Chair: room seems to accept need for work. Need to negotiate milestone with ADs. Robert: still concerned that generalization creates new signalling protocol for initiating and controlling sessions, wants to make sure we don't duplicate existing capability. (Comment was really about the port mapping draft, next agenda item). 14:00 Port Mapping Between Unicast and Multicast RTP Sessions ============================================================= draft-ietf-avt-ports-for-ucast-mcast-rtp-00 ------------------------------------------- Ali Begen, charts at http://www.ietf.org/proceedings/10mar/slides/avt-9.pdf. Breakout session the previous day. Cullen Jennings took notes (sent out to list). Magnus Westerlund : need also to consider how to do retransmission, but that should probably be a separate specification. Basically clarifying behaviour that should have been in the retransmission or the SSM RFC. Roni recalled that the whole effort started because the SSM document mentions the possibility of a unicast retransmission scheme, but does not say how to do it. Magnus: there actually needs to be some glue between the retransmission RFC, the SSM RFC, and the port mapping draft to define the usage for NACKs. Ali: finish the port mapping work, then consider how to package the information. Tom van Caenagem : the information required is already in the RAMS draft, since the whole basis of that draft is usage of retransmission for the initial burst. Magnus countered that we are actually looking at retransmission in two different functional blocks, and the second one (retransmission of packets already sent) is underspecified. Keith (Chair): we need to quantify the impact on the document itself. Magnus thinks a separate "glue" document would be the better way to go. If done in the RAMS draft, a very clear separation between the two functional blocks would be required. Roni noted that we had already started to separate material from the RAMS draft because it was felt to be more general in scope. Ingemar Johansson noted that parallel activities to provide missing glue are taking place in the Open IPTP Forum and DVB. Roni noted that we were trying to expedite this work so these other organizations could use it. Tom van Caenagem repeated his point, that the other organizations had already described how to do retransmission three years ago, before work on fast channel change was started. He still feels that the RAMS draft supplies all the information necessary. Ali Begen replied that people wouldn't know to look in the RAMS draft for that information. Tom repeated what he had suggested earlier, that the draft name should be changed to make it clearer. Keith (Chair): this is a packaging issue, best resolved in offline discussion. Reverting to technical discussion: Ali raised the question of whether there were any objections to requiring support of RTP/RTCP multiplexing as shown in the slides. There appeared to be no objection and Keith as Chair saw that as consensus. Port Mapping -- Alternative Solution ------------------------------------ Tom van Caenagem, charts at http://www.ietf.org/proceedings/10mar/slides/avt-10.pdf. The proposed solution is specialized, makes certain assumptions about NAT behaviour. Cullen Jennings noted that it does not work for the most common NAPT behavior, which according to security people is regarded as the most secure. Ali Begen summed up: Agreement around the approach proposed earlier, restructure the documents when the technical work is done. 14:20 MPEG2-TS Preamble ======================= draft-begen-avt-rtp-mpeg2ts-preamble-04 draft-xia-avt-mpeg2ts-preamble-02 Tom van Caenagem presented both drafts. Charts at http://www.ietf.org/proceedings/10mar/slides/avt-8/avt-8.htm. Jonathan Lennox : can receiver distinguish between packets subject to preamble and others? Roni Even: yes, provision for that in MPEG-2. Bill ver Steeg : is syntax of Xia output valid for any decoder? (Ali) Can it be handled by third-party set top boxes. Cisco interoperates with nine vendors. Frank Xia : answer is yes. Cullen speaking for Colin Perkins: does the draft always produce a valid MPEG-2 TS or does it depend on the details of the preamble? Roni Even: agreed that post-processing is needed within some boxes, but the output is compliant to the MPEG2-TS reference model. Bill ver Steeg: are the bits on the wire recognizable as valid MPEG- 2 TS packets? Stephan Wenger : probably no one complies totally. Quite likely that the standard itself is ambiguous with respect to compliance. The practical test is what the analyzers and chips on the market do. Since both proposals claim interoperability in their own environments that is probably all you can ask. Frank Xia: can demonstrate bit stream compliance. Eric Friedrich (Jabber): is PCR found in the preamble? Roni Even: this discussion not to the point. The point is the packaging discussion. Stephan Wenger: looking at the way forward, it is wrong to have group decide now. Could live with both, or have a shoot-out (interop test). Don't try to decide here and now. Keith (Chair): is the sense of the room that we work for one document, or that we go with both solutions or neither. Roni Even: need data. Stephan Wenger: strongly supports deferring the decision. Likely to have two solutions in reality even though IETF chose one. Put the question off. Keith: continue in next session. ===================================================================== AVT Session 2 California D 1510-1610 Thursday March 25, 2010. Roni Even and Keith Drage chairing. Note taker Tom Taylor . Audio archive at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77- ch4-thur-afnoon2.mp3 1. Introduction and status ========================== "Note Well" notice was presented. MPGE2-TS Preamble ----------------- Keith Drage as Chair said that we were looking for direction, not technical discussion at this point. There are two different solutions proposed. (1) Should the Working Group attempt to choose one, or (2) should the Working Group accept that both solutions exist. By show of hands: one solution, 11; two solutions, 14. The Chair ruled that there is no clear direction, and resolution of the matter is deferred to the list. 2. Keep-alive Mechanism for RTP =============================== Xavier Marjou , charts at http://www.ietf.org/proceedings/10mar/slides/avt-5.pdf. [The charts review comments received from the IESG. "Discusses" have to be resolved before the document can advance, while "Comments" are suggestions which should be accounted for unless there is a good reason not to do so. These are not distinguished in the charts, although most of the issues are "Discusses".] Comment 1 (as shown in the slide title) --------- Xavier Marjou's proposal is to document the concerns with the suggested fallback solution. Robert Sparks indicated that this would not be enough to resolve his Discuss. Xavier pointed to the next slide for that resolution. Comment 2 --------- The proposed resolution is to remove the recommendation for a fallback solution. Robert Sparks accepted this proposal. Robert's key point is that sending an unknown payload type violates RFC 3264 (Offer/Answer). Roni Even commented that it does not violate RFC 3550, which says that receivers must ignore unknown payload types. Robert countered that receiving unknown payload types definitely causes problems in some implementations. His analogy is for a driver training school to tell its students to ignore red lights because other drivers have the duty of ensuring that the intersection is clear before they drive through it. It is OK to document the unknown payload type alternative with the applicable warnings, in case someone wants to use it in a controlled context where it will not cause damage, but it is wrong to recommend it. To do so would introduce brittleness and, in any event, intermediate nodes are likely to drop the packets concerned. (Counter- argument here that by that point the NAT would have been passed and the packets would have done their job.) Cullen Jennings said it might be good to have a fallback mechanism if the Working Group wants to consider the matter further, but using an unknown payload type is not the right answer. He mentioned the possibility of a static payload type. Roni Even noted that the payload type had to match the medium (audio or video) of the stream concerned. Keith Drage summed up: the proposal to remove the recommendation while retaining documentation of the alternative and associated drawbacks is accepted. The author should send a text proposal to the list and we would go on from there. Comment 3 --------- The usefulness of the a=rtp-keepalive attribute was questioned. No one cared to comment, so this must be resolved on the list. Comment 4 --------- Does RTCP have to be added to the scope? Jonathan Lennox commented that RTCP is self- sustaining. Given that RTP/RTCP multiplexing is the recommended solution, no further discussion is really needed. Stephan Wenger suggested that a sentence be added in the introduction making this point. Magnus Westerlund agreed that RTCP is normally OK. However, the operation of RTCP is subject to important configuration considerations. Symmetry between the peers is required. (Comment 5 skipped) Comment 6 --------- Xavier suggested that the whole of section 6 of the draft could be eliminated now that we have decided not to recommend a fallback method. Roni Even disagreed. He suggested that all that was necessary was to remove section 6.1 and the sentence in section 6 preceding that sub-section. The rest of section 6 is useful. Cullen Jennings agreed that since T140 is the only example of the problem described, the proposal is acceptable. Comment 7 --------- This is the issue of the keepalive timer value, and the observation that it depends on the transport being used. Stephan Wenger suggested that the document recommend a UDP timer and say that timers suitable to other transports are for further study. Cullen Jenning proposed a table for all transports. Roni noted that the BEHAVE Working Group could supply the values. Robert Sparks commented that since the recommended approach is to use RTP/RTCP multiplexing, the timer interval will equal the RTCP interval in any event. Keith Drage again summed up: a change to the document is needed in any event, get agreement on the right one and send a text proposal to the list. Comment 8 --------- The reference to ICE agents was found to be cryptic. Robert Sparks noted that this was a suggestion (Comment) rather than a Discuss, but a reasonable point. The comment asks for a few more words so the outside reader understands what is meant by the phrase: "ICE agent". Comment 9 --------- The question is whether RTSP deserves specific mention. Roni Even noted that the issue is unidirectionality -- the server is send-only. It was agreed that RTP/RTCP multiplexing still works in this case. Comment 10 ---------- The existence of codecs sending comfort noise so rarely that the NAT binding would time out was questioned. It was agreed that a more likely cause would be use of the mute button at one end. The bullet concerned will be updated to use this example. Comment 11 ---------- Agreed that REQ-9 will be removed. Comment 12 ---------- No one had a comment on the proposed resolution. The author is to send a text proposal to the list for review. 3. RTCP Receiver Report for Feedback Storm Suppression ====================================================== Authors absent, not presented or discussed. Charts at http://www.ietf.org/proceedings/10mar/slides/avt-4.pdf. 4. Support for multiple clock rates in an RTP session ===================================================== Marc Petit-Huguenin , charts at http://www.ietf.org/proceedings/10mar/slides/avt-6.pdf. Three approachs are currently used to handle codecs with multiple clock rates. The choice of approach has consequences for synchronization, jitter calaculation, and interpretation of the calculated jitter. When using RTCP, the proposal is to make the use of different SSRCs for the different clock rates mandatory. One question that arises is whether you can reuse the same SSRC for a given clock rate when reverting to it. Packets may still be in flight from the earlier usage, so confusion could be possible as a result. When not using RTCP, it is easier to implement non-monotonic timestamps. The charts record a number of additional proposals to flesh out the solution. Marc asked if this could be adopted as a Working Group work item. Keith Drage asked if this is a real problem, and what priority it should have. Ali Begen indicated his support for the work. Roni Even stated that it was not a new problem, and that requiring the use of different SSRCs for the different clock rates was a good direction. 5. Proxy Rapid Acquisition of Multicast RTP Sessions ==================================================== Jinwei Xia , charts at http://www.ietf.org/proceedings/10mar/slides/avt-7.pdf. Roni Even added after the presentation of the charts that the authors think that the draft is clearer than the previous version. The key to the solution is collocation of the proxy with the near-side router. Bill ver Steeg < asked what changes in the network to enable the use of a proxy rather than implementation guidelines. Jinwei responded. Cullen Jennings stated that he was not yet convinced this was a good idea. He suspects the existence of significant security issues needing system modifications to include the middlebox in the security context. This contradicts the intention to avoid the need to modify clients. == 30 ==