From magnus.westerlund@ericsson.com Mon Jul 2 00:00:16 2012 Return-Path: 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 9DD9211E8136; Mon, 2 Jul 2012 00:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 amoJQ0eux+TG; Mon, 2 Jul 2012 00:00:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5269311E807F; Mon, 2 Jul 2012 00:00:15 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-5c-4ff14702b564 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BF.50.25842.20741FF4; Mon, 2 Jul 2012 09:00:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Mon, 2 Jul 2012 09:00:17 +0200 Message-ID: <4FF14705.8000606@ericsson.com> Date: Mon, 2 Jul 2012 09:00:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , "avtext@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUyM+JvrS6z+0d/g6fHWSxe9qxkt/h47war A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyDr9fwVjQzl5x7/tbpgbGh6xdjJwcEgImEntnHGKB sMUkLtxbz9bFyMUhJHCKUeJDw2t2CGcZo8Ss/2fZQKp4BbQlVq5axQhiswioSHSePgPWzSZg IXHzRyNYjahAsMS06ffYIeoFJU7OfAJWIyLgLvHh2z6wGmEBY4nvq/YyQmyWlLjXvhosziyg JzHlagsjhC0v0bx1NjOILQS0t6Gpg3UCI/8sJGNnIWmZhaRlASPzKkbh3MTMnPRyc73Uoszk 4uL8PL3i1E2MwJA7uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTI xMEp1cBY5nTSKKXx0JsZv7tuRGzz99MrnD5/wqJDl5bkHyz67sMnzhh7RnNpz+ml+UpF6Ve/ HGpfwvHUeMlcNUtNYYu9SeUPPqpOYF0kN2OOcn3fB8a7v7RPnM5MaLRjE910z677Uuqtd3sn axuJf9k1tUax4pyS6M5ab4t41vfbHiU+OvRkW+aqD3fnKrEUZyQaajEXFScCAIYyDg8HAgAA Subject: [AVTCORE] RTP Stream Duplication work into AVTEXT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 07:00:16 -0000 AVTCORE and AVTEXT, AVTCORE WG held a call for adopting a WG item on RTP stream duplication which was well supported. The chairs and the ADs has discussed the WG item when creating a milestone. We come to the conclusion that this work would fit within AVTEXT's charter. Considering the current workload in AVTEXT etc. We intended to move the WG item into AVTEXT. If you have issues with this, please raise it now. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jul 2 02:04:14 2012 Return-Path: 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 49D6121F8BB3 for ; Mon, 2 Jul 2012 02:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.221 X-Spam-Level: X-Spam-Status: No, score=-106.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 hIfMKKq3nIaE for ; Mon, 2 Jul 2012 02:04:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47BA021F8ADF for ; Mon, 2 Jul 2012 02:04:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc26d000005908-e8-4ff1641058a7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.60.22792.01461FF4; Mon, 2 Jul 2012 11:04:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Mon, 2 Jul 2012 11:04:16 +0200 Message-ID: <4FF16412.8080909@ericsson.com> Date: Mon, 2 Jul 2012 11:04:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra5Aykd/g3dfbCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuvDL+wF69krZu6bwd7A+IO1i5GTQ0LAROLgry+MELaYxIV7 69m6GLk4hAROMUqc2zyBEcJZxiixemcrWBWvgLZEy8ptYDaLgIrExKv9YDabgIXEzR+NbCC2 qECwxLTp99gh6gUlTs58wgJiiwgoSeyYtI0ZxBYG2nzgSzc7xGZJiXvtq8F6mQX0JKZcbWGE sOUlmrfOBqsXAtrb0NTBOoGRfxaSsbOQtMxC0rKAkXkVo3BuYmZOermhXmpRZnJxcX6eXnHq JkZgoB3c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGQW iDjOlW0WWVrdHB8u/lf7z/JDapM3JsuoHTp0+srKwMUOJ9Rzk7fffjr7WNm1dwwR2TOm7bFY X/MuLXGjhexJ+VO10fcvfbz+bgcb67E6Z05RJ8kNhec1XP6I6rl3HqtJWJTmPLGiaOvvrzcF r53MrgqPFIxMD754xuT4148d8iU//gnZX1ViKc5INNRiLipOBAAsLZ/sAgIAAA== Subject: [AVTCORE] Next step for draft-ietf-avtcore-monarch-17 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 09:04:14 -0000 WG, I am personally happy with the latest changes in this document. Glen suggested that this document should change status to BCP. That would clearly raise the documents status from "this is our thinking of how it should work" to "this is how you shall do it". If that is what the WG think we should do, then I am happy to execute on that. People who think it should be a BCP please provide input in the next week, i.e. no later than the 9th of July. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mary.ietf.barnes@gmail.com Mon Jul 2 08:58:31 2012 Return-Path: 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 0CFCF21F854E; Mon, 2 Jul 2012 08:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.638 X-Spam-Level: X-Spam-Status: No, score=-103.638 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 M0RQw8myCxab; Mon, 2 Jul 2012 08:58:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50E7921F851C; Mon, 2 Jul 2012 08:58:30 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9734851obb.31 for ; Mon, 02 Jul 2012 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4d2ogAaugDYMLmg9cIAI+X9BYTNC7EF10BM1aiGK4cI=; b=s/K+n8IeqvHpuNk0YA3F+FTAfiQrpAjA6CsBy3kqQ+dLfzixW9gEa8BWlEHPvaEue0 f2n5Js6Bb7+XomwMIfbXrB4qfpMijEBAvOIK89FDLgcJW6ZGtUtKhp9/mhSYjSx8u8zs OegCwcWBsmqGNScVH9sg+EH/pkf5PTlPSD+Rr827QGBaFGoJUtHw8ZeZI3kwcxo/t9jn iNXEaV/66W5uTHBQCOsLwKqEGkagdrz/QPKx5dOGfXjZ2xTyZ+I/6RkpvMDz2DQQkz3C svty0e8d/x/KhlKWDeYljbn+DrU+duCUCLBhLoMk8m/o1wK7WRJeYzgyI/w7WnPI+VSp V79w== MIME-Version: 1.0 Received: by 10.60.171.135 with SMTP id au7mr14388795oec.62.1341244715429; Mon, 02 Jul 2012 08:58:35 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Mon, 2 Jul 2012 08:58:35 -0700 (PDT) In-Reply-To: <4FF14705.8000606@ericsson.com> References: <4FF14705.8000606@ericsson.com> Date: Mon, 2 Jul 2012 10:58:35 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec55405a6d1f07004c3dadede Cc: "avtext@ietf.org" , IETF AVTCore WG Subject: Re: [AVTCORE] RTP Stream Duplication work into AVTEXT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 15:58:31 -0000 --bcaec55405a6d1f07004c3dadede Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can you please remind us what draft that is? I believe you are referring to: http://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ It's probably a good idea to have the draft name in this email thread for searching in the archives later. Thanks, Mary. On Mon, Jul 2, 2012 at 2:00 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > AVTCORE and AVTEXT, > > AVTCORE WG held a call for adopting a WG item on RTP stream duplication > which was well supported. The chairs and the ADs has discussed the WG > item when creating a milestone. We come to the conclusion that this work > would fit within AVTEXT's charter. Considering the current workload in > AVTEXT etc. We intended to move the WG item into AVTEXT. > > If you have issues with this, please raise it now. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --bcaec55405a6d1f07004c3dadede Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can you please remind us what draft that is? =A0I believe you are referring= to:

It's probably a good idea to have the draft name in= this email thread for searching in the archives later.=A0

Thanks,
Mary.=A0

On Mon, Jul 2, 2012 at 2:00 AM, Magnus Westerlund <magnus.wes= terlund@ericsson.com> wrote:
+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--bcaec55405a6d1f07004c3dadede-- From internet-drafts@ietf.org Mon Jul 2 21:49:55 2012 Return-Path: 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 091FF21F86F1; Mon, 2 Jul 2012 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.373 X-Spam-Level: X-Spam-Status: No, score=-98.373 tagged_above=-999 required=5 tests=[AWL=-4.106, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, SARE_SUB_6CONS_WORD=0.356, 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 Ye-9c5qCZ0ux; Mon, 2 Jul 2012 21:49:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624321F86D9; Mon, 2 Jul 2012 21:49:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703044954.21859.53951.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 21:49:54 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 04:49:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-00.txt Pages : 21 Date : 2012-07-02 Abstract: NTP timestamps are used by several RTP protocols for synchronisation and statistical measurement. This memo specifies SDP signalling identifying NTP timestamp clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Jul 2 23:06:53 2012 Return-Path: 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 B29F211E8138; Mon, 2 Jul 2012 23:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 Z8IZeL-9YEfh; Mon, 2 Jul 2012 23:06:53 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57E2811E8134; Mon, 2 Jul 2012 23:06:52 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-4c-4ff28c027974 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C4.AE.25842.20C82FF4; Tue, 3 Jul 2012 08:06:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Tue, 3 Jul 2012 08:06:57 +0200 Message-ID: <4FF28C01.9010705@ericsson.com> Date: Tue, 3 Jul 2012 08:06:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mary Barnes References: <4FF14705.8000606@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvrS5Tzyd/g2nvBS1e9qxkt/h47war xef9+5kdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsEroy3a7cwFhwSqjh/5SBLA+Mhvi5G Tg4JAROJpU/vskLYYhIX7q1n62Lk4hASOMUosfXpJRYIZxmjxN6nf5lBqngFtCUeb53A2MXI wcEioCLRfM8HJMwmYCFx80cjG4gtKhAsMW36PXaIckGJkzOfsIDYIgI6Et8+vwWrYRZwl3hz 7wgjiC0s4CixsHE7mC0kUCCx4OkLJhCbUyBQYtaiH2wQx0lK3GtfDdWrJzHlagsjhC0v0bx1 NjNEr7ZEQ1MH6wRGoVlIVs9C0jILScsCRuZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiBwXxw y2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHugGxp7rwn u5kqcj7/tT++vGhWdsLWO+f31139tdcwxOOMRI3Ze+7vwucP7o9af2Jh3RbHPU/23pkmMy3v 4xOHP7u66y7uMD8u5217SC/5kcPVqN27b7t53DJf/LHS8Rury+prV85v9E9vulL6PcN569Ny NkmnixkuT2YVdbI/03YS/25r2bVeiaU4I9FQi7moOBEA1Q7SSzQCAAA= Cc: "avtext@ietf.org" , IETF AVTCore WG Subject: Re: [AVTCORE] RTP Stream Duplication work into AVTEXT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 06:06:53 -0000 On 2012-07-02 17:58, Mary Barnes wrote: > Can you please remind us what draft that is? I believe you are > referring to: > http://datatracker.ietf.org/doc/draft-begen-avtcore-rtp-duplication/ > > It's probably a good idea to have the draft name in this email thread > for searching in the archives later. Yes, it is that draft. Sorry for not being explicit enough. Magnus > > Thanks, > Mary. > > On Mon, Jul 2, 2012 at 2:00 AM, Magnus Westerlund > > > wrote: > > AVTCORE and AVTEXT, > > AVTCORE WG held a call for adopting a WG item on RTP stream duplication > which was well supported. The chairs and the ADs has discussed the WG > item when creating a milestone. We come to the conclusion that this work > would fit within AVTEXT's charter. Considering the current workload in > AVTEXT etc. We intended to move the WG item into AVTEXT. > > If you have issues with this, please raise it now. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Wed Jul 4 13:48:57 2012 Return-Path: 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 0350921F85E5 for ; Wed, 4 Jul 2012 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 p4pYxkzJRBTZ for ; Wed, 4 Jul 2012 13:48:56 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 128EF21F85E4 for ; Wed, 4 Jul 2012 13:48:56 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SmWV0-0006PN-ef; Wed, 04 Jul 2012 20:49:06 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4FF16412.8080909@ericsson.com> Date: Wed, 4 Jul 2012 21:48:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <184D5288-7B31-4AC6-B666-A3FF894BB02A@csperkins.org> References: <4FF16412.8080909@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1278) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Next step for draft-ietf-avtcore-monarch-17 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 20:48:57 -0000 Magnus, The changes resulting from the IESG review seem to be pushing this draft = away from BCP recommendations, and more towards informational = guidelines. I could see the -14 draft as a BCP, but not so much the -16 = draft. Given the way the draft has developed, I'd leave it as = informational. Cheers, Colin On 2 Jul 2012, at 10:04, Magnus Westerlund wrote: > WG, >=20 > I am personally happy with the latest changes in this document. >=20 > Glen suggested that this document should change status to BCP. That = would clearly raise the documents status from "this is our thinking of = how it should work" to "this is how you shall do it". >=20 > If that is what the WG think we should do, then I am happy to execute = on that. People who think it should be a BCP please provide input in the = next week, i.e. no later than the 9th of July. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From rachel.huang@huawei.com Wed Jul 4 18:17:12 2012 Return-Path: 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 5F11F21F8550 for ; Wed, 4 Jul 2012 18:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 gkNwzfYgAmS0 for ; Wed, 4 Jul 2012 18:17:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 549EF21F854E for ; Wed, 4 Jul 2012 18:17:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS40038; Wed, 04 Jul 2012 21:17:23 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 18:15:38 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 18:15:43 -0700 Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.214]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 09:15:36 +0800 From: "Huangyihong (Rachel)" To: Roni Even , "avt@ietf.org" Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRANpwnxA Date: Thu, 5 Jul 2012 01:15:35 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB3AF5A792@szxeml539-mbx.china.huawei.com> References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.163] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB3AF5A792szxeml539mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-avtcore-idms@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 01:17:12 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB3AF5A792szxeml539mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have read the draft and have no other comments except for a few spelling = errors. It can be checked using the IETF tools: http://tools.ietf.org/tools/idspell/webservice. I support the publication of the document after all the issues have been fi= xed. Best Regards! Rachel From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: Monday, June 18, 2012 12:05 AM To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf= -avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore co-chair --_000_51E6A56BD6A85142B9D172C87FC3ABBB3AF5A792szxeml539mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

I have read the draft = and have no other comments except for a few spelling errors. It can be chec= ked using the IETF tools:

http://tools.ietf.org/tools/idspell/webservice.

I support the publicat= ion of the document after all the issues have been fixed.=

 

Best Regards!

Rachel

 

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Monday, June 18, 2012 12:05 AM
To: avt@ietf.org
Cc: draft-ietf-avtcore-idms@tools.ietf.org
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

 

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-i=
etf-avtcore-idms-05 , RTCP for inter-de=
stination media synchronization.
 

The WGLC will end on July 10th, 20= 12

 

Please review the draft and send comments to the lis= t.

 

For the draft authors;  Are you aware of any IPR tha=
t applies to draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance with IETF IPR r=
ules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
The above question is needed for the document write-up wh=
en sent to publication.
 

Thanks

 

Roni Even

AVTcore  co-chair

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB3AF5A792szxeml539mbxchi_-- From bill.wu@huawei.com Wed Jul 4 19:13:58 2012 Return-Path: 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 7CBBC21F8525 for ; Wed, 4 Jul 2012 19:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.605 X-Spam-Level: X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 DDP+yWrYjmR7 for ; Wed, 4 Jul 2012 19:13:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A7FF021F8522 for ; Wed, 4 Jul 2012 19:13:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS42464; Wed, 04 Jul 2012 22:14:09 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:12:43 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:12:48 -0700 Received: from w53375 (10.138.41.149) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 10:11:15 +0800 Message-ID: From: Qin Wu To: Colin Perkins , Magnus Westerlund References: <4FF16412.8080909@ericsson.com> <184D5288-7B31-4AC6-B666-A3FF894BB02A@csperkins.org> Date: Thu, 5 Jul 2012 10:11:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Next step for draft-ietf-avtcore-monarch-17 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 02:13:58 -0000 QWdyZWUsIHB1dHRpbmcgaXQgYXMgaW5mb3JtYXRpb25hbCBsb29rcyBnb29kIHRvIG1lLg0KDQpS ZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJDb2xp biBQZXJraW5zIiA8Y3NwQGNzcGVya2lucy5vcmc+DQpUbzogIk1hZ251cyBXZXN0ZXJsdW5kIiA8 bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0KQ2M6ICJJRVRGIEFWVENvcmUgV0ciIDxh dnRAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVseSAwNSwgMjAxMiA0OjQ4IEFNDQpTdWJq ZWN0OiBSZTogW0FWVENPUkVdIE5leHQgc3RlcCBmb3IgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFy Y2gtMTcNCg0KDQpNYWdudXMsDQoNClRoZSBjaGFuZ2VzIHJlc3VsdGluZyBmcm9tIHRoZSBJRVNH IHJldmlldyBzZWVtIHRvIGJlIHB1c2hpbmcgdGhpcyBkcmFmdCBhd2F5IGZyb20gQkNQIHJlY29t bWVuZGF0aW9ucywgYW5kIG1vcmUgdG93YXJkcyBpbmZvcm1hdGlvbmFsIGd1aWRlbGluZXMuIEkg Y291bGQgc2VlIHRoZSAtMTQgZHJhZnQgYXMgYSBCQ1AsIGJ1dCBub3Qgc28gbXVjaCB0aGUgLTE2 IGRyYWZ0LiBHaXZlbiB0aGUgd2F5IHRoZSBkcmFmdCBoYXMgZGV2ZWxvcGVkLCBJJ2QgbGVhdmUg aXQgYXMgaW5mb3JtYXRpb25hbC4NCg0KQ2hlZXJzLA0KQ29saW4NCg0KDQoNCk9uIDIgSnVsIDIw MTIsIGF0IDEwOjA0LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4gV0csDQo+IA0KPiBJIGFt IHBlcnNvbmFsbHkgaGFwcHkgd2l0aCB0aGUgbGF0ZXN0IGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVu dC4NCj4gDQo+IEdsZW4gc3VnZ2VzdGVkIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgY2hhbmdl IHN0YXR1cyB0byBCQ1AuIFRoYXQgd291bGQgY2xlYXJseSByYWlzZSB0aGUgZG9jdW1lbnRzIHN0 YXR1cyBmcm9tICJ0aGlzIGlzIG91ciB0aGlua2luZyBvZiBob3cgaXQgc2hvdWxkIHdvcmsiIHRv ICJ0aGlzIGlzIGhvdyB5b3Ugc2hhbGwgZG8gaXQiLg0KPiANCj4gSWYgdGhhdCBpcyB3aGF0IHRo ZSBXRyB0aGluayB3ZSBzaG91bGQgZG8sIHRoZW4gSSBhbSBoYXBweSB0byBleGVjdXRlIG9uIHRo YXQuIFBlb3BsZSB3aG8gdGhpbmsgaXQgc2hvdWxkIGJlIGEgQkNQIHBsZWFzZSBwcm92aWRlIGlu cHV0IGluIHRoZSBuZXh0IHdlZWssIGkuZS4gbm8gbGF0ZXIgdGhhbiB0aGUgOXRoIG9mIEp1bHku DQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZN DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAg KzQ2IDEwIDcxNDgyODcNCj4gRuRy9mdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2 IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlk ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg0KDQotLSANCkNvbGluIFBlcmtp bnMNCmh0dHA6Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50 ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXZ0 From albrecht.schwarz@alcatel-lucent.com Fri Jul 6 02:27:48 2012 Return-Path: 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 06FDA21F8625 for ; Fri, 6 Jul 2012 02:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 uPj1OrO3H6cd for ; Fri, 6 Jul 2012 02:27:47 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3545F21F85D5 for ; Fri, 6 Jul 2012 02:27:46 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q669Ouie006616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Jul 2012 11:27:57 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 6 Jul 2012 11:27:28 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Magnus Westerlund Date: Fri, 6 Jul 2012 11:27:27 +0200 Thread-Topic: RTP Multiplexing Architecture => term "media stream" Thread-Index: Ac0++G77UhLSOuQ7Q3qklMNfkjKooQcXws8g Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96218B2303EA@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com> <114BEA37E68543458F3F22DFC709324E@china.huawei.com> <4FC71297.6080800@ericsson.com> In-Reply-To: <4FC71297.6080800@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "avt@ietf.org" Subject: [AVTCORE] RTP Multiplexing Architecture => term "media stream" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 09:27:48 -0000 Ref.: http://tools.ietf.org/id/draft-westerlund-avtcore-multiplex-architect= ure-01.txt Magnus, just a short comment with respect to your definition: Media Stream: A sequence of RTP packets using a single SSRC that together carries part or all of the content of a specific Media Type from a specific sender source within a given RTP session. =3D> a media stream may carry multiple different media formats of the same = type, right? If yes, then "media type" dependency might be a key characteristic of "medi= a stream". I'm wondering whether then the term "media stream" could be replaced by e.g= . "media type stream" or "media type specific stream" or anything else, due= to the fact that the term "media stream" is heavily used, often with sligh= tly different semantics, in other contexts. The update in your draft might be e.g.: Media Type Specific Stream (briefly "Media Stream" in this document): A se= quence ... BTW: the loosely usage of term "media stream" in RFC 3550 gives the impress= ion that the "RFC 3550 media stream" is tight to a single media format in m= y understanding. Hm? Any thoughts? Albrecht From magnus.westerlund@ericsson.com Fri Jul 6 04:10:14 2012 Return-Path: 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 98DA821F879E for ; Fri, 6 Jul 2012 04:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 Aft-jyLUzx0n for ; Fri, 6 Jul 2012 04:10:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9872121F86B1 for ; Fri, 6 Jul 2012 04:10:13 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-30-4ff6c7a40f66 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 17.A4.23986.4A7C6FF4; Fri, 6 Jul 2012 13:10:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 13:10:29 +0200 Message-ID: <4FF6C7A3.6040705@ericsson.com> Date: Fri, 6 Jul 2012 13:10:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <20120529022556.7241.72727.idtracker@ietfa.amsl.com> <4FC62550.7000707@ericsson.com> <4FC62E7D.30402@ericsson.com> <114BEA37E68543458F3F22DFC709324E@china.huawei.com> <4FC71297.6080800@ericsson.com> <5F7BCCF5541B7444830A2288ABBEBC96218B2303EA@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96218B2303EA@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7S49/8DZbeZ7T40/qL0eJlz0p2 ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxY8pS1oJfghVLjp5nbGCcz9fFyMkhIWAi cWh1ByuELSZx4d56ti5GLg4hgVOMEpMP/mKBcJYxSiyYc4gRpIpXQFvi6qrTzCA2i4CKxOaV G8HibAIWEjd/NLKB2KICwRLTpt9jh6gXlDg58wkLiC0i4CFxf8ExoBoODmYBRYlJ7ZIgprCA o8S81clQq5gk2m7uAmvlFEiQOL31IwvEcZIS99pXg41nFtCTmHK1hRHClpdo3job7BwhoNMa mjpYJzAKzUKyeRaSlllIWhYwMq9iFM5NzMxJLzfSSy3KTC4uzs/TK07dxAgM4YNbfqvuYLxz TuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNvvSer1zcn//3nSS5M9 WwrerFk7eYpJgjnjvZ7NixutT/DPWrdTPPH6ej5lScMrZxcpLHj0pEvXNPzpt+ch9gcPGx8L UFkVs/fwtNfdvPuFOJ4KpHsUX9sl5R1n8iNOV+VoqsIGl8qCd43+e/605ylozRbLqvv80LX0 YGO34LyYNzcXn941fZkSS3FGoqEWc1FxIgBK2p00LwIAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] RTP Multiplexing Architecture => term "media stream" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 11:10:14 -0000 On 2012-07-06 11:27, Schwarz, Albrecht (Albrecht) wrote: > Ref.: > http://tools.ietf.org/id/draft-westerlund-avtcore-multiplex-architecture-01.txt > > Magnus, > > just a short comment with respect to your definition: > > Media Stream: A sequence of RTP packets using a single SSRC that > together carries part or all of the content of a specific Media Type > from a specific sender source within a given RTP session. > > > => a media stream may carry multiple different media formats of the > same type, right? If you mean that a video source could be encoded using H.264 or MPEG-2 and what is in the media stream may be either of them at any given time. The answer is yes. > > If yes, then "media type" dependency might be a key characteristic of > "media stream". To certain degree it is. But there is several other properties that defines a media stream. I think your proposal will simply be illogical to people. However, we already have worked on the next version of the multiplex-architecture document. It will be much clearer on the usage of media stream thanks to Harald Alvestrand's work. Cheers Magnus > > I'm wondering whether then the term "media stream" could be replaced > by e.g. "media type stream" or "media type specific stream" or > anything else, due to the fact that the term "media stream" is > heavily used, often with slightly different semantics, in other > contexts. > > The update in your draft might be e.g.: > > Media Type Specific Stream (briefly "Media Stream" in this document): > A sequence ... > > BTW: the loosely usage of term "media stream" in RFC 3550 gives the > impression that the "RFC 3550 media stream" is tight to a single > media format in my understanding. Hm? > > > Any thoughts? Albrecht > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jul 6 07:05:21 2012 Return-Path: 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 9886F21F85E0 for ; Fri, 6 Jul 2012 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 LhFEr+Q-+EV4 for ; Fri, 6 Jul 2012 07:05:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99D21F859A for ; Fri, 6 Jul 2012 07:05:20 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-e1-4ff6f0af6b8f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.3D.23986.FA0F6FF4; Fri, 6 Jul 2012 16:05:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 16:05:35 +0200 Message-ID: <4FF6F0AE.9080407@ericsson.com> Date: Fri, 6 Jul 2012 16:05:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Pascal Buhler (pabuhler)" References: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com> In-Reply-To: <7EC1BF197B21C747868126E92F8A7D62D8BE@xmb-aln-x04.cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre76D9/8DS506Fq87FnJbrHx7SRW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjdu9RpoKbwhUXPj9naWB8wt/FyMkhIWAi 0f/zLyuELSZx4d56ti5GLg4hgVOMEn9WT2UGSQgJLGOUmPm9BsTmFdCW6O5fwNjFyMHBIqAi cfY2N0iYTcBC4uaPRjYQW1QgWGLa9HvsEOWCEidnPmEBKRcRMJZYtikZxGQWUJSY1C4JUiEs 4CjxvmkVC8QiD4n3rzeB2ZwCnhK7jr5hg7hMUuJe+2owm1lAT2LK1RZGCFteonnrbKgjtSUa mjpYJzAKzUKyeBaSlllIWhYwMq9iFM5NzMxJLzfSSy3KTC4uzs/TK07dxAgM3oNbfqvuYLxz TuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIVEX/oZ567Y9nXChl2H Zz/RuiVSJf/6wP925qKtR0tNLYWv7Fpx7WdqdfmxAzorl6qZZ33ifDHR/cyhnKQLMgl7E/nu 1ahmHw3uEp/XKyVkdffyrFnvc/238uu6Tm05KFsSfXFCfcQMpg/T8xnN2vIr83vfbr+6L6V4 N/vz1EXuH/zn1O78YqPEUpyRaKjFXFScCAAhJ5gbLAIAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] comment on draft-westerlund-avtext-rtcp-sdes-srcname X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:05:21 -0000 On 2012-06-29 09:43, Pascal Buhler (pabuhler) wrote: > > One of the problems mentioned in the draft, that is the case when > receiving the RTP streams before the SEDS has arrived is something > that needs to be addressed. The option of including the mapping in > the SDP is not always appropriate due to devices like an RTP > Translator in the middle. Therefore I was wondering if you have > considered including a definition of a RTP header extension > (http://tools.ietf.org/html/rfc5285) to include the SRCNAME in the > RTP stream. Yes it is potentially a lot of bits wasted but it is up > to the sender to decide the size of the SRCNAME so that can mitigate > it somewhat. Also it may not be required in every packet just packets > that make sense for example only in the beginning of a stream, at key > points in the stream or else periodically. When using the SRCNAME to > correlate two or more separate encodings of the same source it is > important as a receiver that when first receiving one encoding and > then switching to receive a second encoding to make this correlation > as soon as possible. > Thanks for the support for the general use case. Yes, using a header extension to provide the information is a potential extension for certain use cases that clearly can be an extension on the basis of our proposed solution. Yes, clearly you should have the flexibility to include such information as often or seldom as makes sense in your application. > > There is also mention of using this as a way correlating FEC with > media. How would this work in the simulcast case where there are > multiple encodings of the same source. How to use only SRCNAME to map > the FEC stream to the individual media streams when all media streams > have the same SRCNAME. Yes, this has been raised previously and I agree we need to support it. We think we have an idea how to improve SRCNAME to work also in those cases. Now it is only of matter of manage to write it up before the draft deadline. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Mon Jul 9 04:03:26 2012 Return-Path: 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 9AA9D21F8623 for ; Mon, 9 Jul 2012 04:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396] 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 HZg3-31V4RYb for ; Mon, 9 Jul 2012 04:03:25 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6D10721F861C for ; Mon, 9 Jul 2012 04:03:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,551,1336341600"; d="scan'208";a="71934097" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 09 Jul 2012 13:03:35 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 13:03:35 +0200 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRADAXESAAMj08/AAiFbPgAI2J/JQ Date: Mon, 9 Jul 2012 11:03:34 +0000 Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <4FE3271F.7020506@ericsson.com> <4FEBFEAD.2040908@ericsson.com> In-Reply-To: <4FEBFEAD.2040908@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-avtcore-idms@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:03:26 -0000 Hi Magnus, All, I promised to get back to you on the following point: > 7. Section 6. Assuming that the normative definition will remain and = > possibly also as a clarification to the ETSI specification: This = > section is not making it sufficient clear that what an SC is supposed = > to do is to pick one RTP packet it recevied, then report the values = > for this particular packet. I think one should clarify this and also = > making it clearer what the selection criteria for such a packet is. > Should one focus on using maximum delayed packets, media delayed = > packets or simply random selection? In addition we have the rules = > about picking packets when multiple RTP sequence numbers have the same = > TS value. I would recommned that one add some paragraphs before the = > actual figure definition to discuss this. > = > RvB: Good point. In theory it shouldn't really matter. Up to now, we = > have been assuming random selection, just picking a packet when the = > RTCP rules allow you to send a report. I will check with my co-authors = > to see whether they still think this is good enough. I will come back = > to you on this one. I checked with my co-authors and we agree that reporting on the 'last' RTP = packet to arrive when the RTCP timer is sufficient. In cases where a partic= ular video frame is divided over a number of packets, the client should rep= ort on the packet with the lowest sequence number. We will include such a t= ext in the next iteration. Best regards, Ray -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: donderdag 28 juni 2012 8:50 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 On 2012-06-25 14:15, Brandenburg, R. (Ray) van wrote: > Hi Magnus, > = > Many thanks for the very thorough review. You will find my comments = > inline. > = > Ray > = > -----Original Message----- From: Magnus Westerlund = > [mailto:magnus.westerlund@ericsson.com] Sent: donderdag 21 juni 2012 > 15:53 To: avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 > = > Hi, > = > This is my WG last call review as an individual. I think there is = > quite a lot to address before this document is ready for publication = > request. > = > 1. This document has 6 authors listed. This is one more than the = > policy allows: http://www.rfc-editor.org/policy.html#policy.authlist > = > RvB: See my other mail. > = > 2. Abstract: "This document gives information on an RTCP Packet Type = > and RTCP XR Block Type including associated SDP parameters for = > Inter-Destination Media Synchronization (IDMS)." > = > Doesn't it define these packet/block types? > = > RvB: We will change the abstract to reflect the contents more = > accurately. The draft defines the RTCP Packet Type and mandates the = > use of the ETSI-defined XR Block Type, which is included in the draft = > for sake of completeness. > = > 3. Section 3: > = > The ladder diagrams first line is wrongly indented. > = > RvB: OK. > = > 3. Section 3. Ladder diagram, maybe this diagram should have some = > handle, like figure 1 with a label. > = > RvB: OK. > = > 4. Section 3. I am missing discussion on the overview level of clocks. = > Yes it is present later, but I think the topic should be introduced = > already here is section 3. > = > RvB: Good idea. We will include a short section to discuss this. > = > 5. Section 6. I think this section should make it clear how an SC can = > include multiple report blocks for different received sources. In = > general I think this may be a topic that needs to be lifted into the = > overview. The issue I see is the following ones. > = > a) Within a multi-party communication session different media senders = > include different reference clocks. Thus creating multiple = > synchronization groups within the context of one multi-media = > communication session. > = > b) even if they can agree on using the same clock reference they still = > need to enable the fact that an end-point is acting as MSAS for some = > media sources and SC for others. This should be made more clear. > = > RvB: I agree that these are both valid scenarios. However, I'm not = > sure whether they pose a problem. In the case where an SC has to = > report on multiple groups, it will just send multiple report blocks = > (possibly concatenated using RTCP rules). Do I miss something here? No, I don't think they represent any significant issues. It just that I thi= nk it is worth pointing out that this is expected and that implementations = needs to handle such situations. Many implementors reads the spec and looks= at the examples and if it is not spelled out that these are valid cases th= ey might not implement to support them. > = > 6. Section 6 appears to be a normative definition of RTCP XR block = > type 12. That block type is registered by IANA as belonging to ETSI > 183 063 specification. Unless we have a formal liasion assigning the = > change right to IETF I don't see how we can make an updated normative = > specification of this XR block type. I see two options. > = > a) IETF are given the change right over the block type > = > b) IETF makes a normative reference to the ETSI specification of the = > block type and then simply makes it clear that they only uses SPST=3D1. > = > RvB: I fully agree with the problems of trying to change the = > specification. When starting this work, we have therefore decided to = > go for your route B). Ok, I have no issues with that, however it must be much more clear and expl= icit that the ETSI spec is the normative one. > = > 7. Section 6. Assuming that the normative definition will remain and = > possibly also as a clarification to the ETSI specification: This = > section is not making it sufficient clear that what an SC is supposed = > to do is to pick one RTP packet it recevied, then report the values = > for this particular packet. I think one should clarify this and also = > making it clearer what the selection criteria for such a packet is. > Should one focus on using maximum delayed packets, media delayed = > packets or simply random selection? In addition we have the rules = > about picking packets when multiple RTP sequence numbers have the same = > TS value. I would recommned that one add some paragraphs before the = > actual figure definition to discuss this. > = > RvB: Good point. In theory it shouldn't really matter. Up to now, we = > have been assuming random selection, just picking a packet when the = > RTCP rules allow you to send a report. I will check with my co-authors = > to see whether they still think this is good enough. I will come back = > to you on this one. Good > = > 8. Section 6, PT field definition. This is not making clear that one = > shall report the PT of the packet one is reporting on. > = > RvB: Ok. > = > 9. Section 6. Media Stream Correlation Identifier: 32 bits. This = > identifier is used to correlate synchronized media streams. The value = > 0 (all bits are set "0") indicates that this field is empty. > The value 2^32-1 (all bits are set "1") is reserved for future use. > If the RTCP Packet Sender is an SC (SPST=3D1) or an MSAS (SPST=3D2), then = > the Media Stream Correlation Identifier maps on the Synchronization = > Group Identifier (SyncGroupId) to which the report applies. > = > It is not clear what "maps" means here. Considering that the field = > appears to carry the full syncgroupID I think another formulation = > shall be used. > = > RvB: We will rephrase this paragraph to make it more clear. > = > 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in = > which a certain RTP timestamp shows up for the first time." > = > Does this means with the lowest sequence number or the packet first to = > arrive with that TS? > = > RvB: The lowest sequence. We will clarify this sentence. > = > 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)" > = > Why is the packet used to distribute the intended playout timing = > called a "report". This is very confusing considering that the XR is a = > report also. > = > RvB: Sorry, you're right. We'll come up with a better name. > = > 12. Section 7. > = > SSRC: 32 bits. The SSRC of the media source SHALL be set to the value = > of the SSRC identifier carried in the RTP header [RFC3550] of the RTP = > packet to which the RTCP IDMS packet relates. > = > First of all I assume this field definition is for "SSRC of media = > source" field. > = > RvB: Correct > = > a. What isn't clear is if it is at all valid that another SSRC "SSRC = > of packet sender" than the "SSRC of media source" is allowed and shall = > be considered valid. > = > RvB: We have always assumed the SSRC of Media Source scenario. Do you = > think there is a good reason to support 'SSRC of packet sender' as = > well? No, I don't have a use case in mind. This could be useful if one has a sepa= rate node taking care of determining a number of source should be played ou= t. At the same time I think it creates thorny security question etc. Today,= you can build the authorization to set the playout time on the media sourc= e. With this you get in addition to authenticating source you also need to = know that the third party setting the playout is authorized to do it on beh= alf of the media source. I would suggest to skip third party functionality = at this point. > = > b. Secondly, when an end-point has multiple sources in the same RTP = > session to send it appears they need to send multiple RTCP packets. > = > RvB: Do you mean a scenario where one source sends multiple RTP = > streams (e.g. audio and video). In that case, it is only necessary to = > do IDMS for one stream. The rest is lip-sync. The Media-level SDP part = > describes which stream to perform IDMS for. I will check with my = > co-authors whether they think it is useful to recommend either audio = > or video streams here for this purpose. Lets assume audio only RTP session. I can have two audio source. This means= that the end-point needs to set playout for both its sources or rely on li= p sync assuming they are using the same CNAME. I think this opens up to several aspects: a) The need to describe that you only need to actually provide playout time= for one SSRC within a synchronization context, i.e. the SSRC having the sa= me CNAME. I think this needs to be explicit that this can be done in this w= ay. I think you also needs to say what to do if I get playout times for two= SSRCs with the same CNAME and they don't match. This spans over both multi= ple RTP session and multiple SSRCs within a session. b) The next is that you will receive playout reports from all SSRCs an end-= point have in the session. Also here consistency is an important aspect, bu= t I would expect that especially the receive time report will jitter at the= same order of the transport jitter. > = > 13. Section 7. > = > It is not clear if there are any restrictions on the values to be = > included in the RTCP packet. Must the sender of it include information = > for a already sent packet, a future packet or can it even be a virtual = > packet that is never sent? > = > I understand that one can scale the figures in this packet to = > determine what the correct value should be given a received RTP packet = > and its timestamp. But, are I allowed to calculate a correct time = > value a year into the future that is then expected to be scaled back. = > Or is the RTP timestamp value included in the packet in itself an = > indication for when this information was current? > = > RvB: Good point. Because RTP timestamps wrap around, choosing a time = > far into future may cause problems. So indeed, the timestamp chosen = > needs to be a (relatively) current one. We will change the section to = > reflect this. > = > 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of = > SDP parameters for signaling the clock synchronization source or = > sources available to and used by the individual receivers. Using = > these paramenters, an SC can indicate which synchronization source is = > being used at the moment, the last time the SC synchronized with this = > source and the synchronization frequency. An SC can also indicate any = > other synchronization sources available to it. This allows multiple = > SCs in an IDMS session to use the same or a similar clock source for = > their session. > = > So the clksrc draft appear to indended to define the usage of a=3Dssrc = > to make it clear which clock source a particular SSRC uses. What isn't = > clear from this text is that when providing reporting that all nodes = > sending a report or a configuration must use their view of that = > particular clock source. I think the implications of having multiple = > clock sources in an RTP session must be made clearer. As the used = > clock comes into play both when configuring, reporting and adjusting = > time scales for playout. > = > RvB: I'm not completely following you here. The synchronization source = > mentioned here is a wall clock source (e.g. NTP), and not a media = > clock source. The reference to the clcksrc document is just to provide = > the reader with the means to perform clock synchronization (and thus = > improve the accuracy of IDMS). Does this help? Correct, I hadn't thought through this sufficiently. All SSRCs in one or mo= re RTP session using the same CNAME MUST use the same wall clock, i.e. same clksrc. If you have different ones you need to use different CNAMES. S= o it is actually CNAMES and clock sources that should be bound in the signa= lling. >From that perspective an end-point could use multiple CNAMES and thus have = different clock sources present in the same session. A prime example would = be a central node that forwards streams, but do not resynchronize them into= a single CNAME. Such an end-point would in an O/A SDP signalling have need= to express the different clock source for the other participants in the se= ssion. > = > 15. Section 9: > = > SyncGroupId =3D 1*DIGIT ; Numerical value from 0 through 4294967294 > = > As the syncgroupID is limited to 10 digits, why not make that clear in = > the ABNF also using 1*10DIGIT as the definition. > = > Applies also to Section 10. > = > RvB: Ok. > = > 16. Section 11. > = > As someone else noted. This section really needs to be split into = > Offer/Answer rules and one on TISPAN interop. > = > RvB: Agree. We will change this in the next iteration. > = > 16. Section 11. Offer/Answer rules It is not clear how one deals with = > the potential existence of multiple sync groups or how the ID is = > negotiated. Especially when you in a multi-party negotiate with an = > application server. > = > I also think it should make clear how it works in declarative cases, = > like RTSP SDPs. > = > RvB: We will take up this point in the new version (see previous = > comment). > = > 17. Section 14. > = > This IANA registration is insufficient. It needs to be more precise in = > which regestries that are to be used. > = > RvB: Ok. Thanks for you examples. > = > To my understand the following actions are required: > = > register a media level SDP attribute: This is okay considering the = > template but one could clarify that the registry intended is the one = > titled "att-field (media level only)" > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp- > parameters-9 > > = > = > One RTCP Control Packet types (PT): = > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp- > parameters-3 > > And if the XR block type is to be normatively defined by this = > document then two registrations are needed: > = > - New or update of RTCP XR Block Type = > http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-type > s.xml > > = - Add the XR SDP parameter: > http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-par > ameters.xml > > 18. References. Should [I-D.draft-gross-leap-second] be normative? = > It is not written in a RFC 2119 style an requirement to take this = > document into account, so maybe informative is correct. > = > RvB: I propose going for informative. The leap-second draft is just a = > way of increasing the accuracy of IDMS. And since it is meant as an = > update to RFC3550, can be considered part of RTCP and not specifically = > targeted at IDMS. I think that is fine. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ekr@rtfm.com Mon Jul 9 12:24:48 2012 Return-Path: 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 798A111E81CD for ; Mon, 9 Jul 2012 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 tbhuVhuDVDFP for ; Mon, 9 Jul 2012 12:24:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7E9611E81CB for ; Mon, 9 Jul 2012 12:24:47 -0700 (PDT) Received: by vcqp1 with SMTP id p1so8179307vcq.31 for ; Mon, 09 Jul 2012 12:25:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=gJ7xORnLplm+p91O1A1fnv/cu1Nh6JeD0gSLJznkVBo=; b=Zw/Fee2ckigQw4TI2J6NxiMVmtZzgSHT9hpcwZAN/Tj8el6mVeFa3tZgrooFh1CCP5 Ru+F5ROPdTwk/7KD2E5zRPoNUmW3qvqzc2IqJXJAcP+E9Gt8jN4wniTqeXlk3l5hx6di nxuHM2c6x0HVmK/B8vDmeaNW8pY9SHJ1MACLDKHmuiHLJiJoeiO+0K71omlHYni/Qdh9 u9tYCx1wA6jxSKJI/ZOpaHLIq5UUiDujdGdtzlQNhJfzhyyLTQ7jH+HHBkpeZ2/e8OMm P5aILAbultPwh6mCuHqhbMpZSx8zxB4dsm8w9a9CEmK/gJdZ6KSKl59t4siuh0MDgpQ+ IZIg== Received: by 10.52.93.133 with SMTP id cu5mr16769931vdb.125.1341861912853; Mon, 09 Jul 2012 12:25:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 9 Jul 2012 12:24:32 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 9 Jul 2012 12:24:32 -0700 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkfMwE8g/Rs0/DvRx8VUmdLBiD4tw+wY+cIyxel409gRA9OaZfVs0BUVZIC1jeHB3tpDyJW Cc: rtcweb@ietf.org Subject: [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:24:48 -0000 As discussed at the RTCWEB interim: Executive summary: use a CSPRNG to generate CNAMEs. -Ekr From internet-drafts@ietf.org Mon Jul 9 12:28:35 2012 Return-Path: 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 6143911E81F0; Mon, 9 Jul 2012 12:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, 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 hKIPz-0kwhNj; Mon, 9 Jul 2012 12:28:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD7311E81E7; Mon, 9 Jul 2012 12:28:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709192834.908.63769.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 12:28:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:28:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Encrypted Key Transport for Secure RTP Author(s) : David A. McGrew Dan Wing Kai Fischer Filename : draft-ietf-avtcore-srtp-ekt-00.txt Pages : 51 Date : 2012-07-09 Abstract: Encrypted Key Transport (EKT) is an extension to Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTP or SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP, and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Mon Jul 9 14:51:02 2012 Return-Path: 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 6B80B11E8114 for ; Mon, 9 Jul 2012 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 rQhcW5SlC4IB for ; Mon, 9 Jul 2012 14:51:01 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9B49111E80CD for ; Mon, 9 Jul 2012 14:51:01 -0700 (PDT) Received: (qmail 2613 invoked by uid 0); 9 Jul 2012 21:51:27 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 9 Jul 2012 21:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=bZ+tpgDLD/3QAUfrIeWlIcK0F+AhjY6Cyz0uvlCG4N4=; b=ckVbRLFVDTcIeYB9GNcbPJHwbgyZo+mNiqx2G84d1AuYnvl8XPZC9PvGZ0cVt4juas2XvTE7J2F/XWj887308JzS0fmAQSi0x7v2L7OI6o4c6hpFMc0pHUlaz1ATqKWz; Received: from [74.125.82.172] (port=42749 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SoLrb-0006Wm-5K; Mon, 09 Jul 2012 15:51:27 -0600 Received: by were53 with SMTP id e53so2497190wer.31 for ; Mon, 09 Jul 2012 14:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.100.133 with SMTP id ey5mr32835834wib.4.1341870684551; Mon, 09 Jul 2012 14:51:24 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Mon, 9 Jul 2012 14:51:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jul 2012 15:51:24 -0600 Message-ID: From: Kevin Gross To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0444ee277cbb5304c46c9d73 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:51:02 -0000 --f46d0444ee277cbb5304c46c9d73 Content-Type: text/plain; charset=ISO-8859-1 Good start. Please consider referencing to RFC 4086. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Jul 9, 2012 at 1:24 PM, Eric Rescorla wrote: > As discussed at the RTCWEB interim: > > > Executive summary: use a CSPRNG to generate CNAMEs. > > -Ekr > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d0444ee277cbb5304c46c9d73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good start.

Please consider referencing to RFC 4086.
Kevin Gross
+1-303-447-0517
Media Netw= ork Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Mon, Jul 9, 2012 at 1:24 PM, Eric Res= corla <ekr@rtfm.com> wrote:
As discussed at the RTCWEB interim:


Executive summary: use a CSPRNG to generate CNAMEs.

-Ekr
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d0444ee277cbb5304c46c9d73-- From ekr@rtfm.com Mon Jul 9 14:57:15 2012 Return-Path: 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 0F76A11E811E for ; Mon, 9 Jul 2012 14:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.778 X-Spam-Level: X-Spam-Status: No, score=-102.778 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 gnH9jfqQ-vTZ for ; Mon, 9 Jul 2012 14:57:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6FA11E8119 for ; Mon, 9 Jul 2012 14:57:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so8277660vbb.31 for ; Mon, 09 Jul 2012 14:57:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=zpDhK8dPp8asZqQTgTEQaTR8mkbzRfwNJZKb5jlIW1I=; b=fz8cwmQtfbc0snFbq4EK6g7mJ5cpWb9gqoxkn+7WMcgt9xF9FKRVfE2H4xbBNdiIj8 MhFCd3sJ/lNahzrzul2xqwi8QTNVC/6OwdblLh/CNcThgN0bXCob2GG84WTHdRuxgJD5 ui1otkznsf/GWEsE4D++L0RqonBDH9LoG1FPaEkIghfYT2PwyC9VrhFlRKBFCNIqTlXv vfMvDEd4N94MT1E0bdqrobSa0Yve1ohCWUZkJPwWEkG92t6ef1JSN5LJjDHycIpEJsGa bqpS0Dx5BPtAhG0Qu1Je7x63rA1RKuuELAGnUlhJSW6E3xj/SVoIeELjSPUn8Xf325E1 4nGA== Received: by 10.52.100.229 with SMTP id fb5mr16950250vdb.102.1341871059665; Mon, 09 Jul 2012 14:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 9 Jul 2012 14:56:59 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 9 Jul 2012 14:56:59 -0700 Message-ID: To: Kevin Gross Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkYagI2H2PS/uMS28J7Nt1p0hkWZyIblPLPW+9IZh/yhw2LaKE9vHQNJQy6b3S25mbRgIZy Cc: rtcweb@ietf.org, avt@ietf.org Subject: Re: [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 21:57:15 -0000 On Mon, Jul 9, 2012 at 2:51 PM, Kevin Gross wrote: > Good start. > > Please consider referencing to RFC 4086. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org > > > On Mon, Jul 9, 2012 at 1:24 PM, Eric Rescorla wrote: >> >> As discussed at the RTCWEB interim: >> >> >> Executive summary: use a CSPRNG to generate CNAMEs. >> >> -Ekr >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > I meant to. Turns out that RFC 4096 and RFC 4086 are not the same thing. Doh! -Ekr From internet-drafts@ietf.org Mon Jul 9 15:49:35 2012 Return-Path: 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 A2ACF11E80FA; Mon, 9 Jul 2012 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 ywh8tDcRQG4x; Mon, 9 Jul 2012 15:49:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0043811E80B3; Mon, 9 Jul 2012 15:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709224934.8726.44384.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 15:49:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 22:49:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-00.txt Pages : 28 Date : 2012-07-09 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This hetrogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From richard.ejzak@alcatel-lucent.com Mon Jul 9 20:17:26 2012 Return-Path: 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 4C18511E810A; Mon, 9 Jul 2012 20:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.819 X-Spam-Level: X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] 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 1zWMfyd9HPi4; Mon, 9 Jul 2012 20:17:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2041911E80F1; Mon, 9 Jul 2012 20:17:24 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6A3HnHq029685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jul 2012 05:17:49 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Jul 2012 05:17:49 +0200 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.33]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 9 Jul 2012 23:17:46 -0400 From: "Ejzak, Richard P (Richard)" To: "avt@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [AVTCORE][rtcweb] FYI: draft-ejzak-avtcore-rtp-subsessions-01 Thread-Index: Ac1eSpM99L5ReD5oSv+kGr/LQPeceQ== Date: Tue, 10 Jul 2012 03:17:46 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F17708794@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [AVTCORE] [rtcweb] FYI: draft-ejzak-avtcore-rtp-subsessions-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 03:17:26 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note that I submitted an 01 version of the RTP subsessions draft. T= his draft is revised extensively from 00 to focus on how it can enhance BUN= DLE to enable a network to identify multiplexed flows for differential trea= tment and how it can be used in relay topologies. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 09, 2012 10:09 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 1.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-01.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 01 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-07-10 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ejzak-avtcore-rt= p-subsessions-01.txt Status: http://datatracker.ietf.org/doc/draft-ejzak-avtcore-rtp-su= bsessions Htmlized: http://tools.ietf.org/html/draft-ejzak-avtcore-rtp-subsess= ions-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ejzak-avtcore-r= tp-subsessions-01 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and a means of representing this multiplexing option in SDP so that network nodes can easily identify groups of RTP streams and their associated RTCP packets for differential treatment as necessary. This mechanism can be used to complement the BUNDLE multiplexing scheme, which uses the grouping framework to identify all media lines associated with a single transport connection, but provides no means for network nodes to group RTP streams and their RTCP packets for differential treatment. RTP subsessions is an alternative to the SHIM multiplexing proposal; it clearly partitions packets associated with different media lines without changing the format of individual RTP and RTCP packets, but it does not maintain a completely independent SSRC space for each media line, as does SHIM. RTP subsessions avoid SSRC conflicts by construction and can be used in all RTP topologies in which all systems implement RTP subsessions, although SSRC mapping might be needed when forwarding RTP streams from an unpartitioned RTP session into an RTP subsession. The IETF Secretariat --_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please note that I submitted an 01 version of the RTP subsessions d= raft.  This draft is revised extensively from 00 to focus on how it ca= n enhance BUNDLE to enable a network to identify multiplexed flows for differential treatment and how i= t can be used in relay topologies.

 

Richard

 

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, July 09, 2012 10:09 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 1.txt

 

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-01.txt

has been successfully submitted by Richard Ejzak and posted to the<= o:p>

IETF repository.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   01

Title:          &= nbsp; Media multiplexing with Real-time Transport Protocol (RTP) subsession= s

Creation date:    2012-07-10

WG ID:          &= nbsp; Individual Submission

Number of pages: 14

URL:          &nb= sp;  http://www.ietf.org/internet-drafts/draft-ejzak-avtcore-rtp-subse= ssions-01.txt

Status:          http:= //datatracker.ietf.org/doc/draft-ejzak-avtcore-rtp-subsessions

Htmlized:        http://tools.ie= tf.org/html/draft-ejzak-avtcore-rtp-subsessions-01=

Diff:          &n= bsp; http://tools.ietf.org/rfcdiff?url2=3Ddraft-ejzak-avtcore-rtp-subsessio= ns-01

 

Abstract:

   This document describes a means of multiplexing RTP st= reams having

   different media types within a single transport connec= tion and a

   means of representing this multiplexing option in SDP = so that network

   nodes can easily identify groups of RTP streams and th= eir associated

   RTCP packets for differential treatment as necessary.&= nbsp; This mechanism

   can be used to complement the BUNDLE multiplexing sche= me, which uses

   the grouping framework to identify all media lines ass= ociated with a

   single transport connection, but provides no means for= network nodes

   to group RTP streams and their RTCP packets for differ= ential

   treatment.  RTP subsessions is an alternative to = the SHIM

   multiplexing proposal; it clearly partitions packets a= ssociated with

   different media lines without changing the format of i= ndividual RTP

   and RTCP packets, but it does not maintain a completel= y independent

   SSRC space for each media line, as does SHIM.  RT= P subsessions avoid

   SSRC conflicts by construction and can be used in all = RTP topologies

   in which all systems implement RTP subsessions, althou= gh SSRC mapping

   might be needed when forwarding RTP streams from an un= partitioned RTP

   session into an RTP subsession.

 

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

 

 

The IETF Secretariat

 

--_000_03FBA798AC24E3498B74F47FD082A92F17708794US70UWXCHMBA04z_-- From ron.even.tlv@gmail.com Tue Jul 10 07:59:04 2012 Return-Path: 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 9020F11E80EE for ; Tue, 10 Jul 2012 07:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 rZeNzRtbMLX2 for ; Tue, 10 Jul 2012 07:59:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7D11E808D for ; Tue, 10 Jul 2012 07:59:02 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so39254wgb.13 for ; Tue, 10 Jul 2012 07:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=5q+O621iXic6TOwjyO0p8RMFzp1ksQv5IZXLjN9F/r8=; b=QSJV/tboBrmc3zS+BmThh3nXkP8FiPqIXxD21J2pZ67YY8uB7IegOX45PEnSc4MUqL mOL3oMWoKYn1GHBjtPK/N+/EdpTda0l0870DiD9KXnyJmeG2CMuNkNBoheseqsK0t2PP TG3MKZCD3nBJTcZJSGSjz1FMohOfNBiglPQntD6hxMPGau9Yt/n3lN5USrTIoPKlFy6d 7ePqygqA0FqdJd7GE/4zrpSeq+ik6qVxQ7tsO5THqPLEeIMJOn8dl+EwnZl/YbXgAo4w x6hKlknvfY2RVSAzoxd6ATjAbwZnZdyXjt1+lB8Aq4nOdV7VgFsWDs8JuwhnW5oA/aDw 8dhQ== Received: by 10.180.14.34 with SMTP id m2mr38966329wic.22.1341932370307; Tue, 10 Jul 2012 07:59:30 -0700 (PDT) Received: from RoniE ([109.64.198.75]) by mx.google.com with ESMTPS id t7sm8014939wix.6.2012.07.10.07.59.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:59:29 -0700 (PDT) From: "Roni Even" To: Date: Tue, 10 Jul 2012 17:59:01 +0200 Message-ID: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01CD5EC5.B14D8BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxg== Content-Language: en-us Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:59:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01CD5EC5.B14D8BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Thanks to everyone who sent comments. I think we got a good number of WGLC reviews. The next step is for the editors to address the comments and update the document. Note that the July 16th is the cutoff date for document submission. We will also have time to discuss open issues in the AVTcore session in Vancouver Roni Even AVTcore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 17 June, 2012 6:05 PM To: 'avt@ietf.org' Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' Subject: WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_008B_01CD5EC5.B14D8BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

Thanks to everyone who = sent comments. I think we got a good number of WGLC reviews. The next = step is for the editors to address the comments and update the = document.

Note that the July 16th is the cutoff = date for document submission.

We will also have time = to discuss open issues in the AVTcore session in = Vancouver

 

Roni = Even

AVTcore co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 17 June, 2012 = 6:05 PM
To: 'avt@ietf.org'
Cc: = 'draft-ietf-avtcore-idms@tools.ietf.org'
Subject: WGLC on = draft-ietf-avtcore-idms-05

 

Hi,

I would =
like to start a WGLC on http://too=
ls.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for =
inter-destination media =
synchronization.
 =

The WGLC will = end on July 10th, 2012

 

Please = review the draft and send comments to the list.

 

For the =
draft authors;  Are you aware of any IPR that applies to =
draft-ietf-avtcore-idms-05? If so,
has this =
IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, =
4879, 3669 and 5378 for more details)?
The above =
question is needed for the document write-up when sent to =
publication.
 =

Thanks

 

Roni = Even

AVTcore =  co-chair

 

------=_NextPart_000_008B_01CD5EC5.B14D8BF0-- From mary.ietf.barnes@gmail.com Tue Jul 10 16:37:34 2012 Return-Path: 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 9C79011E80A4; Tue, 10 Jul 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 KCt17g5Apjgr; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5811E8087; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so649964obb.31 for ; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2eZAFEs9bEjwxfu6kVYXdKTRFE+RHAuVSMy079j8b/w=; b=kPwEeMxJX5zc/+6mwEa0OZ6umUlKlKFrLLET4PVA0CRANJZuy8fJcjSZmEy+DffeKP 2dmxv7ikOrIi7BA2MLnMNesyr1efQOfW67LqU0EVRQti51Agg27o4xOkvZeGFuGM6Jqi /BKPgmjssuQR5SCKqK4eyxhzW6qCs5V70MCcmU/qJSJkRIHAmAfVaRypb7H6kPpXyLJr AW6UerabPJw+sdKkIa71uqxer8wl4BkaUMjoHlu3/VdsXcvOr5MxsMUwjVJRVpXWUJuo 3LEOe7kmWKHbBRRR60eA/yFKQfhf3Abslm2szVLAlHp/GSo5jOVaKwGfov4Pr/8rPqZi 30lA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr1569393obc.1.1341963472177; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Date: Tue, 10 Jul 2012 18:37:52 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=14dae9399bad0f88a204c482380a Subject: [AVTCORE] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:37:34 -0000 --14dae9399bad0f88a204c482380a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Apologies to the many of you that are receiving this multiple times. Unfortunately, the RAI list is not a superset of participants in WGs that might be interested in this. Folks that aren't on the RAI list might want to subscribe here: https://www.ietf.org/mailman/listinfo/rai Please note the important update below with regards to (no) lunch. We are planning a lunchtime tutorial on Monday, July 30th. The primary objective is to provide more background on telepresence as well as an update of the work in CLUE to the broader RAI and IETF community. This will hopefully facilitate the process of completing the CLUE protocol work as it gets broader community review. Here's the proposed outline: 1) Introduction to telepresence 2) Example telepresence scenarios 3) Introduction to the CLUE work 4) High level introduction of framework 5) One or two use cases as examples of how the CLUE framework is realized - showing how existing protocols (e.g., SDP, RTP) are integral to the solution along with additional signaling for CLUE. We have reserved a room for around 50 and attendance will be FCFS, so please RSVP by Friday, July 13th, 2012 (5pm Pacific) http://www.doodle.com/mzu3nmdeehkxkiys **Important update*: * Please note that we do not have a sponsor for lunch, thus folks will have to grab something before the tutorial (sorry, I tried). However, we will have some cookies and veggies/fruit available so folks will have something to munch. Please send any questions/comments to me (or to the CLUE WG mailing list) rather than reply all. Regards, Mary CLUE WG co-chair --14dae9399bad0f88a204c482380a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important update*: =A0Please note that we do not have = a sponsor for lunch, thus folks will have to grab something before the tuto= rial (sorry, I tried). =A0However, we will have some cookies and veggies/fr= uit available so folks will have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair

--14dae9399bad0f88a204c482380a-- From csp@csperkins.org Wed Jul 11 04:59:34 2012 Return-Path: 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 D4BE921F8655 for ; Wed, 11 Jul 2012 04:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 fkeL4G5hSfHf for ; Wed, 11 Jul 2012 04:59:34 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D521F864F for ; Wed, 11 Jul 2012 04:59:33 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SovaN-0007Wc-nj; Wed, 11 Jul 2012 12:00:03 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 11 Jul 2012 13:00:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BA47368-02D8-46DD-8220-B97660A20E61@csperkins.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:59:35 -0000 [limiting replies to avt, since this is about details] On 9 Jul 2012, at 20:24, Eric Rescorla wrote: > As discussed at the RTCWEB interim: >=20 > Executive summary: use a CSPRNG to generate CNAMEs. Section 2.1 says: "The timestamp (from the RTP header) to within a few = seconds. With a typical 100 ticks/second clock, this represents about = 10 bits of entropy at most (and potentially more like 2-3 bits)". The = RTP timestamp has a random initial value, and typically ticks at either = 8kHz or 90kHz. It's not a wall clock. There's more entropy here than = supposed.=20 --=20 Colin Perkins http://csperkins.org/ From ekr@rtfm.com Wed Jul 11 07:51:34 2012 Return-Path: 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 D8ABD21F872A for ; Wed, 11 Jul 2012 07:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.794 X-Spam-Level: X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qlD+WkM-53kN for ; Wed, 11 Jul 2012 07:51:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98321F8724 for ; Wed, 11 Jul 2012 07:51:34 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so869273vbb.31 for ; Wed, 11 Jul 2012 07:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ePbtMmKYBY9/KVhMqDo611OXjkSnzaAx/Bcw879hAmE=; b=Edfuz6Iuf0k9qwre0xdBe6EEK0y6h7WCDAmhPkmgChpBs6ArbN1vfxothC1hMXce0V rM/Cg9jG6TOCQ1xM8BRbWN66Oozb7/ygoQPF8kiwJZsENeNcCJ7yho+Of/uMHua1D6QW NGYKNJc9j4VFvt6RRwJwzDMsYT+yhMEUV12+yGii6dTfzjHo/bbVudPnqRmCe51xtXxQ YUzD3Ub1e3P6cYfYv5pYvu6XJuSmfN6+1gMyS3lztj0trhLpPZt47U57RVSlaa2svWDr DDAiGhlPnFGbrAXw2BUJ8/T/5YPEF0kqmpiQoKb28OrmCe5kesiSVLI0TR63Z/66S67p EwuQ== Received: by 10.220.106.135 with SMTP id x7mr12223817vco.28.1342018324220; Wed, 11 Jul 2012 07:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 11 Jul 2012 07:51:24 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <2BA47368-02D8-46DD-8220-B97660A20E61@csperkins.org> References: <2BA47368-02D8-46DD-8220-B97660A20E61@csperkins.org> From: Eric Rescorla Date: Wed, 11 Jul 2012 07:51:24 -0700 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl/Xp9GxUZ7oPuBHSpdpaDWDTMPhIt5m9ou5ly35pzhuaC/PCCDonfb0B41X8PM9eJoST5F Cc: IETF AVTCore WG Subject: Re: [AVTCORE] FYI: draft-rescorla-random-cname-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:51:35 -0000 On Wed, Jul 11, 2012 at 5:00 AM, Colin Perkins wrote: > [limiting replies to avt, since this is about details] > > On 9 Jul 2012, at 20:24, Eric Rescorla wrote: >> As discussed at the RTCWEB interim: >> >> Executive summary: use a CSPRNG to generate CNAMEs. > > > Section 2.1 says: "The timestamp (from the RTP header) to within a few se= conds. With a typical 100 ticks/second clock, this represents about 10 bit= s of entropy at most (and potentially more like 2-3 bits)". The RTP timesta= mp has a random initial value, and typically ticks at either 8kHz or 90kHz.= It's not a wall clock. There's more entropy here than supposed. Sorry, RTCP NTP timestamp. -Ekr From woohwankim@gmail.com Sun Jul 15 22:48:11 2012 Return-Path: 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 C789821F8494 for ; Sun, 15 Jul 2012 22:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Qf5fWwa4Q3yZ for ; Sun, 15 Jul 2012 22:48:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C30EA21F8493 for ; Sun, 15 Jul 2012 22:48:10 -0700 (PDT) Received: by yenq13 with SMTP id q13so5113514yen.31 for ; Sun, 15 Jul 2012 22:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/Ti8pMRZdysrfN5LHPDrac+AxgE6lVMvB+HeDzin4Qg=; b=D+W4WIojKGA5Mi5nP764GocLcdcdQDO2XAi3BaB49Rj479A67Aai7hlxHA55LI3vMo mH2qqj37HPlncarsOtK1EGQOLgxgZGQnK9HwSrVFhvWg+x5h5qOiPJ4VnGmFuTOEYx4t I7D1k4qxEmgoy58uP/2lwzsWsxYEhswhXJincQovCQiKTISdtK2Bdzb9/i7L1xARxIs+ +AGQRB8A5VZ0GjNusIwwzpQPwXBE0w7ddjYhPRqf+Ft/1Ov+FjNrVBd3F7YNia2v7yY9 mXq5fytbSH5XntAiGas+gw0Nn2nXuee7UAnOS5biMM8L6TEgYo4E7TK3BYfFZPqTHA7m Zp6A== MIME-Version: 1.0 Received: by 10.50.186.196 with SMTP id fm4mr4384420igc.34.1342417733917; Sun, 15 Jul 2012 22:48:53 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.64.104.165 with HTTP; Sun, 15 Jul 2012 22:48:53 -0700 (PDT) Date: Mon, 16 Jul 2012 14:48:53 +0900 X-Google-Sender-Auth: UdobFCis_YpUR5cb0slulfC400c Message-ID: From: Woo-Hwan Kim To: avt@ietf.org, draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Content-Type: multipart/alternative; boundary=14dae9340fe72b9c3504c4ebfcd3 Cc: Daesung Kwon , Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 05:48:11 -0000 --14dae9340fe72b9c3504c4ebfcd3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi. Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-01. 1. typos and minors p.4 DTLS -> DTLS-SRTP p.8 ROS -> ROC p.11 the corresponding STRCP encrypted -> the corresponding SRTCP encrypted p.13 C_max -> C_MAX p.18 AEAD_AES_128_CCM -> AEAD_AES_128_GCM p.18 AEAD_AES_256_CCM -> AEAD_AES_256_GCM 2. On the CCM decryption In this draft, there is no separation between GCM and CCM except "Tag_Size_Flag=93. It means both modes have the same parameters (nonce length, counter block length etc.) and the same IV format (described in Sections 8.1 and 9.1). But that does not hold if the authors intend to apply the interfaces of CCM described in RFC 5116. For example, the counter block length parameter q is not 4 but 3 when the length of nonce is 12 octets. According to the InputFormatting Function proposed in NIST SP 800-38C (and referred by RFC 5116), Tag_Size_Flag recommended in this draft is derived when q=3D3. Note that such parameter is related to several AEAD parameters, and so a large portion of the draft should be revised. 3. CCM Tag Validation Section 5.3 says "The ciphertext MUST NOT be decrypted until the AEAD tag has been validated. The associated data MUST NOT be released until the AEAD tag has been validated." The above does not hold for CCM mode of operation, because it is required to decrypt ciphertext before confirming the validation of the AEAD tag. 4. Ciphertext length expansion for SRTP Section 9.2 says "Since the AEAD cipher is larger than the plaintext by exactly the length of the AEAD authentication tag, the corresponding STRCP encrypted packet replaces the plaintext field with a slightly larger field containing the cipher." Does this sentence only hold for SRTCP? 5. Input/output data for CCM (Sections 5.2.1 and 5.2.2) Both input and output data for CCM require Tag_Size_Flag, but that is the value which can be computed by three parameters (defined in NIST SP 800-38C). Because Tag_Size_Flag is not included in SRTP/SRTCP packets, the only way to share the same Tag_Size_Flag is to fix authentication tag length and counter block length in advance. Additionally, Section 5.2.1 says the only output of "Encrypt Mode" is "Ciphertext" with bit string length =3D legnth length(ciphertext)-tag_lengt= h. What is the difference between "ciphertext" and "Ciphertext". If length of the "Ciphertext" does not consider the length of "authentication tag", where is authentication tag? 6. CCM tag length specification Section 10.3 RFC5116 only defines AEAD_AES_128/256_CCM with 16 octets tag length. Section 13.2 "Note that these SRTP Protection Profiles do not specify an auth_function, auth_key_length, or auth_tag_length because all of these profiles use AEAD algorithms, and thus do not use a separate auth_function, auth_key, or auth_tag." In IANA AEAD registry, there is no entry for AEAD_AES_128/256_CCM_12. It means that there is no official reference for AES_CCM with 96-bit authentication tag. So it is required to define AEAD_AES_128/256_CCM_12 independently in this document, similar to AEAD_AES_128/256_CCM_8 defined for TLS usage(internet draft, AES-CCM Cipher Suites for TLS). For SDES, it may be necessary to add CCM-related crypto suites with 64- and 96-bit authentication tags. Thanks. Woo-Hwan Kim --14dae9340fe72b9c3504c4ebfcd3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi.

Here are some comments on the draft-ietf-= avtcore-srtp-aes-gcm-01.

1. typos and minors
=

p.4 DTLS -> DTLS-SRTP
p.8 ROS -> ROC
p.11 the corresponding STRCP encrypted -> the corresponding SRTCP e= ncrypted
p.13 C_max -> C_MAX
p.18 AEAD_AES_128_CCM -= > AEAD_AES_128_GCM
p.18 AEAD_AES_256_CCM -> AEAD_AES_256_GC= M

2. On the CCM decryption

In th= is draft, there is no separation between GCM and CCM except "Tag_Size_= Flag=93.=A0
It means both modes have the same parameters (nonce l= ength, counter block length etc.) and the same=A0IV format (described in Se= ctions 8.1 and 9.1).=A0
But that does not hold if the authors intend to apply the interfaces o= f CCM described in=A0RFC 5116.=A0
For example, the counter block = length parameter q is not 4 but 3 when the length of nonce=A0is 12 octets.= =A0

According to the InputFormatting Function proposed in N= IST SP 800-38C (and referred by RFC 5116),=A0
Tag_Size_Flag recom= mended in this draft is derived when q=3D3.=A0
Note that such par= ameter is related to=A0several AEAD parameters,=A0and so a large portion of= the draft should be revised.

3. CCM Tag Validation

Section = 5.3 says
"The ciphertext MUST NOT be decrypted until the AEA= D tag has been validated. The associated data
MUST NOT be release= d until the AEAD tag has been validated."

The above does not hold for CCM mode of operation,=A0
because it is required to decrypt ciphertext=A0before confirming t= he validation of the AEAD tag.

4. Ciphertext lengt= h expansion for SRTP

Section 9.2 says
"Since the AEAD cipher = is larger than the plaintext by exactly the length of the AEAD authenticati= on=A0
tag, the corresponding STRCP encrypted packet replaces the = plaintext field with a slightly larger=A0
field containing the cipher."

Does this = sentence only hold for SRTCP?

5. Input/output data= for CCM (Sections 5.2.1 and 5.2.2)

Both input and= output data for CCM require Tag_Size_Flag, but that is the value which can= be computed=A0
by three parameters (defined in NIST SP 800-38C). Because Tag_Size_Fla= g is not included in SRTP/SRTCP=A0
packets, the only way to share= the same Tag_Size_Flag is to fix authentication tag length and counter=A0<= /div>
block length in advance.

Additionally, Sectio= n 5.2.1 says the only output of "Encrypt Mode" is "Ciphertex= t" with bit string=A0length =3D legnth length(ciphertext)-tag_length.= =A0
What is the difference between "ciphertext" and=A0"Ciph= ertext". If length of the "Ciphertext" does not consider the= length of "authentication tag",=A0
where is authentica= tion tag?


6. CCM tag length specification

Section 10.3

RFC5116 only defines= AEAD_AES_128/256_CCM with 16 octets tag length.

Section 13.2

"Note that these SRTP Protection= Profiles do not specify an auth_function, auth_key_length, or=A0
auth_tag_length because all of these profiles use AEAD algorithms, and thu= s do not use a separate=A0auth_function, auth_key, or auth_tag."

In IANA AEAD registry, there is no entry for AEAD_AES_1= 28/256_CCM_12.=A0
It means that there is no=A0official reference = for AES_CCM with 96-bit authentication tag. So it is required to define=A0<= /div>
AEAD_AES_128/256_CCM_12 independently in this document, similar to AEA= D_AES_128/256_CCM_8 defined for=A0
TLS usage(internet draft, AES-= CCM Cipher Suites for TLS).=A0

For SDES, it may be= necessary to add CCM-related crypto suites with 64- and 96-bit authenticat= ion=A0tags.

Thanks.

Woo-Hwan Kim
--14dae9340fe72b9c3504c4ebfcd3-- From ray.vanbrandenburg@tno.nl Mon Jul 16 04:14:44 2012 Return-Path: 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 237FC21F86C2 for ; Mon, 16 Jul 2012 04:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 3JPK+pxGWdRs for ; Mon, 16 Jul 2012 04:14:42 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3F13321F878A for ; Mon, 16 Jul 2012 04:14:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,593,1336341600"; d="scan'208";a="72407989" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 16 Jul 2012 13:15:23 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 13:15:23 +0200 From: "Brandenburg, R. (Ray) van" To: Colin Perkins Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Thread-Index: Ac1MouWNdp+K0jkOQUKLCbWCw+ddRAJPZroAA1L3lmA= Date: Mon, 16 Jul 2012 11:15:22 +0000 Message-ID: References: <4fde00ba.8854b40a.5854.12a4@mx.google.com> <192F77F8-66E2-46B0-BE3C-F7B22CB72794@csperkins.org> In-Reply-To: <192F77F8-66E2-46B0-BE3C-F7B22CB72794@csperkins.org> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-avtcore-idms@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 11:14:44 -0000 Hi Colin, Thanks for your review. Sorry for not responding to you earlier. We took up= your comments in the next iteration of the draft (which I will upload late= r today), but I forgot to respond to your comments personally. = > - I don't believe RTCP is on the RFC Editor's list of approved acronyms f= or document titles, but RTP is, so I suggest changing the title of the draf= t to "Inter-destination Media Synchronisation Using the RTP Control Protoco= l (RTCP)". >- Acronyms also need expanding on first use in the abstract. >- Editorial: the draft might read better if the Section 1.1 heading were r= emoved, and if sub-sections 1.2, 1.3, and 1.4 were made part of a new Secti= on 2 "Rationale". >- Editorial: in Section 1.2, "scalable to large multicast networks" may be= better phrased "scalable to large groups" since the functionality is not m= ulticast specific. >- Section 3, near the end of page 6, the draft says "...when both Alice an= d Bob received (or played out) a particular RTP packet". This might be clea= rer written "when both Alice and Bob received (and, optionally, when they p= layed out) a particular RTP packet". = >- Section 3 doesn't seem to mention that Alice and Bob need synchronised c= locks for this to work. It probably should. Thanks for these points. We have included all of them in the next iteration. >- I find the justification for using a 32 bit NTP presentation timestamp i= n Section 6, but a 64 bit NTP presentation timestamp in Section 7 to be unc= onvincing. Could you either strengthen the justification, or move to a comm= on size? We will strengthen the justification. We had a lengthy discussion about thi= s on the mailing list sometime ago, but I agree that the way it is written = right now in the draft does not reflect the outcome of that discussion accu= rately. = - Section 6: is the PT field needed? The combination of RTP timestamp and S= SRC should identify a packet, even with changes in PT and clock rate. The PT field is necessary in cases where the MSAS is not a receiver of the = media stream. In order to do its job, it's necessary for the MSAS to have a= ccess to the clock rate. = >- Section 6, penultimate paragraph: "...in which a certain RTP timestamp s= hows up for the first time" is problematic, since the RTP timestamp can wra= p. = >- Section 8: "receiver involved need synchronised clocks" - yes, but be cl= ear what clock needs to be synchronised. The RTP-format media clocks don't = need to be synchronised, for example, while the NTP-format clock does. Ok. We will fix this in the next iteration. - Section 8, 3rd paragraph: is the use of the mechanism in draft-williams-a= vtcore-clksrc mandatory? It would be useful to make an RFC 2119 style recom= mendation here. True. Although I don't think it should be mandatory, and I think we should = go with MAY. - Section 8, last paragraph: should "...is therefore recommended to take th= e guidelines..." be "...RECOMMENDED..."? Yes. Best regards, Ray -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] = Sent: vrijdag 29 juni 2012 14:18 To: Roni Even Cc: avt@ietf.org; draft-ietf-avtcore-idms@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 Roni, I have some comments on this draft: - I don't believe RTCP is on the RFC Editor's list of approved acronyms for= document titles, but RTP is, so I suggest changing the title of the draft = to "Inter-destination Media Synchronisation Using the RTP Control Protocol = (RTCP)". - Acronyms also need expanding on first use in the abstract. - Editorial: the draft might read better if the Section 1.1 heading were re= moved, and if sub-sections 1.2, 1.3, and 1.4 were made part of a new Sectio= n 2 "Rationale". - Editorial: in Section 1.2, "scalable to large multicast networks" may be = better phrased "scalable to large groups" since the functionality is not mu= lticast specific. - Section 3, near the end of page 6, the draft says "...when both Alice and= Bob received (or played out) a particular RTP packet". This might be clear= er written "when both Alice and Bob received (and, optionally, when they pl= ayed out) a particular RTP packet". = - Section 3 doesn't seem to mention that Alice and Bob need synchronised cl= ocks for this to work. It probably should. - I find the justification for using a 32 bit NTP presentation timestamp in= Section 6, but a 64 bit NTP presentation timestamp in Section 7 to be unco= nvincing. Could you either strengthen the justification, or move to a commo= n size? - Section 6: is the PT field needed? The combination of RTP timestamp and S= SRC should identify a packet, even with changes in PT and clock rate. - Section 6, penultimate paragraph: "...in which a certain RTP timestamp sh= ows up for the first time" is problematic, since the RTP timestamp can wrap= . = - Section 8: "receiver involved need synchronised clocks" - yes, but be cle= ar what clock needs to be synchronised. The RTP-format media clocks don't n= eed to be synchronised, for example, while the NTP-format clock does. - Section 8, 3rd paragraph: is the use of the mechanism in draft-williams-a= vtcore-clksrc mandatory? It would be useful to make an RFC 2119 style recom= mendation here. - Section 8, last paragraph: should "...is therefore recommended to take th= e guidelines..." be "...RECOMMENDED..."? Colin On 17 Jun 2012, at 17:04, Roni Even wrote: > Hi, > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt= core-idms-05 , RTCP for inter-destination media synchronization. > = > The WGLC will end on July 10th, 2012 > = > Please review the draft and send comments to the list. > = > For the draft authors; Are you aware of any IPR that applies to = > draft-ietf-avtcore-idms-05? If so, has this IPR been disclosed in complia= nce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more detail= s)? > The above question is needed for the document write-up when sent to publi= cation. > = > Thanks > = > Roni Even > AVTcore co-chair > = > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org = > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From internet-drafts@ietf.org Mon Jul 16 05:57:58 2012 Return-Path: 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 027D821F8813; Mon, 16 Jul 2012 05:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.541 X-Spam-Level: X-Spam-Status: No, score=-98.541 tagged_above=-999 required=5 tests=[AWL=-3.918, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 Sq8f2yYf71pN; Mon, 16 Jul 2012 05:57:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79721F8816; Mon, 16 Jul 2012 05:57:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716125757.26028.68249.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 05:57:57 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 12:57:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-06.txt Pages : 24 Date : 2012-07-16 Abstract: This document gives information on an RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type including associated Session Description Protocol (SDP) parameters for Inter- Destination Media Synchronization (IDMS). This document mandates the use of the RTCP XR Block Type 12, which is used to collect media playout information from participants in a group playing out (watching, listening, etc.) a specific RTP media stream. This RTCP XR Block Type is specified and registered with IANA by ETSI. The RTCP packet type specified by this document is used to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ray.vanbrandenburg@tno.nl Mon Jul 16 06:03:12 2012 Return-Path: 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 D095921F84B9 for ; Mon, 16 Jul 2012 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 uZUVea4zWcDM for ; Mon, 16 Jul 2012 06:03:11 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE9221F84AF for ; Mon, 16 Jul 2012 06:03:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,594,1336341600"; d="scan'208,217";a="15790299" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 16 Jul 2012 15:03:53 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 15:03:53 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: WGLC on draft-ietf-avtcore-idms-05 - address comments Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxgEnn0bw Date: Mon, 16 Jul 2012 13:03:51 +0000 Message-ID: References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> In-Reply-To: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C64F9E9EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:03:13 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C64F9E9EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi All, First, I would like to thank all who performed a review of the document. Second, I have just uploaded a new version of the document (-06) which hope= fully addresses all of the comments we received during the WGLC process. http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 I'm not going to list all changes from the -05 version here (there are quit= e many of them), but you can find a diff here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 Best regards, Ray van Brandenburg From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: dinsdag 10 juli 2012 17:59 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments Hi Thanks to everyone who sent comments. I think we got a good number of WGLC = reviews. The next step is for the editors to address the comments and updat= e the document. Note that the July 16th is the cutoff date for document submission. We will also have time to discuss open issues in the AVTcore session in Van= couver Roni Even AVTcore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 17 June, 2012 6:05 PM To: 'avt@ietf.org' Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' Subject: WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf= -avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C64F9E9EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi All,

 

First, = I would like to thank all who performed a review of the document.

&n= bsp;

Second,= I have just uploaded a new version of the document (-06) which hopefully a= ddresses all of the comments we received during the WGLC process.

&n= bsp;

http://tools.ietf.org/html/draft-ietf= -avtcore-idms-06

 

I’= ;m not going to list all changes from the -05 version here (there are quite= many of them), but you can find a diff here:

&n= bsp;

http://tools.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-avtcore-idms-06

&n= bsp;

Best re= gards,


Ray van Brandenburg

&n= bsp;

&n= bsp;

&n= bsp;

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: dinsdag 10 juli 2012 17:59
To: avt@ietf.org
Cc: draft-ietf-avtcore-idms@tools.ietf.org
Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments

 

Hi=

Thanks = to everyone who sent comments. I think we got a good number of WGLC reviews= . The next step is for the editors to address the comments and update the d= ocument.

Note th= at the July 16th is the cutoff date for document submission.

We will= also have time to discuss open issues in the AVTcore session in Vancouver<= o:p>

&n= bsp;

Roni Ev= en

AVTcore= co-chair

&n= bsp;

From: Roni Even [= mailto:ron.even.tlv@gmail.com]
Sent: 17 June, 2012 6:05 PM
To: 'avt@ietf.org'
Cc: 'draft-ietf-avtcore-idms@tools.ietf.org'
Subject: WGLC on draft-ietf-avtcore-idms-05

 

Hi,

I would like to start a WGLC on http://tools.ietf.o=
rg/html/draft-ietf-avtcore-idms-05 , RT=
CP for inter-destination media synchronization.
 

The WGLC will end on July 10th, 20= 12

 

Please review the draft and sen= d comments to the list.

 

For the draft authors;  Are you aware=
 of any IPR that applies to draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance =
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?<=
o:p>
The above question is needed for the docum=
ent write-up when sent to publication.
 

Thanks

 

Roni Even

AVTcore  co-chair

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C64F9E9EXCMBX03tsntnon_-- From keith.drage@alcatel-lucent.com Mon Jul 16 06:48:41 2012 Return-Path: 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 AA8F221F8822 for ; Mon, 16 Jul 2012 06:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.018 X-Spam-Level: X-Spam-Status: No, score=-108.018 tagged_above=-999 required=5 tests=[AWL=-1.769, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 1L43m0XHJ4JR for ; Mon, 16 Jul 2012 06:48:40 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE1221F8815 for ; Mon, 16 Jul 2012 06:48:40 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6GDivfD028814 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Jul 2012 15:49:23 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 16 Jul 2012 15:49:15 +0200 From: "DRAGE, Keith (Keith)" To: "Brandenburg, R. (Ray) van" , "avt@ietf.org" Date: Mon, 16 Jul 2012 15:49:14 +0200 Thread-Topic: WGLC on draft-ietf-avtcore-idms-05 - address comments Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxgEnn0bwAAEXMPA= Message-ID: References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:48:41 -0000 I wrote on 28/06/2012: "I do notice that the IETF document and the ETSI document define one and th= e same XR block. Is there an intention that the ETSI document gets modified= to reference the IETF document when finally approved and published (i.e. t= hat the IETF document takes ownership and updates the existing registration= ? Or is there some other strategy for this block type?" >From the revisions of the document it appears that section 7 is now an info= rmative restatement of the ETSI document. The IANA registration remains wit= h ETSI, and there is no addition of a reference to this proposed RFC. So what is the proposed strategy now for the ETSI document? Does it get rev= ised to incorporate the rest of the material now normatively specified in t= his document, or does it ignore it? If the ETSI document is getting revised, why not transfer the normative spe= cification his RFC and then make reference to the whole of this RFC? I'd also note that I believe the IANA considerations section of this docume= nt could be more precisely stated. It needs to be clearer what rows are add= ed to the IANA tables and what are the contents of those rows. Specifically= , I am not sure how: " This document defines a new RTCP packet type called IDMS Settings packet in the IANA registry of RTP parameters, part of RTCP Control Packet types (PT), based on the specification in Section 11." gets interpreted by IANA, given that section 11 talks very little about thi= s new PT. When a value gets assigned, where are you going to write it in th= e specification, and where exactly does it appear in the coding? Keith ________________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: 16 July 2012 14:04 To: avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comment= s Hi All, First, I would like to thank all who performed a review of the document. Second, I have just uploaded a new version of the document (-06) which hope= fully addresses all of the comments we received during the WGLC process.=20 http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 I'm not going to list all changes from the -05 version here (there are quit= e many of them), but you can find a diff here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 Best regards, Ray van Brandenburg From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: dinsdag 10 juli 2012 17:59 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments Hi Thanks to everyone who sent comments. I think we got a good number of WGLC = reviews. The next step is for the editors to address the comments and updat= e the document. Note that the July 16th is the cutoff date for document submission.=20 We will also have time to discuss open issues in the AVTcore session in Van= couver Roni Even AVTcore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: 17 June, 2012 6:05 PM To: 'avt@ietf.org' Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' Subject: WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; =A0Are you aware of any IPR that applies to draft-ie= tf-avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore =A0co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From hans.stokking@tno.nl Mon Jul 16 07:11:28 2012 Return-Path: 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 A436D21F88B5 for ; Mon, 16 Jul 2012 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 FuLovuaif6yT for ; Mon, 16 Jul 2012 07:11:27 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1553621F88B2 for ; Mon, 16 Jul 2012 07:11:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,594,1336341600"; d="scan'208";a="15791659" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 16 Jul 2012 16:12:10 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.128]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 16:12:10 +0200 From: "Stokking, H.M. (Hans)" To: "DRAGE, Keith (Keith)" , "Brandenburg, R. (Ray) van" , "avt@ietf.org" Thread-Topic: WGLC on draft-ietf-avtcore-idms-05 - address comments Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxgEnn0bwAAEXMPAAAQ3TMA== Date: Mon, 16 Jul 2012 14:12:09 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D07695F5F@EXC-MBX01.tsn.tno.nl> References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:11:28 -0000 Dear Keith, On ETSI TISPAN status: TISPAN has officially been terminated by ETSI, so no= changes will be made by ETSI. We started in the IETF to continue the work = on IDMS that started within ETSI, but try to remain (backwards) compatible = as much as possible. We didn't think that an official transfer of the IANA = registration from ETSI to IETF was needed because the block type from ETSI = could be re-used. Within the IETF we did decide on a new packet type for th= e sync settings, hence a new registration was needed. On the reference to section 11, this is a typo in the document since at lea= st a few versions. Thanks for spotting this, we shall change this to sectio= n 8 (which does specify the new packet type). Section 8 does give the codin= g of the new packet type and defines the various fields. We will correct the reference in the next version, ok? We can also include = the row specification for IANA, I guess that's mostly abbreviation and name= , and for the new packet type I think the RFC Editor needs to fill in the P= T number before publication. We can put in a sentence (reminder) for that a= s well then. Best, Hans -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: maandag 16 juli 2012 15:49 To: Brandenburg, R. (Ray) van; avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comment= s I wrote on 28/06/2012: "I do notice that the IETF document and the ETSI document define one and th= e same XR block. Is there an intention that the ETSI document gets modified= to reference the IETF document when finally approved and published (i.e. t= hat the IETF document takes ownership and updates the existing registration= ? Or is there some other strategy for this block type?" >From the revisions of the document it appears that section 7 is now an info= rmative restatement of the ETSI document. The IANA registration remains wit= h ETSI, and there is no addition of a reference to this proposed RFC. So what is the proposed strategy now for the ETSI document? Does it get rev= ised to incorporate the rest of the material now normatively specified in t= his document, or does it ignore it? If the ETSI document is getting revised, why not transfer the normative spe= cification his RFC and then make reference to the whole of this RFC? I'd also note that I believe the IANA considerations section of this docume= nt could be more precisely stated. It needs to be clearer what rows are add= ed to the IANA tables and what are the contents of those rows. Specifically= , I am not sure how: " This document defines a new RTCP packet type called IDMS Settings packet in the IANA registry of RTP parameters, part of RTCP Control Packet types (PT), based on the specification in Section 11." gets interpreted by IANA, given that section 11 talks very little about thi= s new PT. When a value gets assigned, where are you going to write it in th= e specification, and where exactly does it appear in the coding? Keith ________________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: 16 July 2012 14:04 To: avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comment= s Hi All, First, I would like to thank all who performed a review of the document. Second, I have just uploaded a new version of the document (-06) which hope= fully addresses all of the comments we received during the WGLC process.=20 http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 I'm not going to list all changes from the -05 version here (there are quit= e many of them), but you can find a diff here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 Best regards, Ray van Brandenburg From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: dinsdag 10 juli 2012 17:59 To: avt@ietf.org Cc: draft-ietf-avtcore-idms@tools.ietf.org Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments Hi Thanks to everyone who sent comments. I think we got a good number of WGLC = reviews. The next step is for the editors to address the comments and updat= e the document. Note that the July 16th is the cutoff date for document submission.=20 We will also have time to discuss open issues in the AVTcore session in Van= couver Roni Even AVTcore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 17 June, 2012 6:05 PM To: 'avt@ietf.org' Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' Subject: WGLC on draft-ietf-avtcore-idms-05 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtco= re-idms-05 , RTCP for inter-destination media synchronization. The WGLC will end on July 10th, 2012 Please review the draft and send comments to the list. For the draft authors; =A0Are you aware of any IPR that applies to draft-ie= tf-avtcore-idms-05? If so, has this IPR been disclosed in compliance with I= ETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even AVTcore =A0co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Mon Jul 16 08:16:39 2012 Return-Path: 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 402B921F8672; Mon, 16 Jul 2012 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 j7Tn+zisqgfd; Mon, 16 Jul 2012 08:16:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA121F8680; Mon, 16 Jul 2012 08:16:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716151638.1813.47649.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 08:16:38 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:16:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Why RTP Does Not Mandate a Single Security Mechanism Author(s) : Colin Perkins Magnus Westerlund Filename : draft-ietf-avt-srtp-not-mandatory-09.txt Pages : 9 Date : 2012-07-16 Abstract: This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Mon Jul 16 08:58:40 2012 Return-Path: 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 46A0221F8682 for ; Mon, 16 Jul 2012 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.971 X-Spam-Level: X-Spam-Status: No, score=-103.971 tagged_above=-999 required=5 tests=[AWL=-5.698, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 ng9QVQ2-fjoQ for ; Mon, 16 Jul 2012 08:58:39 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2B021F8678 for ; Mon, 16 Jul 2012 08:58:38 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6GFxMkN024671 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Jul 2012 17:59:22 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 16 Jul 2012 17:59:22 +0200 From: "DRAGE, Keith (Keith)" To: "Stokking, H.M. (Hans)" , "Brandenburg, R. (Ray) van" , "avt@ietf.org" Date: Mon, 16 Jul 2012 17:59:21 +0200 Thread-Topic: WGLC on draft-ietf-avtcore-idms-05 - address comments Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxgEnn0bwAAEXMPAAAQ3TMAAD87KA Message-ID: References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> <7F110B3ECC623C4EADDEB82154F2693D07695F5F@EXC-MBX01.tsn.tno.nl> In-Reply-To: <7F110B3ECC623C4EADDEB82154F2693D07695F5F@EXC-MBX01.tsn.tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:58:40 -0000 ETSI TISPAN may be closed, but there is a new networks group in project E2N= A that takes over responsibility for the documents produced by ETSI TISPAN.= So in ETSI there is still the possibility of aligning with the new propose= d RFC. As regards the PT number, I suggest you discuss this with IANA (in conjunct= ion with the WG chairs) in Vancouver, and agree on a value which you put in= the next version. Regards Keith > -----Original Message----- > From: Stokking, H.M. (Hans) [mailto:hans.stokking@tno.nl] > Sent: 16 July 2012 15:12 > To: DRAGE, Keith (Keith); Brandenburg, R. (Ray) van; avt@ietf.org > Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments >=20 > Dear Keith, >=20 > On ETSI TISPAN status: TISPAN has officially been terminated by ETSI, so > no changes will be made by ETSI. We started in the IETF to continue the > work on IDMS that started within ETSI, but try to remain (backwards) > compatible as much as possible. We didn't think that an official transfer > of the IANA registration from ETSI to IETF was needed because the block > type from ETSI could be re-used. Within the IETF we did decide on a new > packet type for the sync settings, hence a new registration was needed. >=20 > On the reference to section 11, this is a typo in the document since at > least a few versions. Thanks for spotting this, we shall change this to > section 8 (which does specify the new packet type). Section 8 does give > the coding of the new packet type and defines the various fields. >=20 > We will correct the reference in the next version, ok? We can also includ= e > the row specification for IANA, I guess that's mostly abbreviation and > name, and for the new packet type I think the RFC Editor needs to fill in > the PT number before publication. We can put in a sentence (reminder) for > that as well then. >=20 > Best, Hans >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: maandag 16 juli 2012 15:49 > To: Brandenburg, R. (Ray) van; avt@ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address > comments >=20 > I wrote on 28/06/2012: >=20 > "I do notice that the IETF document and the ETSI document define one and > the same XR block. Is there an intention that the ETSI document gets > modified to reference the IETF document when finally approved and > published (i.e. that the IETF document takes ownership and updates the > existing registration? Or is there some other strategy for this block > type?" >=20 > From the revisions of the document it appears that section 7 is now an > informative restatement of the ETSI document. The IANA registration > remains with ETSI, and there is no addition of a reference to this > proposed RFC. >=20 > So what is the proposed strategy now for the ETSI document? Does it get > revised to incorporate the rest of the material now normatively specified > in this document, or does it ignore it? >=20 > If the ETSI document is getting revised, why not transfer the normative > specification his RFC and then make reference to the whole of this RFC? >=20 > I'd also note that I believe the IANA considerations section of this > document could be more precisely stated. It needs to be clearer what rows > are added to the IANA tables and what are the contents of those rows. > Specifically, I am not sure how: >=20 > " This document defines a new RTCP packet type called IDMS Settings > packet in the IANA registry of RTP parameters, part of RTCP Control > Packet types (PT), based on the specification in Section 11." >=20 > gets interpreted by IANA, given that section 11 talks very little about > this new PT. When a value gets assigned, where are you going to write it > in the specification, and where exactly does it appear in the coding? >=20 > Keith >=20 > ________________________________________ > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Brandenburg, R. (Ray) van > Sent: 16 July 2012 14:04 > To: avt@ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address > comments >=20 > Hi All, >=20 > First, I would like to thank all who performed a review of the document. >=20 > Second, I have just uploaded a new version of the document (-06) which > hopefully addresses all of the comments we received during the WGLC > process. >=20 > http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 >=20 > I'm not going to list all changes from the -05 version here (there are > quite many of them), but you can find a diff here: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 >=20 > Best regards, >=20 > Ray van Brandenburg >=20 >=20 >=20 > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: dinsdag 10 juli 2012 17:59 > To: avt@ietf.org > Cc: draft-ietf-avtcore-idms@tools.ietf.org > Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments >=20 > Hi > Thanks to everyone who sent comments. I think we got a good number of WGL= C > reviews. The next step is for the editors to address the comments and > update the document. > Note that the July 16th is the cutoff date for document submission. > We will also have time to discuss open issues in the AVTcore session in > Vancouver >=20 > Roni Even > AVTcore co-chair >=20 > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 17 June, 2012 6:05 PM > To: 'avt@ietf.org' > Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' > Subject: WGLC on draft-ietf-avtcore-idms-05 >=20 > Hi, > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf- > avtcore-idms-05 , RTCP for inter-destination media synchronization. >=20 > The WGLC will end on July 10th, 2012 >=20 > Please review the draft and send comments to the list. >=20 > For the draft authors; =A0Are you aware of any IPR that applies to draft- > ietf-avtcore-idms-05? If so, has this IPR been disclosed in compliance > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)= ? > The above question is needed for the document write-up when sent to > publication. >=20 > Thanks >=20 > Roni Even > AVTcore =A0co-chair >=20 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Mon Jul 16 09:14:31 2012 Return-Path: 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 04E2211E809F; Mon, 16 Jul 2012 09:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 SbXI1q2BMl1p; Mon, 16 Jul 2012 09:14:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84111E8089; Mon, 16 Jul 2012 09:14:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716161430.1423.49055.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 09:14:30 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:14:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Encryption of Header Extensions in the Secure Real-Time = Transport Protocol (SRTP) Author(s) : Jonathan Lennox Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt Pages : 15 Date : 2012-07-16 Abstract: The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-Time Transport Protocol specification, to require that all SRTP encryption transforms specify how RTP header extensions are to be encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header-e= xt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-encrypted-head= er-ext-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jonathan@vidyo.com Mon Jul 16 09:29:12 2012 Return-Path: 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 AB06711E8099 for ; Mon, 16 Jul 2012 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 gsXupG-qXVi7 for ; Mon, 16 Jul 2012 09:29:11 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0E11E8072 for ; Mon, 16 Jul 2012 09:29:11 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8C225A666BE for ; Mon, 16 Jul 2012 12:09:04 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A32B4A670A3 for ; Mon, 16 Jul 2012 12:02:39 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 16 Jul 2012 12:23:31 -0400 From: Jonathan Lennox To: IETF AVTCore WG Date: Mon, 16 Jul 2012 12:23:30 -0400 Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt Thread-Index: Ac1jb1QOQayLTwuoQTOvFJuIbrjLbg== Message-ID: <1CE19D48-D51A-4AB1-96BD-56F11B09D7BC@vidyo.com> References: <20120716161430.1423.49055.idtracker@ietfa.amsl.com> In-Reply-To: <20120716161430.1423.49055.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:29:12 -0000 Hello, all -- This revision of the draft incorporates comments received during WGLC. The main change in this version of the draft is that it now normatively upd= ates RFC 3711 (SRTP), to state that all future SRTP encryption transforms M= UST specify how they're to be used with header extension encryption. The draft now also specifically defines how it's used with SEED (RFC 5669),= as well as the NULL cipher. There aren't any technical changes to the header extension mechanism, thoug= h there are a number of clarifications. See Appendix B.1 for a full change= log. On Jul 16, 2012, at 12:14 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Core Maintenance W= orking Group of the IETF. >=20 > Title : Encryption of Header Extensions in the Secure Real-Tim= e Transport Protocol (SRTP) > Author(s) : Jonathan Lennox > Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-02.txt > Pages : 15 > Date : 2012-07-16 >=20 > Abstract: > The Secure Real-Time Transport Protocol (SRTP) provides > authentication, but not encryption, of the headers of Real-Time > Transport Protocol (RTP) packets. However, RTP header extensions may > carry sensitive information for which participants in multimedia > sessions want confidentiality. This document provides a mechanism, > extending the mechanisms of SRTP, to selectively encrypt RTP header > extensions in SRTP. >=20 > This document updates RFC 3711, the Secure Real-Time Transport > Protocol specification, to require that all SRTP encryption > transforms specify how RTP header extensions are to be encrypted. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header= -ext >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-0= 2 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-encrypted-he= ader-ext-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 -- Jonathan Lennox jonathan@vidyo.com From internet-drafts@ietf.org Mon Jul 16 15:56:29 2012 Return-Path: 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 424B011E810B; Mon, 16 Jul 2012 15:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 Cxorx6cnVDnW; Mon, 16 Jul 2012 15:56:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E72711E809B; Mon, 16 Jul 2012 15:56:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716225628.19170.74671.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:56:28 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:56:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Congestion Control: Circuit Breakers for Unicast Ses= sions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-01.txt Pages : 15 Date : 2012-07-16 Abstract: The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; rather, it defines a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow is expected to stop transmiting media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation. Any future RTP congestion control specification is expected to operate within the envelope defined by these circuit breakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breakers There's also a htmlized version available at: http://tools.ietf.org/html/draft-perkins-avtcore-rtp-circuit-breakers-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-perkins-avtcore-rtp-circuit-brea= kers-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Mon Jul 16 16:03:43 2012 Return-Path: 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 BBE9C11E80BE for ; Mon, 16 Jul 2012 16:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qtC48oDuII23 for ; Mon, 16 Jul 2012 16:03:41 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5F211E8085 for ; Mon, 16 Jul 2012 16:03:41 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SquL3-0006Nm-ou; Mon, 16 Jul 2012 23:04:25 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Colin Perkins Date: Tue, 17 Jul 2012 00:04:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120716225628.19170.74671.idtracker@ietfa.amsl.com> To: IETF AVTCore WG X-Mailer: Apple Mail (2.1278) Cc: rtp-congestion@alvestrand.no Subject: [AVTCORE] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:03:43 -0000 This is a minor update only, primarily to update the version of the TCP = throughput equation used, and to clarify a few points raised at the last = meeting. A more significant update can be expected later in the summer. Colin Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-01.txt > Date: 16 July 2012 23:56:28 GMT+01:00 > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : RTP Congestion Control: Circuit Breakers for = Unicast Sessions > Author(s) : Colin Perkins > Varun Singh > Filename : = draft-perkins-avtcore-rtp-circuit-breakers-01.txt > Pages : 15 > Date : 2012-07-16 >=20 > Abstract: > The Real-time Transport Protocol (RTP) is widely used in telephony, > video conferencing, and telepresence applications. Such = applications > are often run on best-effort UDP/IP networks. If congestion control > is not implemented in the applications, then network congestion will > deteriorate the user's multimedia experience. This document does = not > propose a congestion control algorithm; rather, it defines a minimal > set of "circuit-breakers". Circuit-breakers are conditions under > which an RTP flow is expected to stop transmiting media to protect > the network from excessive congestion. It is expected that all RTP > applications running on best-effort networks will be able to run > without triggering these circuit breakers in normal operation. Any > future RTP congestion control specification is expected to operate > within the envelope defined by these circuit breakers. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breaker= s >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-perkins-avtcore-rtp-circuit-breakers-01 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-perkins-avtcore-rtp-circuit-bre= akers-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 Colin Perkins http://csperkins.org/ From ray.vanbrandenburg@tno.nl Tue Jul 17 00:06:01 2012 Return-Path: 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 33AE511E809C for ; Tue, 17 Jul 2012 00:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.202 X-Spam-Level: **** X-Spam-Status: No, score=4.202 tagged_above=-999 required=5 tests=[AWL=-3.270, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 q1ohBeOyuOP0 for ; Tue, 17 Jul 2012 00:06:00 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAAD11E8083 for ; Tue, 17 Jul 2012 00:05:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,599,1336341600"; d="scan'208";a="72484233" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 17 Jul 2012 09:06:44 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 09:06:44 +0200 From: "Brandenburg, R. (Ray) van" To: "DRAGE, Keith (Keith)" , "Stokking, H.M. (Hans)" , "avt@ietf.org" Thread-Topic: WGLC on draft-ietf-avtcore-idms-05 - address comments Thread-Index: Ac1etFUOFjqjUBYJTLiRQmYWXu1dxgEnn0bwAAEXMPAAAQ3TMAAD87KAAB+1vfA= Date: Tue, 17 Jul 2012 07:06:43 +0000 Message-ID: References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> <7F110B3ECC623C4EADDEB82154F2693D07695F5F@EXC-MBX01.tsn.tno.nl> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Deventer, M.O. \(Oskar\) van" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 07:06:01 -0000 Hi Keith, Yes, you're right, E2NA has taken over the responsibilities of TISPAN. Howe= ver, while theoretically possible, in practice it is almost impossible to g= et E2NA to open up the current document even for fixing up some typos, let = alone changing its contents.=20 As for the PT number: good idea, I will discuss this with IANA in Vancouver= .=20 Ray -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: maandag 16 juli 2012 17:59 To: Stokking, H.M. (Hans); Brandenburg, R. (Ray) van; avt@ietf.org Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments ETSI TISPAN may be closed, but there is a new networks group in project E2N= A that takes over responsibility for the documents produced by ETSI TISPAN.= So in ETSI there is still the possibility of aligning with the new propose= d RFC. As regards the PT number, I suggest you discuss this with IANA (in conjunct= ion with the WG chairs) in Vancouver, and agree on a value which you put in= the next version. Regards Keith > -----Original Message----- > From: Stokking, H.M. (Hans) [mailto:hans.stokking@tno.nl] > Sent: 16 July 2012 15:12 > To: DRAGE, Keith (Keith); Brandenburg, R. (Ray) van; avt@ietf.org > Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments >=20 > Dear Keith, >=20 > On ETSI TISPAN status: TISPAN has officially been terminated by ETSI,=20 > so no changes will be made by ETSI. We started in the IETF to continue=20 > the work on IDMS that started within ETSI, but try to remain=20 > (backwards) compatible as much as possible. We didn't think that an=20 > official transfer of the IANA registration from ETSI to IETF was=20 > needed because the block type from ETSI could be re-used. Within the=20 > IETF we did decide on a new packet type for the sync settings, hence a ne= w registration was needed. >=20 > On the reference to section 11, this is a typo in the document since=20 > at least a few versions. Thanks for spotting this, we shall change=20 > this to section 8 (which does specify the new packet type). Section 8=20 > does give the coding of the new packet type and defines the various field= s. >=20 > We will correct the reference in the next version, ok? We can also=20 > include the row specification for IANA, I guess that's mostly=20 > abbreviation and name, and for the new packet type I think the RFC=20 > Editor needs to fill in the PT number before publication. We can put=20 > in a sentence (reminder) for that as well then. >=20 > Best, Hans >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > DRAGE, Keith (Keith) > Sent: maandag 16 juli 2012 15:49 > To: Brandenburg, R. (Ray) van; avt@ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address=20 > comments >=20 > I wrote on 28/06/2012: >=20 > "I do notice that the IETF document and the ETSI document define one=20 > and the same XR block. Is there an intention that the ETSI document=20 > gets modified to reference the IETF document when finally approved and=20 > published (i.e. that the IETF document takes ownership and updates the=20 > existing registration? Or is there some other strategy for this block=20 > type?" >=20 > From the revisions of the document it appears that section 7 is now an=20 > informative restatement of the ETSI document. The IANA registration=20 > remains with ETSI, and there is no addition of a reference to this=20 > proposed RFC. >=20 > So what is the proposed strategy now for the ETSI document? Does it=20 > get revised to incorporate the rest of the material now normatively=20 > specified in this document, or does it ignore it? >=20 > If the ETSI document is getting revised, why not transfer the=20 > normative specification his RFC and then make reference to the whole of t= his RFC? >=20 > I'd also note that I believe the IANA considerations section of this=20 > document could be more precisely stated. It needs to be clearer what=20 > rows are added to the IANA tables and what are the contents of those rows= . > Specifically, I am not sure how: >=20 > " This document defines a new RTCP packet type called IDMS Settings > packet in the IANA registry of RTP parameters, part of RTCP Control > Packet types (PT), based on the specification in Section 11." >=20 > gets interpreted by IANA, given that section 11 talks very little=20 > about this new PT. When a value gets assigned, where are you going to=20 > write it in the specification, and where exactly does it appear in the co= ding? >=20 > Keith >=20 > ________________________________________ > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Brandenburg, R. (Ray) van > Sent: 16 July 2012 14:04 > To: avt@ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address=20 > comments >=20 > Hi All, >=20 > First, I would like to thank all who performed a review of the document. >=20 > Second, I have just uploaded a new version of the document (-06) which=20 > hopefully addresses all of the comments we received during the WGLC=20 > process. >=20 > http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 >=20 > I'm not going to list all changes from the -05 version here (there are=20 > quite many of them), but you can find a diff here: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 >=20 > Best regards, >=20 > Ray van Brandenburg >=20 >=20 >=20 > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: dinsdag 10 juli 2012 17:59 > To: avt@ietf.org > Cc: draft-ietf-avtcore-idms@tools.ietf.org > Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments >=20 > Hi > Thanks to everyone who sent comments. I think we got a good number of=20 > WGLC reviews. The next step is for the editors to address the comments=20 > and update the document. > Note that the July 16th is the cutoff date for document submission. > We will also have time to discuss open issues in the AVTcore session=20 > in Vancouver >=20 > Roni Even > AVTcore co-chair >=20 > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 17 June, 2012 6:05 PM > To: 'avt@ietf.org' > Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' > Subject: WGLC on draft-ietf-avtcore-idms-05 >=20 > Hi, > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf- > avtcore-idms-05 , RTCP for inter-destination media synchronization. >=20 > The WGLC will end on July 10th, 2012 >=20 > Please review the draft and send comments to the list. >=20 > For the draft authors; =A0Are you aware of any IPR that applies to=20 > draft- ietf-avtcore-idms-05? If so, has this IPR been disclosed in=20 > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for mo= re details)? > The above question is needed for the document write-up when sent to=20 > publication. >=20 > Thanks >=20 > Roni Even > AVTcore =A0co-chair >=20 > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer=20 > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Tue Jul 17 13:30:44 2012 Return-Path: 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 4851021F8532 for ; Tue, 17 Jul 2012 13:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 BoFQAgG6ic9C for ; Tue, 17 Jul 2012 13:30:43 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id E94EA11E8072 for ; Tue, 17 Jul 2012 13:30:42 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SrEQb-0002Xt-WP; Tue, 17 Jul 2012 20:31:30 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C11C6BB-326A-4451-AC4B-EE473C696DFD" From: Colin Perkins In-Reply-To: Date: Tue, 17 Jul 2012 21:31:25 +0100 Message-Id: References: <008a01cd5eb4$edc3f8a0$c94be9e0$@gmail.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1278) Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:30:44 -0000 --Apple-Mail=_0C11C6BB-326A-4451-AC4B-EE473C696DFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ray, This addresses the comments I made on the earlier version. Thanks, Colin On 16 Jul 2012, at 14:03, Brandenburg, R. (Ray) van wrote: > Hi All, > =20 > First, I would like to thank all who performed a review of the = document. > =20 > Second, I have just uploaded a new version of the document (-06) which = hopefully addresses all of the comments we received during the WGLC = process. > =20 > http://tools.ietf.org/html/draft-ietf-avtcore-idms-06 > =20 > I=92m not going to list all changes from the -05 version here (there = are quite many of them), but you can find a diff here: > =20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-06 > =20 > Best regards, >=20 > Ray van Brandenburg > =20 > =20 > =20 > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: dinsdag 10 juli 2012 17:59 > To: avt@ietf.org > Cc: draft-ietf-avtcore-idms@tools.ietf.org > Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments > =20 > Hi > Thanks to everyone who sent comments. I think we got a good number of = WGLC reviews. The next step is for the editors to address the comments = and update the document. > Note that the July 16th is the cutoff date for document submission. > We will also have time to discuss open issues in the AVTcore session = in Vancouver > =20 > Roni Even > AVTcore co-chair > =20 > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: 17 June, 2012 6:05 PM > To: 'avt@ietf.org' > Cc: 'draft-ietf-avtcore-idms@tools.ietf.org' > Subject: WGLC on draft-ietf-avtcore-idms-05 > =20 > Hi, > I would like to start a WGLC on = http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for = inter-destination media synchronization. > =20 > The WGLC will end on July 10th, 2012 > =20 > Please review the draft and send comments to the list. > =20 > For the draft authors; Are you aware of any IPR that applies to = draft-ietf-avtcore-idms-05? If so, > has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details)? > The above question is needed for the document write-up when sent to = publication. > =20 > Thanks > =20 > Roni Even > AVTcore co-chair > =20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_0C11C6BB-326A-4451-AC4B-EE473C696DFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 
I would like to start a WGLC on RTCP for inter-destination media =
synchronization.
The WGLC =
will end on July 10th, 2012
For the =
draft authors;  Are you aware of any IPR that applies to =
draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance with IETF IPR =
rules (see RFCs 3979, 4879, 3669 and 5378 for more =
details)?
The above =
question is needed for the document write-up when sent to =
publication.
Thanks

This e-mail and = its contents are subject to the DISCLAIMER at avt@ietf.org



Colin Perkins


= --Apple-Mail=_0C11C6BB-326A-4451-AC4B-EE473C696DFD-- From ron.even.tlv@gmail.com Tue Jul 17 13:39:22 2012 Return-Path: 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 0452921F8644 for ; Tue, 17 Jul 2012 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Vm0nOpXJ3p3i for ; Tue, 17 Jul 2012 13:39:21 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B121F8627 for ; Tue, 17 Jul 2012 13:39:20 -0700 (PDT) Received: by weyu54 with SMTP id u54so607173wey.31 for ; Tue, 17 Jul 2012 13:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=UdE+KX4sbIAfEG2MuEOe8xjesxkSqIg9QMvzpHJsGb8=; b=h81kV7M1EjIxLhIoCW2j9kWcdv8kgR05flYhhghOCl7yGhH98GumuF2xxs0jQj+6YI c3HBUQiX0d8QOasKXAZkNQic424XO1FwNT1kWQcLJydVs7kH3rCjdidOMHfUgMvQTZaY dUWttm1ONq/Mp8xRgTaLiW2UaofYIUholA5AK9IRlBIH8qd4/WNkzjGJns2oCjKNnBNT hZMJDUXULuUX1Ab5EfsdYDzgBpo8aMolBcowoHAdilfVHPD3yy6VCHAuwia0fiZCafEv 6kAjQSZXu7dcc1A+VaOgImk2y22zL7d3u1sN9qwyI13B1p12jhd55Z2nJDtVRgf+Eo3N 6iiQ== Received: by 10.180.19.169 with SMTP id g9mr547162wie.9.1342557608317; Tue, 17 Jul 2012 13:40:08 -0700 (PDT) Received: from RoniE (bzq-79-176-214-12.red.bezeqint.net. [79.176.214.12]) by mx.google.com with ESMTPS id o2sm42634068wiz.11.2012.07.17.13.40.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 13:40:07 -0700 (PDT) From: "Roni Even" To: Date: Tue, 17 Jul 2012 23:39:26 +0200 Message-ID: <016201cd6464$a4968ed0$edc3ac70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0163_01CD6475.681FACF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1kZGSQcUnWlkUjTi6BmFEqKyddJg== Content-Language: en-us Subject: [AVTCORE] Proposed AVTcore agenda for IETF84 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:39:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0163_01CD6475.681FACF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0164_01CD6475.681FACF0" ------=_NextPart_001_0164_01CD6475.681FACF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The proposed agenda is in http://www.ietf.org/proceedings/84/agenda/agenda-84-avtcore Attached is the txt version of the agenda. Please let the chairs know if you have any comments Thanks Roni Even AVTcore co-chair ------=_NextPart_001_0164_01CD6475.681FACF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The proposed = agenda is in http= ://www.ietf.org/proceedings/84/agenda/agenda-84-avtcore =

Attached is the txt version of the = agenda.

Please let the chairs know if = you have any comments

 

Thanks

Roni = Even

AVTcore = co-chair

------=_NextPart_001_0164_01CD6475.681FACF0-- ------=_NextPart_000_0163_01CD6475.681FACF0 Content-Type: text/plain; name="a1207.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="a1207.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Magnus Westerlund Roni Even AGENDA Thursday, 2 August 2012 at 15:10-17:10 (Regency E) -------------------------------------------------- 15:10 AVTCore Status Update (Chairs, 15) 15:25 Random Algorithm for RTP CNAME generation (Eric Rescorla, 15) draft-rescorla-avtcore-random-cname-00 15:40 RTP Multiplexing Architecture (Magnus Westerlund , 15) draft-westerlund-avtcore-multiplex-architecture-02 15:55 Multiple RTP Session on a Single Lower-Layer Transport(Magnus = Westerlund , 20) draft-westerlund-avtcore-transport-multiplexing-03 16:15 RTP Considerations for Endpoints sending multiple media = streams(Jonathan Lennox, 20) draft-lennox-avtcore-rtp-multi-stream-00 16:35 Multiple Media type in an RTP session (Magnus Westerlund , 20) draft-westerlund-avtcore-multi-media-rtp-session-00 16:55 Media Multiplexing with RTP subsessions (Richard Ejzak, 15) draft-ejzak-avtcore-rtp-subsessions-01 17:10 End Friday, 3 August 2012 at 11:20-12:20 (Regency E) ------------------------------------------------ 11:20 Encrypted Key Transport for Secure RTP (Dan Wing, 20) draft-ietf-avtcore-srtp-ekt-00 11:40 RTCP for inter-destination media synchronization(Ray van = Brandenburg, 20) draft-ietf-avtcore-idms-06 12:00 RTP Clock Source Signalling (Kevin Gross, 10) draft-ietf-avtcore-clksrc-00 12:10 RTP and Leap Second (Kevin Gross, 10) draft-ietf-avtcore-leap-second-00 12:20 End ------=_NextPart_000_0163_01CD6475.681FACF0-- From magnus.westerlund@ericsson.com Wed Jul 18 13:14:07 2012 Return-Path: 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 A29C321F87C3 for ; Wed, 18 Jul 2012 13:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ejmSNsIRBC+X for ; Wed, 18 Jul 2012 13:14:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DABAA21F87B3 for ; Wed, 18 Jul 2012 13:14:05 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-9e-5007193ff5b8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 08.F1.15286.F3917005; Wed, 18 Jul 2012 22:14:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Wed, 18 Jul 2012 22:14:55 +0200 Message-ID: <5007193E.3090800@ericsson.com> Date: Wed, 18 Jul 2012 22:14:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: avt@ietf.org References: <4FF16412.8080909@ericsson.com> In-Reply-To: <4FF16412.8080909@ericsson.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/mixed; boundary="------------040006070204040600040700" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvra69JHuAwa4dJhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY0PnD6aCxwkVn26tZWtgPBHdxcjBISFgInHmoGgXIyeQKSZx 4d56NhBbSOAUo8T1pzZdjFxA9nJGiV8nGhlB6nkFtCWWTg8HqWERUJWYOv0RWD2bgIXEzR+N YLaoQKDEt63HWUFsXgFBiZMzn7CA2CICAhIrtv8Fs4UFnCQWvjzCArFLW+LJjQ5GEJtTQEfi 2MHfjBCnSUrcPpACEmYWCJDofbSPCaa8oamDdQKjwCwkG2YhKYOw9SSmXG1hhLDlJZq3zmae BTSVWSBFYvZ5J4iwosSU7ofsEHa4xOa2N2wLGNlXMQrnJmbmpJcb6aUWZSYXF+fn6RWnbmIE hvXBLb9VdzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy2Pns1 JzL/EWRpDV8m9/zeo8hwHzkt4bIHguUz/p6f33BHoLX/t7ofp8idj28PPZqmG7KfXVwtYEGG j1Qd9+5dTnNrHjl2cfa9CvtmbnEkMPZjUe2vzwUTjp92d53u+02B70payhWlKrkzQuxr0vmZ DVKyXm99nvnKzeSrTOvyE1M+HOg9GKLEUpyRaKjFXFScCADsuL4fOQIAAA== Subject: Re: [AVTCORE] Next step for draft-ietf-avtcore-monarch-17 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:14:07 -0000 --------------040006070204040600040700 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit WG, I have written a new document writeup, attached. I have requested that Robert continues with his AD processing of the document at this point. Cheers Magnus On 2012-07-02 11:04, Magnus Westerlund wrote: > WG, > > I am personally happy with the latest changes in this document. > > Glen suggested that this document should change status to BCP. That > would clearly raise the documents status from "this is our thinking of > how it should work" to "this is how you shall do it". > > If that is what the WG think we should do, then I am happy to execute on > that. People who think it should be a BCP please provide input in the > next week, i.e. no later than the 9th of July. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------040006070204040600040700 Content-Type: text/plain; charset="windows-1252"; name="writeup-draft-ietf-avtcore-monarch-17.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="writeup-draft-ietf-avtcore-monarch-17.txt" V3JpdGV1cCBmb3IgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMTcNCg0KDQooMSkgV2hh dCB0eXBlIG9mIFJGQyBpcyBiZWluZyByZXF1ZXN0ZWQgKEJDUCwgUHJvcG9zZWQgU3RhbmRh cmQsDQpJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkNCmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9mIFJGQz8gIElz IHRoaXMgdHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZQ0KdGl0bGUgcGFnZSBoZWFkZXI/ DQoNCkluZm9ybWF0aW9uYWwNCg0KDQooMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2Vt ZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50DQpXcml0ZS1VcC4gUGxlYXNl IHByb3ZpZGUgc3VjaCBhIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4gUmVjZW50 DQpleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNlbWVudHMg Zm9yIGFwcHJvdmVkDQpkb2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29u dGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczoNCg0KVGVjaG5pY2FsIFN1bW1hcnkNCg0K ICAgVGhpcyBtZW1vIHByb3Bvc2VzIGFuIGFyY2hpdGVjdHVyZSBmb3IgZXh0ZW5kaW5nIFJU UCBDb250cm9sIFByb3RvY29sDQogICAoUlRDUCkgd2l0aCBhIG5ldyBSVENQIEV4dGVuZGVk IFJlcG9ydHMgKFhSKSAoUkZDMzYxMSkgYmxvY2sgdHlwZSB0bw0KICAgcmVwb3J0IG5ldyBt ZXRyaWNzIHJlZ2FyZGluZyBtZWRpYSB0cmFuc21pc3Npb24gb3IgcmVjZXB0aW9uIHF1YWxp dHksDQogICBmb2xsb3dpbmcgUlRDUCBndWlkZWxpbmUgZXN0YWJsaXNoZWQgaW4gUkZDNTk2 OC4gIFRoaXMgbWVtbyBzdWdnZXN0cw0KICAgdGhhdCBhIG5ldyBibG9jayBzaG91bGQgY29u dGFpbiBhIHNpbmdsZSBtZXRyaWMgb3IgYSBzbWFsbCBudW1iZXIgb2YNCiAgIG1ldHJpY3Mg cmVsZXZhbnQgdG8gYSBzaW5nbGUgcGFyYW1ldGVyIG9mIGludGVyZXN0IG9yIGNvbmNlcm4s IHJhdGhlcg0KICAgdGhhbiBjb250YWluaW5nIGEgbnVtYmVyIG9mIG1ldHJpY3Mgd2hpY2gg YXR0ZW1wdCB0byBwcm92aWRlIGZ1bGwNCiAgIGNvdmVyYWdlIG9mIGFsbCB0aG9zZSBwYXJh bWV0ZXJzIG9mIGNvbmNlcm4gdG8gYSBzcGVjaWZpYw0KICAgYXBwbGljYXRpb24uICBBcHBs aWNhdGlvbnMgbWF5IHRoZW4gIm1peCBhbmQgbWF0Y2giIHRvIGNyZWF0ZSBhIHNldA0KICAg b2YgYmxvY2tzIHdoaWNoIGNvdmVycyB0aGVpciBzZXQgb2YgY29uY2VybnMuICBXaGVyZSBw b3NzaWJsZSwgYQ0KICAgc3BlY2lmaWMgYmxvY2sgc2hvdWxkIGJlIGRlc2lnbmVkIHRvIGJl IHJlLXVzYWJsZSBhY3Jvc3MgbW9yZSB0aGFuDQogICBvbmUgYXBwbGljYXRpb24sIGZvciBl eGFtcGxlLCBmb3IgYWxsIG9mIHZvaWNlLCBzdHJlYW1pbmcgYXVkaW8gYW5kDQogICB2aWRl by4NCg0KV29ya2luZyBHcm91cCBTdW1tYXJ5DQoNCiAgVGhpcyBkb2N1bWVudCBoYXMgYmVl biBqb2ludGx5IGxhc3QgY2FsbGVkIHdpdGggWFJCTE9DSyBXRyBvbmUgb2YgDQogIHRoZSBw cmltYXJ5IGNvbnN1bWVyIG9mIHRoZXNlIGFyY2hpdGVjdHVyYWwgY29uc2lkZXJhdGlvbnMu IA0KDQpEb2N1bWVudCBRdWFsaXR5DQoNCiAgVGhlcmUgYXJlIG9uZ29pbmcgdXNhZ2Ugb2Yg dGhlIGFyY2hpdGVjdHVyYWwgcHJpbmNpcGxlcyBkZXNjcmliZWQgaW4gDQogIHRoaXMgZG9j dW1lbnQgd2l0aGluIHRoZSBYUkJMT0NLIFdHLiBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gcmV2 aWV3ZWQgDQogIGJ5IGEgbnVtYmVyIG9mIHBlb3BsZSBpbiBib3RoIEFWVENPUkUgYW5kIFhS QkxPQ0sgV0cuIA0KICANClBlcnNvbm5lbA0KDQogIE1hZ251cyBXZXN0ZXJsdW5kIGlzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZCBhbmQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgDQogIERpcmVj dG9yIGlzIFJvYmVydCBTcGFya3MNCiAgDQogIA0KKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhl IHJldmlldyBvZiB0aGlzIGRvY3VtZW50IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ0KdGhlIERv Y3VtZW50IFNoZXBoZXJkLiAgSWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBu b3QgcmVhZHkNCmZvciBwdWJsaWNhdGlvbiwgcGxlYXNlIGV4cGxhaW4gd2h5IHRoZSBkb2N1 bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG8NCnRoZSBJRVNHLg0KDQpUaGUgc2hlcGhlcmQg cmV2aWV3ZWQgdGhlIGRvY3VtZW50IHZlcnkgY2FyZWZ1bGx5IGluIHZlcnNpb24gLTA5IHBy aW9yIHRvIA0KdGhlIFdHIGxhc3QgY2FsbC4gSGUgaGFzIHNpbmNlIHJldmlld2VkIHRoZSBj aGFuZ2VzIHdpdGggZWFjaCBuZXcgdmVyc2lvbi4gDQpUaGUgV0cgbGFzdCBjYWxsIGFuZCB0 aGUgY2hhbmdlcyBhZnRlciB0aGUgV0cgbGFzdCBjYWxsIGhhcyBiZWVuIHZlcmlmaWVkIA0K d2l0aCB0aGUgV0cgYmVmb3JlIHJlcXVlc3RpbmcgcHVibGljYXRpb24uIFRodXMgdGhlIHNo ZXBoZXJkIGJlbGlldmVzIHRoZSANCmRvY3VtZW50IHRvIGJlIHJlYWR5LiANCg0KDQooNCkg RG9lcyB0aGUgZG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgdGhl IGRlcHRoIG9yDQpicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZv cm1lZD8gDQoNCk5vLCB0aGlzIGRvY3VtZW50IGhhcyBnb3R0ZW4gcmVhc29uYWJseSBnb29k IGxldmVscyBvZiByZXZpZXcuIA0KDQooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50 IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20NCmJyb2FkZXIgcGVyc3Bl Y3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21wbGV4aXR5LCBBQUEsIERO UywNCkRIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IElmIHNvLCBkZXNjcmli ZSB0aGUgcmV2aWV3IHRoYXQNCnRvb2sgcGxhY2UuDQoNCk5vIHNwZWNpYWwgcmV2aWV3IGhh cyB0YWtlbiBwbGFjZSBiZXlvbmQgdGhlIG9uZSBmcm9tIFhSQkxPQ0sgV0cgYXMgdGhlDQpt YWluIGNvbnN1bWVycyBvZiB0aGUgZG9jdW1lbnQuIA0KDQoNCig2KSBEZXNjcmliZSBhbnkg c3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNoZXBoZXJk DQpoYXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGly ZWN0b3IgYW5kL29yIHRoZQ0KSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxl LCBwZXJoYXBzIGhlIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlDQp3aXRoIGNlcnRhaW4gcGFy dHMgb2YgdGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFs bHkNCmlzIGEgbmVlZCBmb3IgaXQuIEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNj dXNzZWQgdGhvc2UgaXNzdWVzIGFuZA0KaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdp c2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlDQpjb25jZXJucyBo ZXJlLg0KDQpObyBjb25jZXJucy4gDQoNCg0KKDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJt ZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFINCmRpc2Nsb3N1cmVzIHJlcXVp cmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4 DQphbmQgQkNQIDc5IGhhdmUgYWxyZWFkeSBiZWVuIGZpbGVkLiBJZiBub3QsIGV4cGxhaW4g d2h5Lg0KDQpZZXMsIHRoZSBzaGVwaGVyZCBoYXMgY29uZmlybWVkIHdpdGggYWxsIGF1dGhv cnMuIA0KDQoNCig4KSBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUgYmVlbiBmaWxlZCB0aGF0IHJl ZmVyZW5jZXMgdGhpcyBkb2N1bWVudD8NCklmIHNvLCBzdW1tYXJpemUgYW55IFdHIGRpc2N1 c3Npb24gYW5kIGNvbmNsdXNpb24gcmVnYXJkaW5nIHRoZSBJUFINCmRpc2Nsb3N1cmVzLg0K DQpObyBJUFIgZGlzY2xvc3VyZXMuDQoNCg0KKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29u c2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KcmVwcmVzZW50IHRoZSBz dHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdpdGggb3RoZXJzDQpi ZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQg YWdyZWUgd2l0aCBpdD8gICANCg0KSXQgaXMgZmFpcmx5IHdpZGUgY29uc2Vuc3VzIHdpdGgg Y2xlYXJseSByZXZpZXcgZnJvbSBtb3JlIGluZGl2aWR1YWxzIA0KdGhhbiBqdXN0IHRoZSB1 c3VhbCBzdXNwZWN0cy4gDQoNCigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVh bCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgDQpkaXNjb250ZW50PyBJZiBzbywg cGxlYXNlIHN1bW1hcmlzZSB0aGUgYXJlYXMgb2YgY29uZmxpY3QgaW4gc2VwYXJhdGUNCmVt YWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hv dWxkIGJlIGluIGENCnNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJl IGlzIHB1YmxpY2x5IGF2YWlsYWJsZS4pIA0KDQpOby4NCg0KKDExKSBJZGVudGlmeSBhbnkg SUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMNCmRvY3Vt ZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBhbmQgdGhlIElu dGVybmV0LURyYWZ0cw0KQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZSBub3Qg ZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlDQp0aG9yb3VnaC4NCg0KSUQtbml0cyB0 b29sIGxpc3RzIG5vIGlzc3Vlcy4gVGhlcmUgZXhpc3QgbWVudGlvbmluZyBpbiB0aGUgYWJz dHJhY3Qgb2YgDQpib3RoIFJGQzM2MTEgYW5kIFJGQzU5Njggd2hpY2ggY291bGQgYmUgY29u c2lkZXJlZCBjaXRhdGlvbnMuDQoNCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBt ZWV0cyBhbnkgcmVxdWlyZWQgZm9ybWFsIHJldmlldw0KY3JpdGVyaWEsIHN1Y2ggYXMgdGhl IE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0KDQpObyBm b3JtYWwgcmV2aWV3IHJlcXVpcmVkIGZvciB0aGlzIGRvY3VtZW50LiANCg0KDQooMTMpIEhh dmUgYWxsIHJlZmVyZW5jZXMgd2l0aGluIHRoaXMgZG9jdW1lbnQgYmVlbiBpZGVudGlmaWVk IGFzDQplaXRoZXIgbm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPw0KDQpPbmx5IGluZm9ybWF0 aXZlIHJlZmVyZW5jZXMgdXNlZC4gDQoNCg0KKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJl ZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCByZWFkeSBmb3INCmFkdmFuY2Vt ZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaCBub3Jt YXRpdmUNCnJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIHBsYW4gZm9yIHRoZWlyIGNv bXBsZXRpb24/DQoNCk5vIG5vcm1hdGl2ZSByZWZlcmVuY2VzLiANCg0KKDE1KSBBcmUgdGhl cmUgZG93bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAz OTY3KT8NCklmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9y dCB0aGUgQXJlYSBEaXJlY3RvciBpbiB0aGUNCkxhc3QgQ2FsbCBwcm9jZWR1cmUuDQoNCk5v LiANCg0KKDE2KSBXaWxsIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRo ZSBzdGF0dXMgb2YgYW55DQpleGlzdGluZyBSRkNzPyBBcmUgdGhvc2UgUkZDcyBsaXN0ZWQg b24gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyLCBsaXN0ZWQNCmluIHRoZSBhYnN0cmFjdCwgYW5k IGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90DQps aXN0ZWQgaW4gdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4cGxhaW4gd2h5LCBh bmQgcG9pbnQgdG8gdGhlDQpwYXJ0IG9mIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUgcmVsYXRp b25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlDQpvdGhlciBSRkNzIGlzIGRpc2N1c3Nl ZC4gSWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgaW4gdGhlIGRvY3VtZW50LA0KZXhwbGFp biB3aHkgdGhlIFdHIGNvbnNpZGVycyBpdCB1bm5lY2Vzc2FyeS4NCg0KTm8gY2hhbmdlIHRv IG90aGVyIGRvY3VtZW50cyBhbHJlYWR5IHB1Ymxpc2hlZC4gDQoNCigxNykgRGVzY3JpYmUg dGhlIERvY3VtZW50IFNoZXBoZXJkJ3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRp b25zDQpzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBjb25zaXN0ZW5j eSB3aXRoIHRoZSBib2R5IG9mIHRoZQ0KZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJv dG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVudCBtYWtlcw0KYXJlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmll cy4NCkNvbmZpcm0gdGhhdCBhbnkgcmVmZXJlbmNlZCBJQU5BIHJlZ2lzdHJpZXMgaGF2ZSBi ZWVuIGNsZWFybHkNCmlkZW50aWZpZWQuIENvbmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElB TkEgcmVnaXN0cmllcyBpbmNsdWRlIGENCmRldGFpbGVkIHNwZWNpZmljYXRpb24gb2YgdGhl IGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3RyeSwgdGhhdA0KYWxsb2NhdGlvbnMg cHJvY2VkdXJlcyBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmluZWQsIGFuZCBh DQpyZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnkgaGFzIGJlZW4gc3VnZ2Vz dGVkIChzZWUgUkZDIDUyMjYpLg0KDQpBcyB0aGlzIGRvY3VtZW50IGRvZXNuJ3QgZGVmaW5l IGFueSBwcm90b2NvbCwgbm9yIHJlZ2lzdHJ5IGV0YyB0aGVyZSBpcw0Kbm8gbmVlZCBmb3Ig YW55IElBTkEgYWN0aW9ucy4NCg0KDQooMTgpIExpc3QgYW55IG5ldyBJQU5BIHJlZ2lzdHJp ZXMgdGhhdCByZXF1aXJlIEV4cGVydCBSZXZpZXcgZm9yIGZ1dHVyZQ0KYWxsb2NhdGlvbnMu IFByb3ZpZGUgYW55IHB1YmxpYyBndWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQN CnVzZWZ1bCBpbiBzZWxlY3RpbmcgdGhlIElBTkEgRXhwZXJ0cyBmb3IgdGhlc2UgbmV3IHJl Z2lzdHJpZXMuDQoNCk5vbmUuIA0KDQooMTkpIERlc2NyaWJlIHJldmlld3MgYW5kIGF1dG9t YXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRoZSBEb2N1bWVudA0KU2hlcGhlcmQgdG8gdmFs aWRhdGUgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IHdyaXR0ZW4gaW4gYSBmb3JtYWwNCmxh bmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywg ZXRjLg0KDQpObyBmb3JtYWwgbGFuZ3VhZ2Uu --------------040006070204040600040700-- From iesg-secretary@ietf.org Thu Jul 19 13:00:01 2012 Return-Path: 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 F034621F8772; Thu, 19 Jul 2012 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, 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 Zkxh8whL-vkD; Thu, 19 Jul 2012 13:00:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1421F8655; Thu, 19 Jul 2012 13:00:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120719200000.30476.64089.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2012 13:00:00 -0700 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Guidelines for Use of the RTP Monitoring Framework) to Informational RFC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:00:01 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Guidelines for Use of the RTP Monitoring Framework' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo proposes an extensible RTP monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ballot/ No IPR declarations have been submitted directly on this I-D. From ietf-ipr@ietf.org Fri Jul 20 09:52:22 2012 Return-Path: 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 29D4A11E807F; Fri, 20 Jul 2012 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, 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 1lL0o9hO9+uL; Fri, 20 Jul 2012 09:52:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571D221F85E1; Fri, 20 Jul 2012 09:52:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: abegen@cisco.com, zeevvax@microsoft.com, Tom.Van_Caenegem@alcatel-lucent.be X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> Date: Fri, 20 Jul 2012 09:52:15 -0700 Cc: avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 16:52:22 -0000 Dear Ali Begen, Zeev Vax, Tom Van Caenegem: An IPR disclosure that pertains to your RFC entitled "Unicast-Based Rapid Acquisition of Multicast RTP Sessions" (RFC6285) was submitted to the IETF Secretariat on 2012-07-19 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1830/). The = title of the IPR disclosure is "Microsoft Corporation's Statement about IPR relat= ed to RFC 6285.""); The IETF Secretariat From ietf-ipr@ietf.org Fri Jul 20 10:21:41 2012 Return-Path: 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 CCBA821F852A; Fri, 20 Jul 2012 10:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 j2ekenAVOqbS; Fri, 20 Jul 2012 10:21:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A221F850B; Fri, 20 Jul 2012 10:21:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: anderskl@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120720172141.27684.75774.idtracker@ietfa.amsl.com> Date: Fri, 20 Jul 2012 10:21:41 -0700 Cc: avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 4425 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:21:42 -0000 Dear Anders Klemets: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format f= or Video Codec 1 (VC-1)" (RFC4425) was submitted to the IETF Secretariat on 2012-07-19 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1831/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to RFC 4425.""); The IETF Secretariat From staywiredvs@gmail.com Fri Jul 20 10:30:12 2012 Return-Path: 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 8988A21F8587; Fri, 20 Jul 2012 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 nLMprczTZnX6; Fri, 20 Jul 2012 10:30:12 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8621F8564; Fri, 20 Jul 2012 10:30:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4637689ggn.31 for ; Fri, 20 Jul 2012 10:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=90gNlHZMqs0evCTINfpqsztAPL6AHPNzf7x/LA5lqd0=; b=RAoMNCIBq41XmVcNHYxAE4039H439HR2AYbjRcyds3Yq78mQvJpGwhbi2TXaD9f5MP IEz3Mxd2CFUGY/aKFRcjsC998s3dO3XSi6a/Yrd/xBvJDJtQfr4sQv0YhuYi7FjjWYOh 6ieYj1dDmpN7FyHZvWqH7rynuhPIDXcHQ/skgWh4MjtI/MoPNzFmeu76QV6zZrKx68NU eF+kEcxvGDers0yTiM9BaDjxtoWi3RymczifUi9DvYJWt04j7ecn3SxWjPBDxGj79TBA KXQZFcx1IlS0orL8nU4R1fL4GrRUe4cpQXfFg3ZR/HlZndKZl6g0Hmj/az3L7iRMPXKP MPxg== Received: by 10.50.10.201 with SMTP id k9mr5143690igb.28.1342805467830; Fri, 20 Jul 2012 10:31:07 -0700 (PDT) Received: from [25.44.225.105] ([74.198.164.233]) by mx.google.com with ESMTPS id qo3sm9852185igc.8.2012.07.20.10.31.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2012 10:31:06 -0700 (PDT) References: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> In-Reply-To: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Jason | Staywired Video Solutions Inc Date: Fri, 20 Jul 2012 13:31:01 -0400 To: IETF Secretariat X-Mailman-Approved-At: Sat, 21 Jul 2012 08:51:33 -0700 Cc: "avt@ietf.org" , "Tom.Van_Caenegem@alcatel-lucent.be" , "zeevvax@microsoft.com" , "ipr-announce@ietf.org" Subject: Re: [AVTCORE] [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:30:12 -0000 Interesting :) Sent from a Staywired Video Solutions Inc. iPhone On 2012-07-20, at 12:52 PM, IETF Secretariat wrote: >=20 > Dear Ali Begen, Zeev Vax, Tom Van Caenegem: >=20 > An IPR disclosure that pertains to your RFC entitled "Unicast-Based Rapid > Acquisition of Multicast RTP Sessions" (RFC6285) was submitted to the IETF > Secretariat on 2012-07-19 and has been posted on the "IETF Page of Intelle= ctual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1830/). The= title > of the IPR disclosure is "Microsoft Corporation's Statement about IPR rela= ted to > RFC 6285.""); >=20 > The IETF Secretariat >=20 > _______________________________________________ > ipr-announce mailing list > ipr-announce@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-announce From magnus.westerlund@ericsson.com Mon Jul 23 04:29:01 2012 Return-Path: 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 DBBEB21F8700 for ; Mon, 23 Jul 2012 04:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.201 X-Spam-Level: X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 EorSafvr19ml for ; Mon, 23 Jul 2012 04:29:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B146E21F8702 for ; Mon, 23 Jul 2012 04:28:59 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-e1-500d357a86f9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FB.FC.15286.A753D005; Mon, 23 Jul 2012 13:28:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Mon, 23 Jul 2012 13:28:58 +0200 Message-ID: <500D3579.4090803@ericsson.com> Date: Mon, 23 Jul 2012 13:28:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: avt@ietf.org References: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VrfKlDfA4PRBCYuXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX1vL1vBJMGKZ0uXMzUwTuPrYuTkkBAwkXgy6xY7hC0mceHe erYuRi4OIYFTjBI9Z+4zQzjLGSW2zf3IAlLFK6At8bHzKFCCg4NFQFXiyuoUkDCbgIXEzR+N bCC2qECgxLetx1khygUlTs58AtYqIiAgsWL7XzBbWKBc4mTvRrB6IYEiia8fr4DFOQVsJVYt PMkEMl5CQFLi9gGw8cwCehJTrrYwQtjyEs1bZzNDtGpLNDR1sE5gFJyFZNssJC2zkLQsYGRe xSicm5iZk15upJdalJlcXJyfp1ecuokRGJQHt/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTAazT9859iMle7Tf4Vqs6xLt/qRuURRd/Oixe58a6Q5+Xua lURb1Modb6nKWqic+//v38opJ00mlayI4FfYnWSy911ctcaZB4/LZwsb9LsmiXnmvtHPMWcV qnZPvtLHFnlEaJEH9z+DBFm9dxpn9E4UWtiFOvs92tso8eiC1BL9T7aXtVU+XlZiKc5INNRi LipOBACZpo/KGAIAAA== Subject: Re: [AVTCORE] [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:29:01 -0000 WG, (as chair) This appear to me that this IPR statement is an update of the previous ones that was made on the Internet-Drafts and known during the development of RFC 6285 https://datatracker.ietf.org/ipr/1024/ https://datatracker.ietf.org/ipr/1025/ At least the new statement is referencing the same patents/applications. There might be more companies (Cisco and Alcatel-Lucent) that should provide updated IPR statements now that the RFC has been published as they had IPR statements on the related Internet Drafts. I request that these IPR statements are done in a timely fashion. Regards Magnus Westerlund On 2012-07-20 19:31, Jason | Staywired Video Solutions Inc wrote: > Interesting :) > > Sent from a Staywired Video Solutions Inc. iPhone > > > > > On 2012-07-20, at 12:52 PM, IETF Secretariat wrote: > >> >> Dear Ali Begen, Zeev Vax, Tom Van Caenegem: >> >> An IPR disclosure that pertains to your RFC entitled "Unicast-Based Rapid >> Acquisition of Multicast RTP Sessions" (RFC6285) was submitted to the IETF >> Secretariat on 2012-07-19 and has been posted on the "IETF Page of Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1830/). The title >> of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to >> RFC 6285.""); >> >> The IETF Secretariat >> >> _______________________________________________ >> ipr-announce mailing list >> ipr-announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ipr-announce > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Mon Jul 23 04:30:50 2012 Return-Path: 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 F132A21F86C2; Mon, 23 Jul 2012 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.768 X-Spam-Level: X-Spam-Status: No, score=-109.768 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 faaddwVBy-Xm; Mon, 23 Jul 2012 04:30:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 24B7D21F86B9; Mon, 23 Jul 2012 04:30:48 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6NBSHRN007265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Jul 2012 13:30:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 23 Jul 2012 13:30:39 +0200 From: "DRAGE, Keith (Keith)" To: Jason | Staywired Video Solutions Inc , IETF Secretariat Date: Mon, 23 Jul 2012 13:30:38 +0200 Thread-Topic: [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 Thread-Index: Ac1mnXhns83ExHM1Qxa+zmJ7eZk4MACJdMew Message-ID: References: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-Mailman-Approved-At: Mon, 23 Jul 2012 08:35:27 -0700 Cc: "avt@ietf.org" , "zeevvax@microsoft.com" , "ipr-announce@ietf.org" Subject: Re: [AVTCORE] [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:30:50 -0000 Looks like Microsoft have just been updating their prior disclosures made a= gainst the input drafts. I have just received a whole batch related to vari= ous disconnected RFCs. I don't believe there is anything here the WG were not already aware of whe= n they decided to adopt the technical solution. Regards Keith > -----Original Message----- > From: Jason | Staywired Video Solutions Inc [mailto:staywiredvs@gmail.com= ] > Sent: 20 July 2012 18:31 > To: IETF Secretariat > Cc: abegen@cisco.com; zeevvax@microsoft.com; Van Caenegem, Tom (Tom); > DRAGE, Keith (Keith); avt@ietf.org; even.roni@huawei.com; > gonzalo.camarillo@ericsson.com; ipr-announce@ietf.org; > rjsparks@nostrum.com > Subject: Re: [ipr-announce] IPR Disclosure: Microsoft Corporation's > Statement about IPR related to RFC 6285 >=20 > Interesting :) >=20 > Sent from a Staywired Video Solutions Inc. iPhone >=20 >=20 >=20 >=20 > On 2012-07-20, at 12:52 PM, IETF Secretariat wrote: >=20 > > > > Dear Ali Begen, Zeev Vax, Tom Van Caenegem: > > > > An IPR disclosure that pertains to your RFC entitled "Unicast-Based > Rapid > > Acquisition of Multicast RTP Sessions" (RFC6285) was submitted to the > IETF > > Secretariat on 2012-07-19 and has been posted on the "IETF Page of > Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1830/). > The title > > of the IPR disclosure is "Microsoft Corporation's Statement about IPR > related to > > RFC 6285.""); > > > > The IETF Secretariat > > > > _______________________________________________ > > ipr-announce mailing list > > ipr-announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ipr-announce From ron.even.tlv@gmail.com Mon Jul 23 11:51:25 2012 Return-Path: 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 049CD21F84F3; Mon, 23 Jul 2012 11:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CzGg3fUPDevr; Mon, 23 Jul 2012 11:51:24 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 989E921F84EF; Mon, 23 Jul 2012 11:51:23 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4304618wgb.13 for ; Mon, 23 Jul 2012 11:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=1t0ugtit3HkcfoQEBE+GKSSpbspmZ09elVXzvqPKw4Q=; b=UibrjBYyflJGeiDn9uHJiEl/z5W2Tbbu0bXPkFqp39+f6wdwF5Oz6+NcK3Air+R9pP qpnF9DzoZw2MIGnYQ/bdJtTaEuFQ2nQk0TPjGiGlytnhvMhL2j4E23uDt5a/t8Ry8Dtl RTYH3giPfxwDeCwBYf08TdVTuDEvVyaqdu+y57ZH5A7qcnfpMZ+mIgGulftHRAKIKPf3 OJELISD4MrOzcEChgf5vNv/iDGBf1qjjX0pASLpI5dS7mEqmtZNXV3YntmWqwNPfPPKb hP9eZnF/l8XQ6cLIwc9NVXMjD/glx/wNz1G8VWQ/FNLt7raZPxMHGpKNjWarL/YgXool qWsg== Received: by 10.180.106.97 with SMTP id gt1mr99973wib.5.1343069482509; Mon, 23 Jul 2012 11:51:22 -0700 (PDT) Received: from RoniE (bzq-79-176-214-12.red.bezeqint.net. [79.176.214.12]) by mx.google.com with ESMTPS id l5sm86033wix.5.2012.07.23.11.51.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 11:51:21 -0700 (PDT) From: "Roni Even" To: "'DRAGE, Keith \(Keith\)'" , "'IETF Secretariat'" References: <20120720165215.18171.64503.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 23 Jul 2012 21:50:18 +0200 Message-ID: <005501cd690c$66d91840$348b48c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEl3Z6RbL2+aKpnCz+x2VB9EVyPMAMP3tLNAauLpWGYYHD1gA== Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVTCORE] [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 18:51:25 -0000 Hi, I agree with Keith, >From the document shepherd write-up " (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are multiple IPR disclosures in respect of the draft. After one member of the WG expressed concern, these were explicitly brought to the attention of the working group to see if there were other concerns. There were none." There were the following IPR for the 08 version of the draft before it went to publicatoin For reference, I believe the relevant IPR declarations are: https://datatracker.ietf.org/ipr/990/ https://datatracker.ietf.org/ipr/1024/ https://datatracker.ietf.org/ipr/1025/ https://datatracker.ietf.org/ipr/1128/ https://datatracker.ietf.org/ipr/1269/ https://datatracker.ietf.org/ipr/1200/ Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 23 July, 2012 1:31 PM To: Jason | Staywired Video Solutions Inc; IETF Secretariat Cc: avt@ietf.org; zeevvax@microsoft.com; ipr-announce@ietf.org Subject: Re: [AVTCORE] [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6285 Looks like Microsoft have just been updating their prior disclosures made against the input drafts. I have just received a whole batch related to various disconnected RFCs. I don't believe there is anything here the WG were not already aware of when they decided to adopt the technical solution. Regards Keith > -----Original Message----- > From: Jason | Staywired Video Solutions Inc > [mailto:staywiredvs@gmail.com] > Sent: 20 July 2012 18:31 > To: IETF Secretariat > Cc: abegen@cisco.com; zeevvax@microsoft.com; Van Caenegem, Tom (Tom); > DRAGE, Keith (Keith); avt@ietf.org; even.roni@huawei.com; > gonzalo.camarillo@ericsson.com; ipr-announce@ietf.org; > rjsparks@nostrum.com > Subject: Re: [ipr-announce] IPR Disclosure: Microsoft Corporation's > Statement about IPR related to RFC 6285 > > Interesting :) > > Sent from a Staywired Video Solutions Inc. iPhone > > > > > On 2012-07-20, at 12:52 PM, IETF Secretariat wrote: > > > > > Dear Ali Begen, Zeev Vax, Tom Van Caenegem: > > > > An IPR disclosure that pertains to your RFC entitled "Unicast-Based > Rapid > > Acquisition of Multicast RTP Sessions" (RFC6285) was submitted to > > the > IETF > > Secretariat on 2012-07-19 and has been posted on the "IETF Page of > Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1830/). > The title > > of the IPR disclosure is "Microsoft Corporation's Statement about > > IPR > related to > > RFC 6285.""); > > > > The IETF Secretariat > > > > _______________________________________________ > > ipr-announce mailing list > > ipr-announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ipr-announce _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From ron.even.tlv@gmail.com Tue Jul 24 05:05:47 2012 Return-Path: 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 9F58821F85F3 for ; Tue, 24 Jul 2012 05:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_LOW=-1] 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 7EdK+604YuA8 for ; Tue, 24 Jul 2012 05:05:47 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4E21F8636 for ; Tue, 24 Jul 2012 05:05:46 -0700 (PDT) Received: by weyu54 with SMTP id u54so5637145wey.31 for ; Tue, 24 Jul 2012 05:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=pTLnE++5gwxn+jj5X5PxPCIQVJuwgS0SRUp0non9wYg=; b=rG30Iso6zbgEHw8cgJpxuilIERbpMI3GxAqn2GhTSdnej2fRKS9Ka4x166PNDWP0N1 w9P9a4z36zKB6dG+ivXdCEo2Qtn53GxYdMzMlKmr+Bj52n8tKNzKa37NDp5TUbfpvc8o 8r4BoMMD+BGCMScM/3i1blT0cIyjnZAwhp8pc1faYO7AIrc3os7mKfOCwCpRC2kD1907 n66YjCFlWciW9rhaNODg1rjLtBT94GGAL7VturjvzEXoCteR3AyJ9rpIrG0esWvPEyHm +0B0/ChGFcyT2pi+Gu+5B+k3025zlrYGhxWIxtoBSEjBKdqCrb/qRGuKqSDQLyxoZRyT 8puA== Received: by 10.180.83.66 with SMTP id o2mr6381669wiy.14.1343131545499; Tue, 24 Jul 2012 05:05:45 -0700 (PDT) Received: from RoniE (bzq-79-176-214-12.red.bezeqint.net. [79.176.214.12]) by mx.google.com with ESMTPS id el6sm4017750wib.8.2012.07.24.05.05.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jul 2012 05:05:44 -0700 (PDT) From: "Roni Even" To: Date: Tue, 24 Jul 2012 15:04:46 +0200 Message-ID: <00cd01cd699c$e7bcfef0$b736fcd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CE_01CD69AD.AB461D10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1pnLFLBYiY2F+hRv2L0MEpSQ3k2w== Content-Language: en-us Subject: [AVTCORE] Updated agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:05:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CD69AD.AB461D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01CD69AD.AB461D10" ------=_NextPart_001_00CF_01CD69AD.AB461D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We updated the agenda, changing order of presentations on Thursday and presenters names. Roni Even AVTcore co-chair ------=_NextPart_001_00CF_01CD69AD.AB461D10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We updated the = agenda, changing order of presentations on Thursday and presenters = names.

Roni Even

AVTcore co-chair

------=_NextPart_001_00CF_01CD69AD.AB461D10-- ------=_NextPart_000_00CE_01CD69AD.AB461D10 Content-Type: text/plain; name="a1207.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="a1207.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Magnus Westerlund Roni Even AGENDA Thursday, 2 August 2012 at 15:10-17:10 (Regency E) -------------------------------------------------- 15:10 AVTCore Status Update (Chairs, 15) 15:25 Random Algorithm for RTP CNAME generation (Eric Rescorla, 15) draft-rescorla-avtcore-random-cname-00 15:40 RTP Multiplexing Architecture (Colin Perkins , 15) draft-westerlund-avtcore-multiplex-architecture-02 15:55 RTP Considerations for Endpoints sending multiple media = streams(Jonathan Lennox, 20) draft-lennox-avtcore-rtp-multi-stream-00 16:15 Multiple Media type in an RTP session (Magnus Westerlund , 20) draft-westerlund-avtcore-multi-media-rtp-session-00 16:35 Multiple RTP Session on a Single Lower-Layer Transport(Magnus = Westerlund , 20) draft-westerlund-avtcore-transport-multiplexing-03 16:55 Media Multiplexing with RTP subsessions (Richard Ejzak, 15) draft-ejzak-avtcore-rtp-subsessions-01 17:10 End Friday, 3 August 2012 at 11:20-12:20 (Regency E) ------------------------------------------------ 11:20 Encrypted Key Transport for Secure RTP (Dan Wing, 20) draft-ietf-avtcore-srtp-ekt-00 11:40 RTCP for inter-destination media synchronization(Ray van = Brandenburg, 20) draft-ietf-avtcore-idms-06 12:00 RTP Clock Source Signalling (Kevin Gross, 10) draft-ietf-avtcore-clksrc-00 12:10 RTP and Leap Second (Kevin Gross, 10) draft-ietf-avtcore-leap-second-00 12:20 End ------=_NextPart_000_00CE_01CD69AD.AB461D10 Content-Type: text/html; name="a1207.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="a1207.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Thursday, 2 August 2012 at 15:10-17:10 (Regency E)

15:10 AVTCore Status UpdateChairs
15:25 Random Algorithm for RTP CNAME generationEric Rescorla
= draft-rescorla-avtcore-random-cname-00
15:40 RTP Multiplexing ArchitectureColin = Perkins=20
draft-westerlund-avtcore-multiplex-architecture-02
15:55 RTP Considerations for Endpoints sending multiple = media streamsJonathan Lennox
draft-lennox-avtcore-rtp-multi-stream-00
16:15 Multiple Media type in an RTP sessionMagnus Westerlund=20
draft-westerlund-avtcore-multi-media-rtp-session-00
16:35 Multiple RTP Session on a Single Lower-Layer = TransportMagnus Westerlund=20
draft-westerlund-avtcore-transport-multiplexing-03
16:55 Media Multiplexing with RTP subsessionsRichard Ejzak
= draft-ejzak-avtcore-rtp-subsessions-01
17:10 End

Friday, 3 August 2012 at 11:20-12:20 (Regency E)

11:20 Encrypted Key Transport for Secure RTPDan Wing
draft-ie= tf-avtcore-srtp-ekt-00
11:40 RTCP for inter-destination media synchronizationRay van Brandenburg
draft-ietf-a= vtcore-idms-06
12:00 RTP Clock Source SignallingKevin = Gross
draft-ietf= -avtcore-clksrc-00
12:10 RTP and Leap SecondKevin Gross
draft= -ietf-avtcore-leap-second-00
12:20 End
------=_NextPart_000_00CE_01CD69AD.AB461D10-- From Even.roni@huawei.com Tue Jul 24 21:45:02 2012 Return-Path: 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 A9B6C21F848A for ; Tue, 24 Jul 2012 21:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Mu0-7ATilkc0 for ; Tue, 24 Jul 2012 21:45:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 90D7321F847E for ; Tue, 24 Jul 2012 21:45:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIH96205; Wed, 25 Jul 2012 00:45:00 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 21:41:43 -0700 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 21:41:42 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 12:41:05 +0800 From: Roni even To: "avt@ietf.org" Thread-Topic: NomCom 2012-2013: Second Call for Volunteers Thread-Index: AQHNah+z1m1l6Abw+0umnbe++GX/bw== Date: Wed, 25 Jul 2012 04:41:05 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] Fwd: NomCom 2012-2013: Second Call for Volunteers X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 04:45:02 -0000 -------- Original Message -------- Subject: NomCom 2012-2013: Second Call for Volunteers Date: Tue, 24 Jul 2012 13:06:04 -0700 From: NomCom Chair To: IETF Announcement List The NomCom 2012-2013 Call for Volunteers has now passed its halfway point. Therefore, if you are considering volunteering to participate in the 2012-2013 NomCom, please do so soon. General information on this year's NomCom (including a list of positions to be filled) can be found at: https://www.ietf.org/nomcom/2012/ The success of the NomCom process depends on randomly selecting a committee that is a representative sample of the our community. We endeavor to have a NomCom reflecting the diversity of experience and viewpoints that is our community's greatest strength. However, to achieve this goal we must have the largest possible pool of volunteers that from throughout the IETF community. I am pleased to report that we have had a strong initial response to the First Call for Volunteers, with 74 qualified individuals agreeing to volunteer their time. I greatly appreciate the generosity and commitment to our community exhibited by all of these individuals. However, the pool of volunteers is not yet as diverse as it should be to reflect the breadth of our community with regards to nationality, gender and organizational affiliation. Therefore, I would especially encourage to volunteer those individuals whose participation would increase the diversity of our volunteer pool. If you have volunteered before 12:00 noon UTC on July 24, 2012 and you have not received a confirmation email from me, then an error has occurred and I would request that you resend your email. Details on how to volunteer can be found at the end of this message. To summarize, please volunteer by sending me an email containing your name, affiliation, and the email address you use to register for IETF meetings. The 74 qualified individuals who have so far volunteered are listed below. I apologize for any errors in this list, please notify me of any errors as soon as possible. Sam Aldrin, Huawei Ignas Bagdonas, Cisco Lou Berger, LabN Consulting Randy Bush, IIJ Dennis Cai, Cisco Daniele Ceccarelli, Ericsson Gang Chen, China Mobile Andras Csaszar, Ericsson Hui Deng, China Mobile Keith Drage, Alcatel-Lucent John Drake, Juniper Donald Eastlake, Huawei Charles Eckel, Cisco Mehmet Ersue, Nokia Siemens Networks Miguel Garcia, Ericsson Eric Gray, Ericsson Wassim Haddad, Ericsson Stephen Hanna, Juniper Sam Hartman, Painless Security Jia He, Huawei Giles Heron, Cisco Paul Hoffman, VPN Consortium Christer Holmberg, Ericsson Fangwei Hu, ZTE Andrew Hutton, Siemens Enterprise Communications Cullen Jennings, Cisco Yuanlong Jiang, Huawei Sheng Jiang, Huawei Lizhong Jin, ZTE Stephen Kent, BBN Ari Keranen, Ericsson Ning Kong, CNNIC Jouni Korhonen, Nokia Siemens Networks Mirja Kuehlewind, University of Stuttgart Eliot Lear, Cisco Hongyu Li, Huawei Guoman Liu, ZTE Wenhu Lu, Ericsson Yuxia Ma, ZTE Andrew Malis, Verizon Terry Manderson, ICANN Scott Mansfield, Ericsson Luca Martini, Cisco David Meyer, Cisco Monique Morrow, Cisco Thomas Nadeau, Juniper Karen O'Donoghue, Internet Society Borje Ohlman, Ericsson Keyur Patel, Cisco Teemu Savolainen, Nokia Benson Schliesser, Juniper John Scudder, Juniper Karen Seo, BBN Arturo Servin, LACNIC Shuo (Sean) Shen, CNNIC David Sini, Ericsson Haibin Song, Huawei Tom Taylor, PT Taylor Consulting Pascal Thubert, Cisco Mark Townsley, Cisco Tina Tsou, Huawei Bill VerSteeg, Cisco Thomas Walsh, Juniper Yinxing Wei, ZTE Stephan Wenger, Vidyo Magnus Westerlund, Ericsson Steven White, Alcatel-Lucent Qin (Bill) Wu, Huawei Leaf Yeh, Huawei Lixia Zhang, UCLA Zhaohui (Jeff) Zhang, Juniper Yi Zhao, Huawei Qian (Cathy) Zhou, Huawei Ning Zong, Huawei To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple days. Thank you, Matthew Lepinski nomcom-chair@ietf.org (or mlepinski.ietf@gmail.com) _______________________________________________ xrblock mailing list xrblock@ietf.org https://www.ietf.org/mailman/listinfo/xrblock= From wwwrun@rfc-editor.org Wed Jul 25 21:50:06 2012 Return-Path: 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 F29DC21F84DE for ; Wed, 25 Jul 2012 21:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 nS22gXdzVhb1 for ; Wed, 25 Jul 2012 21:50:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 371AE21F84CE for ; Wed, 25 Jul 2012 21:50:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A718EB1E002; Wed, 25 Jul 2012 21:49:50 -0700 (PDT) To: abegen@cisco.com, dohsu@cisco.com, mlague@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20120726044950.A718EB1E002@rfc-editor.org> Date: Wed, 25 Jul 2012 21:49:50 -0700 (PDT) X-Mailman-Approved-At: Thu, 26 Jul 2012 08:31:29 -0700 Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Editorial Errata Reported] RFC5725 (3293) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 04:50:06 -0000 The following errata report has been submitted for RFC5725, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5725&eid=3293 -------------------------------------- Type: Editorial Reported by: Glen Zorn Section: 3 Original Text ------------- o thinning (T): 4 bits The amount of thinning performed on the sequence-number space. Only those packets with sequence numbers 0 mod 2^T are reported by this block. A value of 0 indicates that there is no thinning and all packets are reported. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). Corrected Text -------------- o thinning (T): 4 bits The amount of thinning performed on the sequence-number space. Only those packets with sequence numbers s satisfying the relation s mod 2^T = 0 are reported by this block. A value of 0 indicates that there is no thinning and all packets are reported. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). Notes ----- The original is cryptic at best. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5725 (draft-ietf-avt-post-repair-rtcp-xr-07) -------------------------------------- Title : Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) Publication Date : February 2010 Author(s) : A. Begen, D. Hsu, M. Lague Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From ron.even.tlv@gmail.com Fri Jul 27 15:42:50 2012 Return-Path: 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 A21CA11E80C5 for ; Fri, 27 Jul 2012 15:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NmnovdB8CtBq for ; Fri, 27 Jul 2012 15:42:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 121B411E8098 for ; Fri, 27 Jul 2012 15:42:50 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5790689pbc.31 for ; Fri, 27 Jul 2012 15:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=v9zdeKjrvF2pW0/Vw6FVemAv32aCN2gsAhEMBKKrbqk=; b=acZfhJ0E1uiEpreO92Id8oYfM/d6V9bDl2A2xLfOi0oZmv4rrvaajqNYluqTk6Uivv c+oGS0XXUEpfM9UF5xsEAkdyN6qSAeaNLY17aMttxo2l4jpx2WGXx3gYoSS2JHEKBCup snlgMkva7+p3lw6S0zAE46vJEw7zuAqxLbni6hFqHDkc+1EQu7KHgg/4MkODh2IXA63v Mol4VNQ5qFdG+20psb2NyRq1bLY0oyt4pXknlVj4rkmus6PNzighj/t/sxQZBj3k6maB 6oDsdCxfhW/ZnKy5vbCEHT3fx+PAXAwX8T7z2EqwZWE/gr0UCH4CXx0Ii1okFegCz41F Gddw== Received: by 10.68.130.9 with SMTP id oa9mr17180152pbb.95.1343428969747; Fri, 27 Jul 2012 15:42:49 -0700 (PDT) Received: from RoniE ([206.191.100.2]) by mx.google.com with ESMTPS id oy8sm2694778pbc.52.2012.07.27.15.42.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 15:42:49 -0700 (PDT) From: "Roni Even" To: Date: Sat, 28 Jul 2012 01:41:45 +0200 Message-ID: <002e01cd6c51$628c8720$27a59560$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CD6C62.2615A540" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1sUAheh6F9qJcoTPaMUiM1G2rHMA== Content-Language: en-us Subject: [AVTCORE] review of draft-lennox-avtcore-rtp-multi-stream-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 22:42:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002F_01CD6C62.2615A540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi guys, I read the draft and I think that it does not discuss the difference in RTCP handling between RTCP terminating mixer and source projecting mixers or translators. It looks to me that the text addresses only the second topologies. If the mixer uses its own SSRCs it does not show all the behaviors described in section 5.1. My understanding of RFC3550 is that for this case the mixer does not forward the sender and receiver reports, only the SDES in order to identify SSRC collision and the BYE messages so there will be less messages than in the case of translators or source projecting mixers. Another comment is that for source projecting mixers in my view, the document provides motivation to use multi sessions over single transport to reduce the number of RTC messages. Roni Even ------=_NextPart_000_002F_01CD6C62.2615A540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = guys,

I read the draft and I think = that it does not discuss the difference in RTCP handling  between = RTCP terminating mixer and source projecting mixers or translators. It = looks to me that the text addresses only the second = topologies.

 

If the mixer uses its own SSRCs it does not show all = the behaviors described in section 5.1. My understanding of RFC3550 is = that for this case the mixer does not forward the sender and receiver = reports, only the SDES in order to identify SSRC collision and the BYE = messages so there will be less messages than in the case of translators = or source projecting mixers.

 

Another = comment is that for source projecting mixers in my view, the document = provides motivation to use multi sessions over single transport to = reduce the number of RTC messages.

 

Roni = Even

 

------=_NextPart_000_002F_01CD6C62.2615A540-- From mary.ietf.barnes@gmail.com Mon Jul 30 09:01:52 2012 Return-Path: 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 4BFE611E80A2; Mon, 30 Jul 2012 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 AZMb63bC+WGJ; Mon, 30 Jul 2012 09:01:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD51811E8091; Mon, 30 Jul 2012 09:01:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3756685lbb.31 for ; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PId8U94hGEYbu5smaElfkBUjb1gvpuDGTWoqh9zUkwE=; b=r9iy1q1yXoxn/VCdB6qwt8oVHTTwJuEfMOnfn4NFb96x0Xm8VQuHv90LzQq2CWoBmM 9k4w2x7MY7UoUUJWbzqsQxXvmd86aEizyY4aOBW0pyNDL/ooaemoU4Qs740s29AOjC7+ tINCt5vkaa3b2G34PeCsVSK+yiXSpsuCXyq9C+5DBpvbZZN1YdaYyVHRi9cF6EZiyBk0 pEI1qTMeoLSXrZk7OcLlwTwb4SqXcjZ2N/XqfP3zYawE8Y7zhm3cQ3MxEqsXvoHS/kDj Eky7RYNfG++5LxD1a98Qyt71Ut7vFiBubdxE2MwoOMMHDXCH/JyOJ3ILFtpInokJgOQy z/0Q== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr11865796lab.8.1343664097632; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 11:01:37 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043745473ca27b04c60e2ddb Subject: Re: [AVTCORE] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:01:52 -0000 --f46d043745473ca27b04c60e2ddb Content-Type: text/plain; charset=ISO-8859-1 Tutorial is in Georgia A. On Tue, Jul 10, 2012 at 6:37 PM, Mary Barnes wrote: > Hi all, > > Apologies to the many of you that are receiving this multiple times. > Unfortunately, the RAI list is not a superset of participants in WGs > that might be interested in this. Folks that aren't on the RAI list > might want to subscribe here: > https://www.ietf.org/mailman/listinfo/rai > > Please note the important update below with regards to (no) lunch. > > We are planning a lunchtime tutorial on Monday, July 30th. The > primary objective is to provide more background on telepresence as > well as an update of the work in CLUE to the broader RAI and IETF > community. This will hopefully facilitate the process of completing > the CLUE protocol work as it gets broader community review. > > Here's the proposed outline: > 1) Introduction to telepresence > 2) Example telepresence scenarios > 3) Introduction to the CLUE work > 4) High level introduction of framework > 5) One or two use cases as examples of how the CLUE framework is > realized - showing how existing protocols (e.g., SDP, RTP) are > integral to the solution along > with additional signaling for CLUE. > > We have reserved a room for around 50 and attendance will be FCFS, so > please RSVP by Friday, July 13th, 2012 (5pm Pacific) > http://www.doodle.com/mzu3nmdeehkxkiys > > **Important update*: * Please note that we do not have a sponsor for > lunch, thus folks will have to grab something before the tutorial (sorry, I > tried). However, we will have some cookies and veggies/fruit available so > folks will have something to munch. > > Please send any questions/comments to me (or to the CLUE WG mailing list) > rather than reply all. > > Regards, > Mary > CLUE WG co-chair > > --f46d043745473ca27b04c60e2ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tutorial is in Georgia A.=A0

On Tue, Jul = 10, 2012 at 6:37 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important= update*: =A0Please note that we do not have a sponsor for lunch, thus = folks will have to grab something before the tutorial (sorry, I tried). =A0= However, we will have some cookies and veggies/fruit available so folks wil= l have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair


--f46d043745473ca27b04c60e2ddb-- From Even.roni@huawei.com Mon Jul 30 11:49:27 2012 Return-Path: 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 5320911E8130; Mon, 30 Jul 2012 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 50WZala3JuOc; Mon, 30 Jul 2012 11:49:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A023E11E8111; Mon, 30 Jul 2012 11:49:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM02872; Mon, 30 Jul 2012 14:49:26 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 11:46:15 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 11:46:16 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 02:45:59 +0800 From: Roni even To: "avt@ietf.org" Thread-Topic: Need volunteers for the NomCom Thread-Index: AQHNbnHLz44QxMxFHUqja0jn/qX+GJdCKiDR Date: Mon, 30 Jul 2012 18:45:59 +0000 Message-ID: References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "payload@ietf.org" Subject: [AVTCORE] FW: Need volunteers for the NomCom X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:49:27 -0000 ________________________________________ From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of No= mCom Chair [nomcom-chair@ietf.org] Sent: Monday, July 30, 2012 6:22 To: Working Group Chairs Subject: Need volunteers for the NomCom We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participant= s in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/= 49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org=