IETF Logo Mail Archive

Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Thu, 25 October 2012 02:18 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F01F0C3A for <xrblock@ietfa.amsl.com>; Wed, 24 Oct 2012 19:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.494
X-Spam-Level:
X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHr4kazEUvwz for <xrblock@ietfa.amsl.com>; Wed, 24 Oct 2012 19:18:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ABD1F21F8F12 for <xrblock@ietf.org>; Wed, 24 Oct 2012 19:18:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX55249; Thu, 25 Oct 2012 02:18:05 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 25 Oct 2012 03:17:52 +0100
Received: from SZXEML446-HUB.china.huawei.com (10.82.67.184) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 25 Oct 2012 10:18:04 +0800
Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.26]) by szxeml446-hub.china.huawei.com ([10.82.67.184]) with mapi id 14.01.0323.003; Thu, 25 Oct 2012 10:17:12 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00
Thread-Index: Ac2s4Ppsq1aQJ1QLSjqaYsxy0WpXigE0faeAACbQTMA=
Date: Thu, 25 Oct 2012 02:17:11 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB443AB6A8@szxeml539-mbx.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB4438F16F@szxeml539-mbx.china.huawei.com> <5D5EF107-BD78-410E-8E81-BC3228B91339@csperkins.org>
In-Reply-To: <5D5EF107-BD78-410E-8E81-BC3228B91339@csperkins.org>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 02:18:08 -0000

Hi Colin,

Please see inline.

Best Regards!
Rachel

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org] 
Sent: Wednesday, October 24, 2012 10:44 PM
To: Huangyihong (Rachel)
Cc: xrblock@ietf.org
Subject: Re: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00

On 18 Oct 2012, at 04:30, Huangyihong (Rachel) wrote:
> Hi folks,
>  
> I have 2 comments for draft-ietf-xrblock-rtcp-xr-synchronization:
>  
> 1.       In RTP flows synchronization offset metric block, only one SSRC set to the SSRC of the reference RTP stream has been specified. IMO,  the SSRC of the reporting stream should be also required.
> 2.       Synchronization offset is a 64-bit unsigned fixed-point number. No indication shows which stream, the reporting stream or the reference stream,  is lag behind. So I propose to split one bit from "Reserved" field to indicate the offset direction.

It would probably be easier to implement if you made the Synchronisation Offset a signed 64 bit value, rather than an unsigned 64 bit value and a separate sign bit.

[Rachel]: The reason I proposed that is because the synchronization offset is represented using the timestamp format of NTP (a 64-bit unsigned fixed-point number), which I think it's better to keep it unchanged.  Are you suggesting to use a nonstandard format instead of the standard NTP format? But you're right that it may be easier for implementations to use a signed value to tell fast or slow from 2 streams.
-- 
Colin Perkins
http://csperkins.org/

v2.23.0 | Report a Bug | By Email