IETF Logo Mail Archive

Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG item

Colin Perkins <csp@csperkins.org> Wed, 03 September 2008 11:21 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: avt-archive@optimus.ietf.org
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F9F3A6A1D; Wed, 3 Sep 2008 04:21:44 -0700 (PDT)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54D43A6A1D for <avt@core3.amsl.com>; Wed, 3 Sep 2008 04:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level:
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvYA1XMZkLBE for <avt@core3.amsl.com>; Wed, 3 Sep 2008 04:21:41 -0700 (PDT)
Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id E80943A69C4 for <avt@ietf.org>; Wed, 3 Sep 2008 04:21:40 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:64469) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1KaqPa-0006cI-4F; Wed, 03 Sep 2008 12:20:34 +0100
In-Reply-To: <44C96BEE548AC8429828A37623150347F6169A@vaebe101.NOE.Nokia.com>
References: <48b081ea.01b7660a.391e.ffffd15d@mx.google.com> <23F7C403-DE24-44A1-BDC7-DA8CCDD381B6@csperkins.org> <44C96BEE548AC8429828A37623150347F36820@vaebe101.NOE.Nokia.com> <9EA8709C-26BF-451C-A7F6-5AA89F382524@csperkins.org> <44C96BEE548AC8429828A37623150347F36CBE@vaebe101.NOE.Nokia.com> <E9568156-E394-4644-BA0C-D38840740076@csperkins.org> <ybuzlmqpm5v.fsf@jesup.eng.wgate.com> <F01EBD6A-29D0-4164-8F77-FE92CF9969F6@csperkins.org> <48BDD214.1060304@rogers.com> <44C96BEE548AC8429828A37623150347F613B7@vaebe101.NOE.Nokia.com> <48be3cf0.0af6660a.5b3f.6a52@mx.google.com> <44C96BEE548AC8429828A37623150347F61464@vaebe101.NOE.Nokia.com> <DC35B61D-1BC4-4462-9282-68BE0F1E76A7@csperkins.org> <44C96BEE548AC8429828A37623150347F614FB@vaebe101.NOE.Nokia.com> <4CEB610F-7078-443D-823A-EE477F79116D@csperkins.org> <44C96BEE548AC8429828A37623150347F61605@vaebe101.NOE.Nokia.com> <67B6098E-1738-4C88-9B21-99E29B8AA535@csperkins.org> <44C96BEE548AC8429828A37623150347F6169A@vaebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <0C44B983-287D-44D4-88BF-2108C90FF8F7@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
Date: Wed, 03 Sep 2008 12:20:32 +0100
To: Ye-Kui.Wang@nokia.com
X-Mailer: Apple Mail (2.753.1)
Cc: rjesup@wgate.com, jonathan@vidyo.com, thomas.schierl@hhi.fraunhofer.de, tom.taylor@rogers.com, avt@ietf.org
Subject: Re: [AVT] accepting draft-lakaniemi-avt-rtp-evbr-02 as WG item
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Ye-Kui,

On 3 Sep 2008, at 11:13, <Ye-Kui.Wang@nokia.com> wrote:
> OK - this to me is saying that we MUST NOT specify any decoder order
> recovery based on time synchronization not using the RTCP SR based
> method, regardless of pros and cons. If this is fine with people, then
> let's forget about the RTP timestamp aligned method (and those others
> belonging to this category).
>
> Also, my understanding is that for any improvement to the RTCP SR  
> based
> method, it MUST be generic to be qualified to be considered by AVT.

I might phrase it a little differently: time synchronisation of  
multiple RTP streams, for whatever purpose, must be done using the  
standard RTP mechanism based on RTCP SR packets. If that time  
synchronisation mechanism is found to have problems, those problems  
should be addressed in a general manner, not specific to any  
particular payload format, class of codecs, etc.

-- 
Colin Perkins
http://csperkins.org/



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

v2.23.0 | Report a Bug | By Email