AVT met Monday morning, 09:00-11:30, and Friday, 14:15-15:15. Chairs were Roni Even and Tom Taylor. Thanks to Bill ver Steeg, Colin Perkins, and Brian Rosen for your meeting notes. 1. Agenda and Note Well ==================== See http://www.ietf.org/proceedings/75/agenda/avt.html. The agenda was accepted as proposed, except for a note by Colin Perkins that the authors of the ECN-related documents agreed on a single common presentation on Friday afternoon. 2. Status ====== Roni Even reported. See http://www.ietf.org/proceedings/75/slides/avt-0.pdf. It was noted that a queue of drafts is building up behind draft-ietf-avt-rtcpssm, which awaits an editorial update. Colin Perkins said that Joerg Ott had promised that the update would be provided shortly. Tom Taylor explained that he had mistakenly failed to copy the list when calling a halt to the debate over max-send-level in the 3984bis draft for lack of consensus. Actually the debate had continued behind the scenes, but Ye-Kui and Randell finally came to an agreement and updated text should be available shortly. We will have a second short WGLC on the revised text, then 3984bis and the SVC draft can proceed to the IESG. The authors feel that draft-ietf-avt-rtp-gsm-hr will be ready for WGLC after another iteration. 3. Rapid Acquisition for Multicast RTP Sessions ============================================ draft-ietf-avt-rapid-acquisition-for-rtp-01. Bill ver Steeg reported. See http://www.ietf.org/proceedings/75/slides/avt-1.pdf. The presentation listed a number of open issues. The one issue discussed in the meeting was the question Ye-Kui Wang raised on the list, about why the Min RAMS Buffer Fill Requirement AVP is needed in the RAMS Request message. Bill's reply was that the sender needs this information to know the minimum fill the receiver requires in its jitter buffer. (Or the receiver may have other buffer requirements.) Ye-Kui commented that this AVP might force the Retransmission Server to select an earlier I-frame start point for the beginning of the retransmitted burst, rather than the most recent one. Ali Begen expanded on Bill's answer, saying that there are lots of reasons why the receiver needs an increased buffer fill. The server will have to decide on the right starting point depending on the requirements indicated by the receiver. The server might even decide it is faster to wait for the next I-frame rather than go back. Roni Even commented that the draft should discuss the issues that clients may have in setting the value of the Min RAMS Buffer Fill Requirement AVP. The remaining open issues were referred to the list. 4. Port Mapping for Retransmission =============================== No draft. Roni Even reported. See http://www.ietf.org/proceedings/75/slides/avt-2.pdf. This issue came up in the work on rapid acquisition of multicast streams, but also applies to small-group multicast as described by RFC 4588. The basic problem is that declarative SDP (as opposed to offer-answer) does not allow the receiver of a unicast stream such as a retransmission stream within a multicast session to specify the transport address to which the stream should be sent. Comments on the Problem Summary slide: Dave Oran commented that the operation should be atomic to avoid the need for correlation of exchanged messages. Moreover, the mechanism has to finish before the retransmission starts, but not too early or we have NAT bindings expire, or maintain too much state at the sender (at worst, state for each receiver in a large multicast group). Colin Perkins had an architectural concern with the transmission of transport addresses in RTCP. The alternative is perhaps to use STUN. Dave Oran pointed out that there is an atomicity issue with synchronization of STUN with the RTCP/RTP exchange. Moreover STUN has its own architectural issues, since it is designed for a stateless server and the retransmission server is stateful. Finally, whatever the solution, we must guard against reflection attacks. It was agreed that the IP address to which the flow should be directed would always be that from which the RTCP FB or NACK message originated. However, the port would be different in general. It was agreed that off-line discussion was needed. A meeting was arranged over the lunch hour on Tuesday. The report of the outcome of that meeting was presented on Friday afternoon (see below). 5. Synchronized Playback in RAMS ============================= draft-yang-avt-rtp-synced-playback-00. Peilin Yang presented. See http://www.ietf.org/proceedings/75/slides/avt-3.pdf. Bill ver Steeg reported that Cisco is filing IPR statements in this area. Ali Begen wondered how the server could set N and V, given that there are other sources of delay such as jitter that are specific to the receiver. He also pointed out that frame skipping does not account for the audio portion of the media transmission. Ashok Narayanan <> noted that speeding up and slowing down video will introduce artifacts. Dave Oran and Colin Perkins made the point that synchronized playback to multiple receivers is a general problem, and a very difficult one. Ye-Kui countered that at least one component of delay could be removed by this technique. He cited work on delay reduction ongoing in TISPAN, involving real-time measurement of delay. Dave Oran asked on what scale: 2 receivers or 200,000? It would appear the work is closer to 2. Dave suggested the problem could be larger in some network situations. There was a comment that other methods were available for adjusting timing, each with its own quality issues. One part of the difficulty of the general problem is that delay across the Internet is variable. Roni's summation was that there have been lots of comments to address, especially the factor of changing delay on the Internet. The problem is interesting, but the solution presented may not be appropriate. 6. Improved Rapid Acquisition of Multicast Sessions ================================================ draft-wang-avt-rtp-improved-rams-00. Ye-Kui Wang presented. See http://www.ietf.org/proceedings/75/slides/avt-4.pdf. Bill ver Steeg wondered if this was intended to be a new normative specification or implementation guidelines for the existing draft. Ali Begen suggested it was up to the receiver to choose the right time to join the multicast session. Colin Perkins was concerned that this might be over-specifying receiver behaviour. Ye-Kui responded that we have to be sure to specify behaviour adequately. Further discussion focussed on the assumption that the bottleneck link was adjacent to the receiver (hence the receiver knows the bandwidth available). Ye-Kui suggested this was a reasonable assumption in the the case of a home network, where devices know the guaranteed bandwidth from the service provider and can be aware of bandwidth consumption by other devices in the home. Colin Perkins countered that devices must always be aware of congestion and loss and be prepared to back off. 7. Multicast Acquisition Report Block Type for RTCP XR =================================================== draft-begen-avt-rapid-sync-rtcp-xr-01. Ali Begen presented. See http://www.ietf.org/proceedings/75/slides/avt-5.pdf. Bill ver Steeg noted the need, here and elsewhere, to deal with extended sequence numbers. 8. Audio Level Indicators in RTP Streams ===================================== Combined presentation of draft-ivov-avt-slic-00 and draft-lennox-avt-rtp-audio-level-exthdr-00. Enrico Marocco presented. See http://www.ietf.org/proceedings/75/slides/avt-6.pdf. The problem statement, draft-ivov-avt-slic-00, was worked up on the DISPATCH list. The problem was referred to AVT after a solution approach was selected. There are actually two related problems. draft-ivov-avt-slic-00 is concerned with getting audio levels from a mixer to a receiver. draft-lennox-avt-rtp-audio-level-exthdr-00 is concerned with getting audio levels from a sender to a mixer. Jeffrey Goldberg <> suggested additional metadata besides audio volume (e.g. position, Dolby) might be interesting. Jonathan Lennox replied that this could be the subject of another header extension draft. Francois Audet could see the reasoning for in-band transport of the indicators from the mixer to the receiver, but was concerned that in-band transport from the senders would involve a lot of code and drive up client cost. Enrico cited the need rapid responsiveness to changing speaker conditions. Roni Even expressed a concern about packet congestion, and Francois was concerned over compatibility with existing terminals. Gunnar Hellstrom saw a possible use case for text conferencing (e.g. using RFC 4103), where the information presented would be the source of a particular text message. Dave Oran had a thought: perhaps send comfort noise payload with the same timestamp as the primary packets. [Not clear if this was related to Gunnar's use case.] Jonathan Lennox suggested that RED (RFC 2198) would be less heavyweight. 9. SRTP Store-and-Forward ====================== draft-mattsson-srtp-store-and-forward-03 and draft-naslund-srtp-saf-02. John Mattsson presented. See http://www.ietf.org/proceedings/75/slides/avt-7.pdf. Cullen Jennings asked what has changed since the last meeting. Were the objections raised in that meeting addressed? The answer was that the usage of CCI and CID has changed. Richard Barnes asked if CCI and CID are protected. John said they were not -- they were like MKI in SRTP. Roni noted a list comment. Dan Wing could not be present because of a collision with BEHAVE, but felt that the solution was complicated both on the client and on the server. John said it wasn't really -- they had implemented it in two days. Randell Jesup commented offline that the RTCP part wasn't mentioned in the draft. RTCP is needed in some cases to sort out data misordering. John stated that the middlebox has to store the relevant part of the RTCP. The RTCP does not need protection. Cullen asked how many had read the draft. A few had done so. Given that most people who needed to comment were absent, further discussion was deferred to the list. =========================================================================== =========================================================================== Friday presentations. Thanks to Dave Oran for the notes. 1. Agenda and Note Well ==================== Roni Even opened the meeting. See http://www.ietf.org/proceedings/75/slides/avt-8.pdf. A report from Tuesday's port mapping breakout session was added as the last item on the agenda. 2. ECN for RTP over UDP/IP ======================= draft-westerlund-avt-ecn-for-rtp-00.txt draft-carlberg-avt-rtp-ecn-02.txt draft-carlberg-avt-rtcp-xr-ecn-01.txt Piers O'Hanlon presented. See http://www.ietf.org/proceedings/75/slides/avt-11.pdf. Chart 2: ECN is actually quite useful to realtime flow - can adapt before loss occurs. (TCP can retransmit.) Most RTP flows today do not adapt to loss - using loss as a signal can be too late to recover before playout deadline expires. Chart 3: Newer codecs can do rate adaptation. ECN allows really congestion response and better user experience (but this draft does not specify the sender's reaction to feedback). Chart 4: ECN-for-TCP tutorial. Chart 5: Extension to UDP seems straightforward: - Signal ECN using SDP offer/answer - set ECT on RTP data packets - send feedback on RTCP RRs (no portable way to monitor receiver ECN marks on UDP). Chart 6: Actually not quite that simple - need to tell if media path supports ECN - can't do this on signaling path - current AVPF is slow - many RTTs. - frequent rate changes are not good for user experience. Unlikely it will be strictly TCP-friendly. Charts 7-8: - RTP has mixers and translators - explicit middle-boxes - mixers are the easy case since they are endpoints. - multicast complicates picture. Basic message: ECN capability varies across receivers and along paths. Chart 9: Here is a proposal. Four components - negotiate with SDP offer/answer - verification of the media path capability to ECN - feedback - error control, fallback. - broken middle boxes can drop/remark packets - need to probe the path. Two ways. 1. use ICE & STUN (details to be sorted out) 2. treat ICE as optimization, but do RTP-native probe. Bob Briscoe : may have an alternative for how to do the data path operations. One can simplify by only doing data plane probing - no need for negotiation. Colin Perkins: reason to have the negotiation is to avoid problems with boxes not prepared to receive RTCP packets they don't understand. Chart 9 (cont'd) - need to monitor in case path fails - can do receiver-only adaptation, but much better to always send feedback. Complications: - translators that don't change the media are easy - it's the ones that split/join you need to be careful about - media transcoders are harder - need to separate the legs. The authors suggested that this be joint work with TSVAREA, but adopt it as an AVT work item. They were instructed to submit a joint draft. The chairs will discuss how and if to add a WG charter item for this work. 3. RTP Payload Format for MPEG2-TS Preamble ======================================== draft-begen-avt-rtp-mpeg2ts-preamble-01 Ali Begen presented. See http://www.ietf.org/proceedings/75/slides/avt-9.pdf. The proposed payload format carries MPEG2-TS (transport stream) stuff, but not what RFC2250 does. Question: are the parts in this payload scattered in the transport stream? Answer: yes. The encoder locks onto the "TSRAP" (Transport stream random access point). - extracts the needed pieces from the TS, and sends them in RTP. - encodes via TLVs like in RAMS: examples - PAT, PMT, PCR, SEQ, ECM, EMM. Question: how does the canonical order for feeding to the decoder interact with the encoding order in the payload packets? Question: do we really need vendor extensibility? Answer: yes. 4.Multicast/Unicast Port Mapping Proposal ======================================= No draft. Roni Even presented. See http://www.ietf.org/proceedings/75/slides/avt-10.pdf. Tuesday's breakout session discussed how to deal with the port assignment problem. They came up with a strawman proposal which the group believes solves the problem: - do a two-phase operation - first phase to get port information to the server, server turns this into a cookie and replies to the client. This can be done in advance, doesn't store server state, and avoids reflection attacks. - at the time you need to do the real transaction (e.g. NAK, RAMS), send the cookie by which the server can figure out the ports to use for the outbound packets (both RTP and RTCP). Next step is to prepare a draft based on this. Do we need a charter change? do we need a milestone? Does WG think it's suitable? Hum taken - no hums against, some hums in favor.