[AVTCORE] IETF 81 meeting report
Roni Even <Even.roni@huawei.com> Sun, 14 August 2011 07:00 UTC
Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46A521F85F2 for <avt@ietfa.amsl.com>; Sun, 14 Aug 2011 00:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.979
X-Spam-Level:
X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6fswUL2u04q for <avt@ietfa.amsl.com>; Sun, 14 Aug 2011 00:00:18 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB7D21F85BB for <avt@ietf.org>; Sun, 14 Aug 2011 00:00:17 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPW000OFOTLRX@szxga04-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPW005YCOTL84@szxga04-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Received: from windows8d787f9 (bzq-79-180-16-191.red.bezeqint.net [79.180.16.191]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPW00BQQOTANG@szxml12-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Date: Sun, 14 Aug 2011 10:00:31 +0300
From: Roni Even <Even.roni@huawei.com>
To: 'AVT Core WG' <avt@ietf.org>
Message-id: <02b901cc5a4f$dfecb510$9fc61f30$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_zCCyB7APtd1tjw//+GRrPQ)"
Content-language: en-us
Thread-index: AcxaT9f/oXhnS9U0RZa3YY/Or3IigA==
Subject: [AVTCORE] IETF 81 meeting report
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Aug 2011 07:00:22 -0000
Hi, This is the draft report for the AVTcore session in IETF81 Please review Roni Even AVTcore co-chair Audio/Video Transport Core Maintenance (AVTCore) Working Group Minutes IETF 81 Chairs: Magnus Westerlund Roni Even Note Takers: Brian Rosen Bill VerSteeg AVTCore Introduction and Status Update These are the minutes for the AVTCore WG. The payload and XRblock WG did not meet and the status was presented in AVText session. The WG has published 7 RFCs, has 1 documents in AUTH48, and an additional 1 in the RFC-editors queue, and 1 documents with the AD or IESG. There are three WG documents that are not going to be discussed here today. draft-ietf-avtcore-srtp-vbr-audio has just finished WG last call and is ready for publication, but have received some minor comments that should be addressed before publication request. draft-ietf-avt-srtp-ekt-02 and draft-ietf-avt-srtp-aes-gcm-01 both needs review. Then the chairs reviewed the WG's milestones. We are already late on the RTP monitoring architecture and the guidelines for VBR with SRTP. The later is mostly done, but the monitoring architecture requires more work and needs to be rescheduled. The RTP Payload Format media types registry is not up to date. There was a discussion what to do. Update it or discontinue it. The consensus is that there is value on this registry and the payload chairs (Roni Even) will update it. We will need to verify that it is updated with every new RTP payload registered with IANA when registering in the general media type registry. Roni introduced a slide on draft-singh-avtcore-mprtp-02 that did not get a time slot since there was little email action on it. Encryption of Header Extensions in SRTP Jonathan Lennox presented draft-ietf-avtcore-srtp-encrypted-header-ext-00. Action item for Jonathan to try to contact the GCM/AEAD authors in order to support not only CTR. Other issues were about having the references correct including the security references. RTCP Extension for Feedback Suppression Indication Qin Wu presented draft-ietf-avtcore-feedback-supression-rtp-05. The open comments were resolved. If there will be no more comments on the list, the document will go to WGLC. Monitoring Architectures for RTP Qin Wu Presented draft-ietf-avtcore-monarch-03. The major open issue was about the identity block Colin Perkins said that for correlating reports we have SSRC. For correlation of RTP with non RTP, we have source descriptions. Fits better in SDES. The chairs asked if there is a need for the identity block at all and Colin see no need. There should be a use case to show a usage of identity block if want to keep it. The draft will be revised accordingly and will see if ready for WGLC. RTP Multiple Stream Sessions and Simulcast Magnus presented draft-westerlund-avtcore-multistream-and-simulcast-00. The first issue discussed was what type of simulcast is this and if the term is correct, Magnus says that the draft defines it and he does not have a better term. There was also a question if it is about simulcast or general multistreams. The next topic was about what is meant by multistreams and how it relates to CLUE work. Magnus response was that it is about multiple RTP sessions, typically one per video stream and one per video stream. The work addresses only the RTP layer and not the CLUE framework multi-stream usage which may need the support on the RTP layer. Another topic in the draft is Bandwidth, talk about two issues, one of flow control and the other is different bandwidth for send and receive, there were comments that it affects also RTCP traffic. It looks like there is interest in the topic but was considered during the discussion to be a separate topic from the simulcast multiple streams. On the SSDP signaling Useful for Retransmission, redundancy and simulcast Jonathan Lennox - we have solutions for retransmission, but they are awful. This would make it much better. The general feeling was that the draft offers solution but the problem it wants to address is broad and not clear, would like to start with architecture description and requirements. Hadriel claimed that it may require a new WG on the topic. There was a strong HUM to start working on architecture of simulcast, multistream. The BW is a separate issue. Delayed Duplication Attribute and Duplication Grouping in SDP Two MMUSIC drafts were presented by Ali Begen since there is a relation to AVTcore. draft-begen-mmusic-temporal-interleaving-02 - This draft propose to duplicate the main stream with one or more copies which are delayed. The major issue raised was that if the loss is due to congestion this will make it worse. Some of the comments that were made: Colin - failures may be a valid reason to do this, not congestion Colin - exact dupes need to be sent in a separate session. Payload type SHOULD be the same, but nothing breaks if you use a different payload type Colin - about signaling, if you have a box that does not understand the SDP, it will try to render both streams Jonathan Lennox - what is the cause of these outages if it is not congestion? Something between every packet and partial stream? Ali Begen- routing errors cause data loss - particularly in core networks. Other comments were that this looks like a FEC with worst algorithm. It make sense if CPU resources are more expensive then network bandwidth. Ted Hardie- need an applicability statement, place where this is a bad idea - subject to a "stupidity attack" based on a bug or bad configuration Chairs: This is an MMUSIC draft but the issues raised are relevant to AVTcore so need to be addressed. draft-begen-mmusic-redundancy-grouping-01 This is the SDP for grouping, was discussed in MMUSIC Comments: Colin - these streams presumably send RTCP back - does this work with encryption? Colin - You do not need a new XR report. The middlebox is just a mixer. Ali - there may be additional elements to report. Colin - the existing mixer semantics would probably work. Magnus - there are grouping issues, and we need to figure out which group addresses it, currently MMUSIC. Retransmission for SSM sessions Ali Begen presented draft-vancaenegem-avtcore-retransmission-for-ssm-00. There was no discussion. An open issue if this is AVTCore or AVText since it address a specific use case. RTP Session Multiplexing Magnus introduced the topic it came from discussion in RTCWEB. RTP requires a lower transport layer to separate RTP sessions on the other hand desire to use one UDP port to address NAT/FW and IPv4 issues. There was a breakout session and the proposal is to have a short term solution that will use one RTP session for audio and video for RTCWEB. This usage will be signaled. The RTCweb solution will also allow fallback to separate sessions for audio and video to be used for example for FEC, and backward interoperability. There will be work also on a long term solution which provides a generic muxing solution of multiple RTP sessions by adding an explicit RTP session identifier somewhere. Some of the comments: Bill VerSteeg - need to consider the multicast case in AVT, as the RTCWEB folks are primarily considering unicast Adam Roach - questioning the number of media streams allowed - multiplexing could have an arbitrary number of flows. Magnus - talking about one session for all streams. Harald - applications do not have to use multiplexed sessions, but they may Colin - FEC cases may not always work with session multiplexing, but Audio/Video/Text will work There was a question if short term is different than long term. This is not defined yet. The chairs took a HUM if there is an interest in working on this issue in AVTcore and there was a strong consensus. Bill VerSteeg and Colin Perkins volunteered to work on requirements for long term solution.
- [AVTCORE] IETF 81 meeting report Roni Even