IETF76 Minutes for AVT ====================== Chairs: Roni Even and Tom Taylor . Note takers (with much thanks): Ingemar Johansson , Xavier Marjou , and Enrico Marocco . The AVT Working Group met twice: on Monday November 9, 13:00-15:00, and Wednesday November 11, 15:10-16:10. In addition, there was an informal meeting Tuesday afternoon, 16:00-18:00, to discuss the two drafts relating to payload type for the MPEG-2 Transport Stream preamble. The topics dealt with on Monday were as follows: - Working Group status report - Rapid Synchronization with RTP Multicast Sessions, draft-ietf-avt-rapid-acquisition-for-rtp-04 - Considerations for RAMS Scenarios, draft-begen-avt-rams-scenarios-00 - Synchronized Playback in RAMS, draft-yang-avt-rtp-synced-playback-02 - Improved Rapid Acquisition of Multicast Sessions, draft-wang-avt-rtp-improved-rams-01 - RTP Payload Format for MPEG2-TS Preamble, draft-begen-avt-rtp-mpeg2ts-preamble-03 - Preamble Acquisition of MPEG-TS Multicast Sessions, draft-yang-avt-rtp-synced-playback-02 - Multicast Acquisition Report Block Type for RTCP XR, draft-begen-avt-rapid-sync-rtcp-xr-03 - Network-based Rapid Acquisition of Multicast RTP Sessions, draft-xia-avt-proxy-rapid-acquisition-00 - Encrypted Key Transport for Secure RTP, draft-mcgrew-srtp-ekt-06 - Guidelines for the use of VBR Audio with Secure RTP, draft-perkins-avt-srtp-vbr-audio-02 The topics dealt with on Wednesday were: - RTP Extension Headers for Audio Level Indicators, draft-ivov-avt-slic-02 and draft-lennox-avt-rtp-audio-level-exthdr-01 - Port Mapping Between Ucast/Mcast RTP Streams, draft-begen-avt-ports-for-ucast-mcast-rtp-01 - ECN for RTP over UDP/IP, draft-westerlund-avt-ecn-for-rtp-02.txt. AVT Monday November 9, 13:00-15:00 ================================== Chairs' report on Working Group Status -------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-9.pdf. Chair (Roni Even): reports the current status of the different drafts related to the WG. Three new RFCs: RFC5686 (draft-ietf-avt-uemclip), RFC 5691 (draft-ietf-avt-rtp-mps), RFC 5584 (rtp-atrac-family). Draft-ietf-avt-rtp-and-rtcp-mux and draft-ietf-avt-dtls-srtp are in RFC editor queue. Draft-ietf-avt-app-rtp-keepalive raised comments from IESG meeting: author will give more feedback at the next meeting this week. Chairs also indicate the existence of a draft on XR Discard metrics (draft-ott-avt-rtcp-xt-discard-metrics-01.txt) and ask feedback about it. Rapid Synchronization with RTP Multicast Sessions, draft-ietf-avt-rapid-acquisition-for-rtp-04 -------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-0.pdf. Presenter was Ali Begen . Ali Begen: the current draft solves all the open-issues encountered so far. Presents the major changes since last version. Two remaining issues (port mapping and concurrent acquisition of multiple RTP streams) will be handled in two other drafts referenced in this draft so that this draft can quickly progress. Chair (Roni): we want people to read the draft and give comments so that it can become a WGLC. Colin Perkins : concerned about the other two drafts that may impact this draft. Might this draft have to change? Stephan Wenger : I agree with Colin and propose to set this draft as an experimental status. Colin Perkins: I do not agree on the experimental status. Chair (Roni): We can wait to see how the rest of the week goes before deciding whether we are ready for WGLC. The draft need reviewers. Considerations for RAMS Scenarios, draft-begen-avt-rams-scenarios-00 ---------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-1.pdf. Ali Begen presented. Ali Begen: customers have deployment questions. This draft intends to cover and describes different cases. Example of topics: "multiple SSRC-muxed RTP streams". The draft will give examples and provide recommendations. Intended status is Informational. Example of problem: RAMS payload dependent on clock rate info. Some slides present some SDP examples. There are also considerations about the feedback target and SSRC Signaling issues. Colin Perkins: everything works, but the solution would be cleaner if you didn't share the feedback target. Jörg Ott : Why are extra multicast addresses a problem? Ali: service providers don't want the extra administrative work, and there may be limits on multicasting capabilities at the DSLAMs. Joerg not sure they understand how simple this is. Will be adding headaches without real technical gains. Xavier Marjou: this type of details is discussed at least in his company; such a draft is interesting in order to describe the overall big picture. Colin Perkins: absolutely no problem with the idea of an explanatory document. Does not think this is technically needed, and need to explore whether it addresses a real problem in deployment. May be a matter of educating the service providers. If there is a real problem, should document that. Chair (Roni): expanded on these points. Chair (Roni): The draft needs more discussion on the mailing list. Need to work out which are priority scenarios. Colin Perkins expressed his support for the general purpose of the draft. Synchronized Playback in RAMS, draft-yang-avt-rtp-synced-playback-02 ------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-2.pdf. Peilin Yang presented. Peilin Yang: RAMS mechanism adds delay, but there are also additional delays (end-to-end transmission, receiving buffer delay, decoding buffer delay….). Different receivers will have different delay due to different offsets caused by Rapid Acquisition of Multicast RTP Session. The draft proposes to speed up the delivery by skipping some frames then to play back normally to reduce the inter-user playback delay. Ali Begen: does not see feedback on issues raised during last session, for example for skipping audio frames. Roni Even: This was just mentioned by Peilin [while presenting the slide entitled "The value N and V"] when he presented the N and V values and audio distortion. Ali Begen: we can not touch audio in the buffer Jörg Ott: many interesting and important parts of the draft are still empty, thus no feedback can be done now. Colin Perkins: What seems to be described is decisions taken at the receiver -- out of scope of the IETF. Stephan Wenger: seem to be mixing up deployed network concerns with matters that won't be relevant for a couple of years. Chair (Roni): wants to see a discussion about "is it a problem to be solved?". Ali Begen: "Yes, but cannot be solved" (receiver dependent). Chair (Roni): "Given all the end-to-end overall delay, difficult communication between the processes. Indicate what we can or cannot do (big picture) before going further". Jörg Ott: Believes that it would be good to have the ability to have multiple boxes in the same room tuned to the same program playing the same thing at the same time. He does not believe that the problem here is with the initial start-up delay. Should tackle the general problem first, then as a second step see how the results get influenced by start-up delay. Colin Perkins: same opinion as Jörg. Improved Rapid Acquisition of Multicast Sessions, draft-wang-avt-rtp-improved-rams-01 ------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-10.pdf. Zi-Xuan Zou presented. Zi-Xuan Zou: presents RAMS problems like what happen when RAMS-I message with join time is lost. The proposal is a more robust mechanism by adding an optional TLV element called "unicast backspace" in RAMS-I message, which gives the RTP timestamp difference between the first unicast burst packet to be sent and the latest primary multicast packet primary multicast packet in the RS. Zi-Xuan illustrates it with an example of message flows. Ali Begen: it might work but the server knows what to do, it's up to the server to manage RAMS, so the client depends on the server. Sooner or later the client will need information from the server. If first RAMS-I is lost, everything is lost anyway. RAMS-I can be sent multiple times, so not convinced this draft is needed. Zi-Xuan Zou: RAMS-I retransmissions increase the burden on the RS. Ali Begen: this is true, but won't happen all the time. Ali Begen: in the RAMS draft the server gives the exact time so no need for this draft. Chair (Roni): the new draft should try to summarize the use-cases. RTP Payload Format for MPEG2-TS Preamble, draft-begen-avt-rtp-mpeg2ts-preamble-03 ----------------------------------------- Chair (Roni) announced that there would be an informal session Tuesday afternoon to discuss this and the next draft. Right now there should just be presentation and clarifications. Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-3.pdf. Ali Begen presented. Ali: There's a lot of info in mpeg2ts stream. So there's a need for a preamble to process and decode incoming mpeg-ts stream efficiently and reduce waiting time. This draft proposes a payload for it. Ali presents the modifications since last meeting. TLOV replaces TLV, where O is added for indicated the order for the processing of the receiver. Roni Even: is the output from the RS is customized per client, taking account of individual client characteristics? Ali Begen: it would be possible to program the RS to do this, but not scalable. Hence the preferred approach is to add code to the RTP implementation on the receiving side to post-process the packaged preamble. Peilin Yang: would the receiver be able to detect the loss of the packet containing the preamble data, if only one packet is used? Ali Begen: it could tell that it had not received a preamble. The packaged preamble provides further acceleration on top of the burst, so if it is lost, the necessary information is still recoverable from the burst but additional delay is incurred. Preamble Acquisition of MPEG-TS Multicast Sessions, draft-yang-avt-rtp-synced-playback-02 --------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-4.pdf. Peilin Yang presented. Peilin Yang: presents another draft and compares it with Ali's previous one. Indicates his draft is simpler because there is no need for post-processing. Discussions about the misuse of RFC4588 and how OSN is set. Ali Begen: I believe MPEG-TS preamble is still not a retransmission solution. Main point: "In the example, SN starts 2000 but when you use OSN as 99 this is incorrect. 99 implies a brand-new preamble packet". Ali Begen second comment: presentation shows one TS preamble packet, but there may be a bunch of them. This has to be taken into account. Colin Perkins: this one doesn't work and Ali's does. It seems like a simple decision here. Chair (Roni): does not want to jump in technical solution because of time. Everyone interested with this work, please come tomorrow to discuss it. Multicast Acquisition Report Block Type for RTCP XR, draft-begen-avt-rapid-sync-rtcp-xr-03 ---------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-5.pdf. Presented by Ali Begen. Ali Begen: varying join delays affect the acquisition delay as well. In order to report the delay, the proposal is to define a new RTCP XR report that is called Multicast Acquisition (MA) Report Block. Modifications since last meeting: addition of two MA methods: one for simple join, one for RAMS. Vendor neutral codes must be registered with IANA. Same TLV elements as used in RAMS draft. Example of vendor-neutral extensions (ex: joint time latency). SDP signaling is pretty simple. The draft is complete. WG adoption or should it be AD-sponsored individual adoption? Chair (Roni): will be discussed with Area Director. Ali mentioned that they have already implemented it and it is being used by customers. Network-based Rapid Acquisition of Multicast RTP Sessions, draft-xia-avt-proxy-rapid-acquisition-00 ---------------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-6.pdf. Qin Wu presented. Qin: motivations for this draft are: difficulty to update legacy RR (STB) to support rapid acquisition, additional complexity on RR, signaling messages consume too many radio resources in radio networks. The proposed solution is to introduce a Proxy to perform the Rapid Acquisition on behalf of the STB. This network based solution is called PRAMS (Proxy RAMS). A RAMS is performed by the proxy upon receipt of an IGMP Join from the RTP Receiver. Colin Perkins: how is the proxy included in the signaling context, how does the proxy receive the SDP description? Jinwei Xia: IMS. Colin: not all RTP sessions use IMS. Colin: there is nothing describing the signaling context in this draft. Ali Begen: same kind of question. Colin: other question: how session quality feedback works in this context with such an intermediary? This breaks the end-to-end concept. He struggles with the motivation of this draft. The whole point of RAMS is backward compatibility. This adds a lot of signalling complexity to protect the receiver. Should we do this work at all? Chair (Roni): Proxy a good idea in general to take load off the network. Colin: yes, but in this case it means more messages on the network. Ali Begen: Cisco will be declaring IPR on this draft. Encrypted Key Transport for Secure RTP, draft-mcgrew-srtp-ekt-06 --------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-7.pdf. Dan Wing presented. Dan Wing: SRTP encrypted key transport (EKT) is intended to provide a protected transport of information like SRTP master keys and rollover counters, to make it possible to use SRTP in cases like a conference with no central control. This version integrates comments received during the last few years as well some feedback from experimentations. EKT is in an SRTP packet, and the same frame contains audio data to avoid synchronization problems when one packet is lost. Colin Perkins: the reason we did not adopt this as a work item before was that we wanted to wait for some progress on this topic in other WGs. It is now mature and should be adopted as a WG item. Chair (Roni): the topic is important. Dan: How many people care about SRTP these days in the IETF? Roni: The IMTC is working on interoperable security profile for video, using SDES in the first phase but looking forward to DTLS. Guidelines for the use of VBR Audio with Secure RTP, draft-perkins-avt-srtp-vbr-audio-02 ---------------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-8.pdf. Colin Perkins presented. Colin: When using variable bit rate audio (VBR audio) with SRTP, it is possible to recognize encrypted voice thanks to voice variations. Article says it's possible with 99% accuracy. There is thus a security risk. Philip Zimmerman's ZRTP draft recommends in his draft to avoid using VBR. Colin says his draft basically recommends the same thing and his question is "should AVT make such a recommendation, if so, is the current draft an appropriate starting point?" Richard Barnes <>: Another alternative may be to fix it within VBR itself to make it constant bit-rate in such cases. Jean Marc Valin <>: all the results of the paper were based on Speex codec, but premature to generalize. In terms of audio and video, he agrees that there is a potential problem. Chair (Roni): Is this part of the "Why is SRTP not mandatory" draft? Colin: separate issue. Roni: we need to be more clear about the risks of VBR. Colin: The feedback is that this is work to be done. AVT Session, Wed Nov 11, 15:10-16:10 ==================================== Agenda bashing, no comments. The result of Tuesday's MPEG-2 TS preamble discussion was reported on the list. Cullen Jennings , our erstwhile Area Director, is handing AVT and MMUSIC over to Robert Sparks . Thank you Cullen for the great job! RTP Extension Headers for Audio Level Indicators, draft-ivov-avt-slic-02 and draft-lennox-avt-rtp-audio-level-exthdr-01 ------------------------------------------------ Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-11.pdf. Emil Ivov presented. Mixer-to-client: draft-ivov-avt-slic-02. Ingemar Johansson: the format on slide 3 may not be correct according to 5285. Emil: yep, sorry, we'll fix the slides :) Client-to-mixer: draft-lennox-avt-rtp-audio-level-exthdr-01. Security issue solved by draft-lennox-avt-srtp-encrypted-extension-headers-00.txt Jörg Ott noted two potential issues: reliance on the client for valid information, and the potential distribution of the header extension in multicast, where it might reach devices that don't understand it. The reliance issue means the mixer always has to check the inputs against the streams it is processing. Emil noted that the draft recommends periodic checking of inputs against the actual media levels. On the multicast issue, Jörg withdrew his concern until he read the draft more closely. Jean Marc Valin : have you considered frequency related scales? Emil: the focus was initially on GUI, we could probably consider something other than dBoV. Roni: so far discussion was about how to convey the info. Michael Knappe < >: dBov is better than dB SPL. There are ways to measure speech level. Emil: post on the list. Christian Hoene : what about stereo mixing? Emil: right now we have only considered visual clues. Roni: Mixer-to-client is interesting? Some hums in favour, no one against. Client-to-mixer? Some hums in favour, no one against. Cullen Jennings: whether to specify in one or two documents boils down to: "Do products always implement both?" The question will be resolved on the list. Port Mapping Between Unicast/Multicast RTP Streams, draft-begen-avt-ports-for-ucast-mcast-rtp-01 -------------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-12.pdf. Ali Begen presented. Xavier Marjou [regarding slide 6]: on what basis do you decide to send back a cookie? Ali: server sends a cookie for every request. Xavier: it does not provide security then. Ali: the slide is confused, too many msgs. Roni Even (as contributor): you can do the cookie once, don't need to keep exchanging. Roni (as Chair): how many read the draft? About 5. Colin Perkins: can you use RAMS without this? Ali: yes. Colin: so this does not need to be a normative reference in the RAMS draft. Roni (as Chair): add more text in the next revision. ECN for RTP over UDP/IP, draft-westerlund-avt-ecn-for-rtp-02.txt --------------------------------------- Presentation at http://www.ietf.org/proceedings/09nov/slides/avt-13.pdf. Colin Perkins presented. Jörg Ott: can you use ECN in ICE to select the candidate? Colin: yes, should document. Bob Briscoe : on slide 6, first option, what happens in case of late joins that don't do ECN? Colin: don't use. Bob Briscoe: if you fix tricks done by bad boxes, you are basically hiding the problem that can result in worse problems. Cullen Jennings: just ignore that particular case, things may always go wrong, you must be ready anyways. Colin: OK, I'll ignore, this was the feedback I was looking for. Colin: would like to adopt the draft in AVT and in parallel review and Last Call in TSVWG. Roni: hum for adoption: strong consensus. -----------------------