From glenzorn@gmail.com Tue Jun 19 23:29:11 2012 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4769621F86FD for ; Tue, 19 Jun 2012 23:29:11 -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=[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 OgchVAKanClD for ; Tue, 19 Jun 2012 23:29:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2B21F86E5 for ; Tue, 19 Jun 2012 23:29:10 -0700 (PDT) Received: by dacx6 with SMTP id x6so9527875dac.31 for ; Tue, 19 Jun 2012 23:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=3B4T4aC/jImaYomG7J4cBruIDp13Ee1dlP6mHZnDCs8=; b=SIsfkDT0ESGpveIpUlmgW3oOw0JekeTq2IlfNR27phqXwFDQxOsePjRTmZSzx83TRh SwdtfQ8phHkt5PmZ8ejWJnVSfp0kcal1bMt+ecOP+kopllde44a+cry8G9NxLleBDJ9l iM4r7+laioIREqznTaC5T15XbJg6aN3h+QEvw5XJmUy4lO9nxofj743SX7EXZNxUGmmD xzYHmm67Ur/ehiP7k1V8M1A2LQpiIffuXHPXdIeDG0F5lhJWoNu/XJa1NRw8t0xXgz3V yrJ5E83LtcIoVKdwbaLEPavzVqVDIXrmq1uQIJcUy8MYaHsVc9cWz9B0jBtLUyFdkqmX Os9g== Received: by 10.68.230.68 with SMTP id sw4mr13422265pbc.142.1340173750223; Tue, 19 Jun 2012 23:29:10 -0700 (PDT) Received: from [192.168.1.99] (ppp-124-121-250-228.revip2.asianet.co.th. [124.121.250.228]) by mx.google.com with ESMTPS id rg9sm7346739pbc.67.2012.06.19.23.29.07 (version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 23:29:09 -0700 (PDT) From: Glen Zorn To: avtext-chairs@tools.ietf.org In-Reply-To: <4FB601D1.3030207@gmail.com> References: <20120510144047.4553.21596.idtracker@ietfa.amsl.com> <4FB601D1.3030207@gmail.com> Content-Type: multipart/alternative; boundary="=-N1d1B9yfiIPJ+F9j7xrb" Organization: Network Zen Date: Wed, 20 Jun 2012 13:29:05 +0700 Message-ID: <1340173745.24121.19.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 06:29:11 -0000 --=-N1d1B9yfiIPJ+F9j7xrb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2012-05-18 at 15:01 +0700, Glen Zorn wrote: > On 05/10/2012 09:40 PM, internet-drafts@ietf.org wrote: > > I guess that this draft is ready for WGLC. I've not seen any dissent; is this actually going to happen? > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. > > > > Title : Support for Multiple Clock Rates in an RTP Session > > Author(s) : Marc Petit-Huguenin > > Glen Zorn > > Filename : draft-ietf-avtext-multiple-clock-rates-05.txt > > Pages : 11 > > Date : 2012-05-10 > > > > This document clarifies the RTP specification when different clock > > rates are used in an RTP session. It also provides guidance on how > > to interoperate with legacy RTP implementations that use multiple > > clock rates. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/ > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > --=-N1d1B9yfiIPJ+F9j7xrb Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2012-05-18 at 15:01 +0700, Glen Zorn wrote: 
On 05/10/2012 09:40 PM, internet-drafts@ietf.org wrote:

I guess that this draft is ready for WGLC.

I've not seen any dissent; is this actually going to happen?


> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.
>
> 	Title           : Support for Multiple Clock Rates in an RTP Session
> 	Author(s)       : Marc Petit-Huguenin
>                            Glen Zorn
> 	Filename        : draft-ietf-avtext-multiple-clock-rates-05.txt
> 	Pages           : 11
> 	Date            : 2012-05-10
>
>     This document clarifies the RTP specification when different clock
>     rates are used in an RTP session.  It also provides guidance on how
>     to interoperate with legacy RTP implementations that use multiple
>     clock rates.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/
>
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext

--=-N1d1B9yfiIPJ+F9j7xrb-- From magnus.westerlund@ericsson.com Tue Jun 19 23:44:00 2012 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041821F8707 for ; Tue, 19 Jun 2012 23:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 A02RfLELRDM3 for ; Tue, 19 Jun 2012 23:44:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A6A6121F8705 for ; Tue, 19 Jun 2012 23:43:59 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-03-4fe1712e3a00 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.E5.11869.E2171EF4; Wed, 20 Jun 2012 08:43: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; Wed, 20 Jun 2012 08:43:58 +0200 Message-ID: <4FE1712E.60007@ericsson.com> Date: Wed, 20 Jun 2012 08:43:58 +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: avtext@ietf.org References: <20120510144047.4553.21596.idtracker@ietfa.amsl.com> <4FB601D1.3030207@gmail.com> <1340173745.24121.19.camel@gwz-laptop> In-Reply-To: <1340173745.24121.19.camel@gwz-laptop> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3Vlev8KG/QX+3hsXHezdYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXzRXZaCXuGKPUc/sDQwTubvYuTkkBAwkTj1+CM7hC0mceHe erYuRi4OIYFTjBINS7uYIJzljBKTDz1hAqniFdCU+PvhPxuIzSKgKrF7zmNWEJtNwELi5o9G sLioQLDEtOn32CHqBSVOznzCAmKLCAhL/HpzE6xeWMBf4taP2VDbWhglPi7tYexi5ODgFDCW eHDAHOIiSYl77avBZjID7W3d/psdwpaXaN46mxnEFhLQlmho6mCdwCg4C8m6WUhaZiFpWcDI vIpRODcxMye93EgvtSgzubg4P0+vOHUTIzAwD275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeW pGanphakFsUXleakFh9iZOLglGpgNOZg8/WeFttXIXF+5p6/h86d+XVx7nXBUK5ehR01YtNC c/STAxdznW1dfMSMX9H6rclhia738+X0vKOi+L5/z7z/vPztY6P/TCuLWhJZrvS7bL2j7LDu 0LxYo0PL07be/nHz/gYPWf3lKm7T1vfek9fckuzzIvDNigNmXGkT+godvXZ8UzHfpcRSnJFo qMVcVJwIANWUX74aAgAA Subject: Re: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 06:44:00 -0000 On 2012-06-20 08:29, Glen Zorn wrote: > On Fri, 2012-05-18 at 15:01 +0700, Glen Zorn wrote: >> On 05/10/2012 09:40 PM, internet-drafts@ietf.org wrote: >> >> I guess that this draft is ready for WGLC. > > I've not seen any dissent; is this actually going to happen? Blame the responsible chair, i.e. me. I have hosted 2 Interim meetings last week and the week before and haven't caught up yet. I plan to do so today. Cheers Magnus > >> >> > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. >> > >> > Title : Support for Multiple Clock Rates in an RTP Session >> > Author(s) : Marc Petit-Huguenin >> > Glen Zorn >> > Filename : draft-ietf-avtext-multiple-clock-rates-05.txt >> > Pages : 11 >> > Date : 2012-05-10 >> > >> > This document clarifies the RTP specification when different clock >> > rates are used in an RTP session. It also provides guidance on how >> > to interoperate with legacy RTP implementations that use multiple >> > clock rates. >> > >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > This Internet-Draft can be retrieved at: >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-05.txt >> > >> > The IETF datatracker page for this Internet-Draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/ >> > >> > _______________________________________________ >> > avtext mailing list >> > avtext@ietf.org >> > https://www.ietf.org/mailman/listinfo/avtext >> > -- 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 Wed Jun 20 00:42:38 2012 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDB821F8710 for ; Wed, 20 Jun 2012 00:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 HRviIJxNb0AO for ; Wed, 20 Jun 2012 00:42:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4302521F86F2 for ; Wed, 20 Jun 2012 00:42:36 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-66-4fe17eecc270 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 79.1F.11869.CEE71EF4; Wed, 20 Jun 2012 09:42:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 20 Jun 2012 09:42:35 +0200 Message-ID: <4FE17EEB.5000705@ericsson.com> Date: Wed, 20 Jun 2012 09:42:35 +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: "avtext@ietf.org" , draft-ietf-avtext-multiple-clock-rates@tools.ietf.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvre6buof+Bnv+81t8vHeD1eLSsUIH Jo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+PPn0bGgt0KFQv2dzA1MC6V7GLk5JAQMJGY eX0zC4QtJnHh3nq2LkYuDiGBU4wSM/7NZAVJCAksZ5TY8Na+i5GDg1dAW+LyUmWQMIuAqsSS PWeZQGw2AQuJmz8a2UBsUYFgiWnT77GD2LwCghInZz4Bmy8ikChxcs87sBphATuJTRNfsULs lZS4174aLM4soCcx5WoLI4QtL9G8dTYzxAnaEg1NHawTGPlnIRk7C0nLLCQtCxiZVzEK5yZm 5qSXG+mlFmUmFxfn5+kVp25iBIbdwS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MU9YszTzKfelI0rX8Y/9i51bfNqxaq1N29ONsxUVRhYsYvZ26JEVC v7ubzfmdUbUlZ92Vf9wW6h5VGpu0j/Lf1Xm6UompvuLo7t8Hi/u2/pviuGiWgdHXnAVsdy/7 LYi7N+XPBws7EYXptQ2JESrxp99tlntsJnesQHBG8/mjlU1KHE/WhH2brcRSnJFoqMVcVJwI ACa7OwcJAgAA Subject: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 07:42:38 -0000 Hi, I have reviewed the draft and found some significant issues that I think should be addressed prior to a WG last call. 1. Section 4.1: The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used to accelerate the synchronization. I would suggest that you change this to: The RTP header extension defined in "Rapid Synchronisation of RTP Flows" [RFC6051] MAY be used to accelerate the synchronization. That tells the reader more about which type of extension and what it is for than the previous formulation. 2. Section 4.2: I found one sever error in the formula: First: start_offset = (capture_time - capture_start) * previous_clock_rate This is missing to add the original start_offset to the new offset calculated. Thus the start_offset calculation should be: start_offset = (capture_time - capture_start) * previous_clock_rate + start_offset 3. Section 4.2: Then I think the timestamp calculation should make clear where the initial random offset is to be added. And to my understanding it needs to be added in the timestamp formula which thus should read: timestamp = (capture_time - capture_start) * clock_rate + start_offset + random_initial_offset Or as an alternative, set the initial values, i.e: start_offset = 0 to start_offset = random_initial_offset' And that works to. 4. Section 4.3: I think one has to clarify that "j" is the newer arrival compared to "i" which is the previous arrival. 5. Section 4.3: For interoperability with legacy RTP implementations, an RTP receiver MAY use the information in two consecutive SR packets to calculate the clock rate used, i.e. if Ni is the NTP timestamp for the SR packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the NTP timestamp and RTP timestamp for the previous SR packet j, then the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - Nj). Frankly, I don't see how this is correct or which information around the used clock rate that you try to derive. I have to assume that you know the previous RTP clock rate. But you have failed to receive any new RTP packets so the receiver doesn't yet know which clock rate is used. Lets assume that you have three clock rates in use in this RTP session, lets say 32k, 16k and 8k. You where running at 32k. Applying the above formula when the switch was very close before sending the second SR packet to 8k. Then you could plug in values like the following: Ri = 400000 Ni = 0 Switch happens 3.8 seconds into this interval Rj = 400000 + 121600 + 1600 = 523200 Nj = 4.0 s Then the above formula yields a value of = (400000 - 523200) / (0 - 4) = 30800 That says you only that a switch to a lower than current clock rate has happened. Not which of them. This formula will only yield a correct result when there are no switches in between the two SR used to calculate the value. To my understanding in the presence of packet loss you require both a RTP packet indicating the current payload type and an RTCP SR or equivalent time sync info to determine correctly where the switch happened (assuming a correct monotonically increasing timestamp space). 6. I wonder if not this specification should clarify the unclarity regarding monotonically increasing RTP timestamp values that this is required. Not only the clock one derives it from. And that put into section 4. 7. Section 4. I think Section 4 should contain the equivalent of table 2 and 3 to provide what values that the formulas in 4.2 and 4.3 provides. 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 glenzorn@gmail.com Sat Jun 23 17:54:55 2012 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F821F8697 for ; Sat, 23 Jun 2012 17:54:55 -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=[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 X49yQouEWRXs for ; Sat, 23 Jun 2012 17:54:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5921F8691 for ; Sat, 23 Jun 2012 17:54:53 -0700 (PDT) Received: by dacx6 with SMTP id x6so3861178dac.31 for ; Sat, 23 Jun 2012 17:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=RoG+IatI7LzyLRWkR9IA60U+JYT766t7no3z9E16u40=; b=qAv72TUhDAbRw+/taCMeK/GoUKeTS4xal76r9jk2qN8cQhNPviOdlJDQXHPAY8B2ZQ ZjWkivuBJlQP1PDv8Q0t3ra6VVu797kST1bztnp8LmtI/EBZW4dPoD3pWBH5QB7zjk+i SQuMsCDoQaj/a49HELI0E/TlxoprsT23907pncaR+FzpN3V3XgrBVj1/KD+a9HHuBX8m j8XZYsuW7qqTf9cUJ8MHdYeUqHfj1I/Mi5AOsRGnFS288ksmUZ7Zrw4PkO6sri6Z9A/m OzJa3Ca2bw1N6An4rR86cNd201fsJN0TjC/dh10O3NQWo1hbqCtYAzVvIuAUJEBByObq J4bw== Received: by 10.68.225.201 with SMTP id rm9mr25588026pbc.71.1340499293563; Sat, 23 Jun 2012 17:54:53 -0700 (PDT) Received: from [192.168.1.99] (ppp-124-120-149-10.revip2.asianet.co.th. [124.120.149.10]) by mx.google.com with ESMTPS id pq5sm3755987pbb.30.2012.06.23.17.54.51 (version=SSLv3 cipher=OTHER); Sat, 23 Jun 2012 17:54:53 -0700 (PDT) From: Glen Zorn To: avtext@ietf.org In-Reply-To: <4FE17EEB.5000705@ericsson.com> References: <4FE17EEB.5000705@ericsson.com> Content-Type: multipart/alternative; boundary="=-mbgdB0oC++L8I01cc075" Organization: Network Zen Date: Sun, 24 Jun 2012 07:54:49 +0700 Message-ID: <1340499289.5506.18.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 00:54:55 -0000 --=-mbgdB0oC++L8I01cc075 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2012-06-20 at 09:42 +0200, Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and found some significant issues that I think > should be addressed prior to a WG last call. > > 1. Section 4.1: The RTP extension defined in Perkins & Schierl [RFC6051] > MAY be used to accelerate the synchronization. > > I would suggest that you change this to: > > The RTP header extension defined in "Rapid Synchronisation of RTP Flows" > [RFC6051] MAY be used to accelerate the synchronization. > > That tells the reader more about which type of extension and what it is > for than the previous formulation. The "Perkins & Schierl" construct was an attempt to avoid the typical practice of writing something like "[RFC6051] defines...", which is abominable. However, reproducing the title of a referenced document is even worse stylistically. How does the existing text not tell the reader what the extension is for? > > 2. Section 4.2: I found one sever error in the formula: > > First: > start_offset = (capture_time - capture_start) > * previous_clock_rate > > This is missing to add the original start_offset to the new offset > calculated. Thus the start_offset calculation should be: > > start_offset = (capture_time - capture_start) > * previous_clock_rate + start_offset I'm not sure I understand. By "original start offset", do you mean the initial vale of the start_offset variable? That is zero, so I don't see how it helps to add it in every time, so it must be something else? > > > 3. Section 4.2: Then I think the timestamp calculation should make clear > where the initial random offset is to be added. The first paragraph of the section says: An RTP Sender with RTCP turned off (i.e. by setting the RS and RR bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for each different clock rate but MAY use different clock rates on the same SSRC as long as the RTP timestamp without the random offset is calculated as explained below[...] > And to my understanding > it needs to be added in the timestamp formula which thus should read: > > timestamp = (capture_time - capture_start) * clock_rate > + start_offset + random_initial_offset > > Or as an alternative, set the initial values, i.e: > start_offset = 0 > > to > > start_offset = random_initial_offset' ... --=-mbgdB0oC++L8I01cc075 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-06-20 at 09:42 +0200, Magnus Westerlund wrote: 
Hi,

I have reviewed the draft and found some significant issues that I think
should be addressed prior to a WG last call.

1. Section 4.1: The RTP extension defined in Perkins & Schierl [RFC6051]
MAY be used to accelerate the synchronization.

I would suggest that you change this to:

The RTP header extension defined in "Rapid Synchronisation of RTP Flows"
[RFC6051] MAY be used to accelerate the synchronization.

That tells the reader more about which type of extension and what it is
for than the previous formulation.

The "Perkins & Schierl" construct was an attempt to avoid the typical practice of writing something like "[RFC6051] defines...", which is abominable.  However, reproducing the title of a referenced document is even worse stylistically.  How does the existing text not tell the reader what the extension is for?


2. Section 4.2: I found one sever error in the formula:

First:
start_offset = (capture_time - capture_start)
                              * previous_clock_rate

This is missing to add the original start_offset to the new offset
calculated. Thus the start_offset calculation should be:

start_offset = (capture_time - capture_start)
                              * previous_clock_rate + start_offset

I'm not sure I understand.  By "original start offset", do you mean the initial vale of the start_offset variable?  That is zero, so I don't see how it helps to add it in every time, so it must be something else?



3. Section 4.2: Then I think the timestamp calculation should make clear
where the initial random offset is to be added.

The first paragraph of the section says:

   An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
   bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for
   each different clock rate but MAY use different clock rates on the
   same SSRC as long as the RTP timestamp without the random offset is calculated
   as explained below[...]


And to my understanding
it needs to be added in the timestamp formula which thus should read:

timestamp = (capture_time - capture_start) * clock_rate
                      + start_offset + random_initial_offset

Or as an alternative, set the initial values, i.e:
 start_offset = 0

to

 start_offset = random_initial_offset'

... --=-mbgdB0oC++L8I01cc075-- From magnus.westerlund@ericsson.com Mon Jun 25 04:06:01 2012 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0269021F84C8 for ; Mon, 25 Jun 2012 04:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 0o9Y3rd0saoE for ; Mon, 25 Jun 2012 04:06:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28121F8484 for ; Mon, 25 Jun 2012 04:05:53 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-81-4fe8460f867a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8F.4B.11869.F0648EF4; Mon, 25 Jun 2012 13:05:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Mon, 25 Jun 2012 13:05:31 +0200 Message-ID: <4FE845FA.4040909@ericsson.com> Date: Mon, 25 Jun 2012 13:05:30 +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: Glen Zorn References: <4FE17EEB.5000705@ericsson.com> <1340499289.5506.18.camel@gwz-laptop> In-Reply-To: <1340499289.5506.18.camel@gwz-laptop> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrS6/2wt/g0urTSw+3rvBarF+8iUW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSujf+4PpoKz8hW9368xNTAekehi5OSQEDCR 2H3jCAuELSZx4d56ti5GLg4hgVOMEgs6XrFDOMsZJV4tuglWxSugLfH2QDs7iM0ioCqx+Pld MJtNwELi5o9GNhBbVCBYYtr0e+wQ9YISJ2c+AesVEVCS2HgJIs4soC5xeN8SRhBbWMBb4s6E j8wgtpBAoMSTa2dZQWxOASOJM1t3s0JcJylxr301G0SvpkTr9t9Qc+QlmrfOhurVlmho6mCd wCg0C8nqWUhaZiFpWcDIvIpRODcxMye93EgvtSgzubg4P0+vOHUTIzCID275rbqD8c45kUOM 0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgXN2288wiB2b7yQ+4y2zMPxda fys7bunZttl1otLDTQxdi27IB/cWyvhNb7zN4CjiqeC5z6tXfs7Kda/9Jdf0rZFcKeumGDtX I/xixvcLGk+vxSyw8ObbfikzXmTtX8fL6vFT329//PXW8ZrqFftbzVnP/8qNy9RTmKwzOXPF hTcrTs2yLY7oUmIpzkg01GIuKk4EAM71EAIwAgAA Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:06:01 -0000 On 2012-06-24 02:54, Glen Zorn wrote: > On Wed, 2012-06-20 at 09:42 +0200, Magnus Westerlund wrote: >> Hi, >> >> I have reviewed the draft and found some significant issues that I think >> should be addressed prior to a WG last call. >> >> 1. Section 4.1: The RTP extension defined in Perkins & Schierl [RFC6051] >> MAY be used to accelerate the synchronization. >> >> I would suggest that you change this to: >> >> The RTP header extension defined in "Rapid Synchronisation of RTP Flows" >> [RFC6051] MAY be used to accelerate the synchronization. >> >> That tells the reader more about which type of extension and what it is >> for than the previous formulation. > > The "Perkins & Schierl" construct was an attempt to avoid the typical > practice of writing something like "[RFC6051] defines...", which is > abominable. However, reproducing the title of a referenced document is > even worse stylistically. How does the existing text not tell the > reader what the extension is for? We are at least in agreement that just an RFC number is insufficient. I have to say that I am currently not confused by the old sentence due to it containing sufficient context to determine which specification it is without remembering all the RFC numbers. I do say that my proposal can be improved significantly when it comes to removing redundancy and make it more readable. That it is horribly stylistically I don't agree with, and I think the benefit in many cases warrants such an approach. Take this as a suggestion from me. > >> >> 2. Section 4.2: I found one sever error in the formula: >> >> First: >> start_offset = (capture_time - capture_start) >> * previous_clock_rate >> >> This is missing to add the original start_offset to the new offset >> calculated. Thus the start_offset calculation should be: >> >> start_offset = (capture_time - capture_start) >> * previous_clock_rate + start_offset > > I'm not sure I understand. By "original start offset", do you mean the > initial vale of the start_offset variable? That is zero, so I don't see > how it helps to add it in every time, so it must be something else? Yes, the first time you switch it will be zero. The next time it will be non-zero and must be included to avoid erronous values after a second switch. > >> >> >> 3. Section 4.2: Then I think the timestamp calculation should make clear >> where the initial random offset is to be added. > > The first paragraph of the section says: > > An RTP Sender with RTCP turned off (i.e. by setting the RS and RR > bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for > each different clock rate but MAY use different clock rates on the > same SSRC as long as _the RTP timestamp without the random offset is > calculated_ > as explained below[...] > Yes, but I think we can improve this by including the random offset into the calculation so they don't do it in the wrong step with the wrong result. Either initially or at the end works. Doing it somewhere in the middle is not a good idea. > >> And to my understanding >> it needs to be added in the timestamp formula which thus should read: >> >> timestamp = (capture_time - capture_start) * clock_rate >> + start_offset + random_initial_offset >> >> Or as an alternative, set the initial values, i.e: >> start_offset = 0 >> >> to >> >> start_offset = random_initial_offset' > > ... -- 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 ----------------------------------------------------------------------