AVT Minutes ============ AVT met for two sessions at IETF 74: Monday 1300-1500, and Thursday 1510-1610. Roni Even and Tom Taylor chaired the sessions. Monday 1300-1500 ================ Dave Oran took notes, with some help from Joerg Ott . Jonathan Lennox acted as Jabber scribe. There were 75 attendees at this session. Chair report (Roni Even) ======================== Slides at http://www.ietf.org/proceedings/09mar/slides/avt-0.pdf - Slight change to agenda: moved security issues to Thursday, RTCP-XR moved to today. - NOTE WELL was presented. - Chairs gave document status - see agenda/intro slides for individual document details. Noted that SSM is blocking some key documents. Apparently a production problem -- using Word. In addition to drafts listed, noted that SVC and 3984bis are ready to go to the IESG. - Received a liaison from ITU-T Q18 of WP1/16. Desire is to avoid tandem media processing entities on a bearer path (e.g. echo cancellers). See chair slides for discussion and details. WG is asked to give chairs input (via mailing list) on how to respond. Colin Perkins on Jabber: do we need a joint BoF to discuss requirements? - Need charter update for RTCP extensions. - There is an issue with codec references for media sub-type registration in the standards tree when the codec itself is proprietary but the payload type is defined by an IETF document. Registry rules are unclear. Topic is on agenda for a meeting between the Chairs and ADs Thursday morning. - RFC3016 mainly used by 3GPP, but some misalignments with 3GPP PSS service. draft-schmidt-avt-rfc3016bis-01 provides updates. The authors want it adopted as a WG work item. RTP Payload for IP-MR Speech codec ================================== draft-ietf-avt-rtp-ipmr-02 Roni presented on behalf of the authors Slides at http://www.ietf.org/proceedings/09mar/slides/avt-1.pdf - on-the-fly adaptable wideband speech codec, VBR, etc. - see slides for details of updates from previous version. - Need review to ascertain whether it is ready for last call. No one indicated that they had read the draft. The presenter asked for people to review it. Rapid Synchronization of RTP flows ================================== draft-perkins-avt-rapid-rtp-sync-03 Roni presented on behalf of the authors Slides at http://www.ietf.org/proceedings/09mar/slides/avt-2.pdf - general agreement to change name of the rapid multicast synch work to avoid terminology confusion. This draft will keep the "rapid synch" terminology. - current draft is a merge of draft-perkins... and draft-schierl... - see slides for details on draft technical content and updates since -00. - proposed solution to jitter problem is to use the NTP header extension for all streams in the session - trying to encourage DVB to use this spec instead of rolling their own for TM-AVC. Chairs polled the room as to whether it should be a working group item. Hum agreement it should be - will confirm on mailing list. Ye-Kui Wang noted that "SSM" was spelled out in different ways. It should be "Source-specific multicast". Rapid Synchronization with RTP Multicast Sessions ================================================= (1) draft-versteeg-avt-rapid-synchronization-for-rtp-02 --------------------------------------------------- Presented by Bill Ver Steeg Slides at http://www.ietf.org/proceedings/09mar/slides/avt-3.pdf The drafts presented at IETF 73 were merged into this one. However, there is another draft dealing with this topic (see below). To avoid confusion with the Perkins-Schierl work item it is proposed to rename this draft to "Unicast-based Rapid Acquisition of Multicast RTP Sessions". - See slides for background and enumeration of updates from last version. - Current draft is a merge of -01 and draft=-levin-rtp-burst. They were similar and not a big deal to combine - Went to TLV encoding of the fields. The earlier dependence on MPEG-2 transport stream transport has been removed. Adding capability for vendor-specific fields. Roni Even remarked that there was no text explaining how the TLVs are used and what is the behavior associated with them. Bill Ver Steeg said they would work to clarify the semantics. Dave Oran noted that in most cases these fields are used strictly for optimizations. Roni argued that designers will not implement them if they see no gain from doing so. Authors will continue to consider the matter. - issue around when and whether we can use extended RTP sequence numbers in the control messages. Breakout scheduled for Tuesday 9 am to discuss open issues. Roni: once a it is a WG item we can think about fixing FMT items. Xavier Marjou : was there thought as to whether everything should be in RTP header extensions rather than RTCP messages? He had NAT interference in mind. Dave Oran responded that most of the messaging fits with the AVPF control channel model, but it might be a good idea to piggyback RS->RR control information for burst rate changes. Zeev Vax added that you can derive burst rate from the received data, but the idea of using header extensions is worth considering. Roni observed that we still need to iron out the details of the mechanism. He would try to present the outcome of the breakout session on Thursday so we can get this to be a WG item as soon as possible. (2) draft-peilin-avt-rtp-burst-01 ----------------------------- Ye-Kui Wang presented on behalf of the authors. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-7.pdf. - there may be Huawei IPR on the draft. - General architecture adopts the draft-versteeg... approach - Two new items beyond what is in the other draft -- 1: allows burst rate to be controlled by RR, RS or both together. -- 2: Method to terminate a burst based on initiation of a different burst - See slides and draft for details. Yunfei Zhang : Requirements OK, but (1) not sure how receiver can know what bit rate to provide to the sender, and (2) are these mandatory requirements of the solution? - Roni: clarification of (1) how does the RR know the peak rate it can use? Answer: receiver just tells what it may know. Followup: should IETF be specifying optimal bitrates? YeKui: not looking to optimize. No need for IETF to specify -- situations differ. Roni: look at RFC 3550. Zeev: Burst typically 5-10 seconds. Can't adapt faster than RTT allows. Need stable jitter and loss estimate. Takes longer than time available. Risk of increased overhead without adding value. - Yunfei second question: is it implied that support of rapid channel change is mandatory? No - depends on provider, but question of making system work better. Dave Oran: bear in mind that this is an optimization of an optimization. Second point: if message fails, don't want to worsen subscriber experience. RTCP-XR* Drafts =============== Geoff Hunt presented. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-4.pdf. - There is a large menagerie of these - see slides for a list. Split of drafts due to a "re-architecting" of the XR drafts to separate the individual blocks to be specific rather than packaged together in arbitrary sets. - see slides for changes from prior versions. A Cisco IPR claim affecting -xr-concsec was noted. Al Morton: on PDV block draft, 2 points - (1) would good to reference an RFC on PDV guidance (RFC5481), (2) Naming conventions in this draft no longer correspond to the terms we use in RFC3550 and elsewhere. He would be glad to help nail the names down, particularly before they get put into an IANA registry. There is now general convergence amongst SDOs. Reviews requested. Milestones still have to be firmed up. Cullen understands the logic of creating so many drafts, but suggested we discuss the prioritization of these drafts on the list. RTP payload format for the CELT codec ===================================== draft-valin-celt-rtp-profile-00 Presented by Greg Maxwell Slides at http://www.ietf.org/proceedings/09mar/slides/avt-5.pdf - Presented background of codec characteristics (see slides). On chart 4, Dave Oran what the Y-axis was for the bar chart on the right -- scores from ITU-T methodology. - To solve early media problems - could burn a bunch of payload types (combinatorics kill it) so need to choose some common combinations. - Future work consideration is signaling configuration data, also need to freeze the CELT bit-stream. RTP Payload format for DV (IEC 61834) Video =========================================== draft-ietf-avt-rfc3189bis-02 Roni provided a quick review. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-6.pdf. - Minor changes from last draft (see slides) Need opinions on whether this is ready for WGLC. AVT Thursday Mar 26 =================== Roni and Tom chairing Status ============= Roni Perkins synch In favour of making WG item? No objections Summary from burst breakout session (chart) Revision then go to list to make WG item DTLS-SRTP Key Transport (Dan) ============================= Apologies, material to be uploaded after presentation. Supports interworking with sdescriptions. David McGrew states values to this independently of EKT -- interworking needed ?? can add description of interworking with MIKEY? Yes. Please indicate which variety of MIKEY is of interest. Roni: verify that the call flows work correctly in interworking. Encrypted key transport (EKT) David McGrew ========================================== Master key conveyed to many participants. Layer of indirection separating key management (who should have it?) from conferencing details. Group controller sets up DTLS-SRTP key transport EKT uses 1 to many RTP channel Defined two years ago, premature. Essential for scaling to large groups -- avoids layer violations. Currently ses sdescriptions Eric Rescorla: what alternatives to EKT. A couple of DTLS-SRTP extensions give almost as good results. How would you know it is safe to send EKT messages? SDP. Looks quite useful. Roni: Do more discussion of tradeoffs before merging documents. Think about multi-unicast cast, which scales differently from multicast. ?? need reliability, RTP not reliable. David: can lose some packets. Dan: can send in either RTCP or RTP. In latter case, common fate. Sender can use more replication initially. AES-192 and AES-256 David McGrew ================================ 128 bit keys won't expire for decades, but might want to be ready for larger keys. Possibilities: future advances in cryptanalysis, larger computers. (Competition/compatibility ZRTP). SWEETPEA compliance. Should we make AES-192 optional, make AES-256 the target. Definitely add DTLS-SRTP binding. Agreed, make standard Jonathan: what about SHA-1? Offline discussion. Cullen: make sure SecArea gets involved. AES-GCM and AES-CCM autheticated encryption David McGrew ======================================================== AES-GCM Encryption + authen -- no need for HMAC Arguably efficient, esp. for short packets AES-CCM more compact code. Draft uses interface defined by RFC 5116 Eric: supports making WG doc. But why CCM? Roni: see if existing usage mandates use Dan xx: might consider SIV instead of CCM. SRTP Store and forward Blom =========================== Draft refocussed on use cases and requirements. Cullen only reader. Didn't understand it all yet. Eric: wondered why all the layers. Response: other scenarios. Continuing discussion. To the list.