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

Qin Wu <bill.wu@huawei.com> Thu, 18 October 2012 02:48 UTC

Return-Path: <bill.wu@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 C24D11F0381 for <xrblock@ietfa.amsl.com>; Wed, 17 Oct 2012 19:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level:
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KekmsfRbq2V2 for <xrblock@ietfa.amsl.com>; Wed, 17 Oct 2012 19:48:44 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23F21F847B for <xrblock@ietf.org>; Wed, 17 Oct 2012 19:48:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS78307; Thu, 18 Oct 2012 02:48:40 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 03:48:02 +0100
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 03:48:38 +0100
Received: from w53375 (10.138.41.149) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 10:47:47 +0800
Message-ID: <B3D6F58FCA484506B3E7511934CF17B0@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: "Claire Bi(jiayu)" <bijy@sttri.com.cn>, xrblock <xrblock@ietf.org>
References: <691926375.1521350523195312.JavaMail.hermes@ent-web2>
Date: Thu, 18 Oct 2012 10:47:46 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0380_01CDAD1E.02AB7E70"
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
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, 18 Oct 2012 02:48:45 -0000

Hi,Claire:
Thank for your reivew to draft-ietf-xrblock-rtcp-xr-synchronization-00.
Below is my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Claire Bi(jiayu) 
  To: xrblock 
  Sent: Thursday, October 18, 2012 9:19 AM
  Subject: [xrblock] Comments on draft-ietf-xrblock-rtcp-xr-synchronization-00


  Hi, 

  I was asked to review draft-ietf-xrblock-rtcp-xr-synchronization-00 and have the following several comments. 

  1. Section 2.1, Synchronization Offset 
  Is Synchronization Offset a absolute value or relative value? Is Synchronizztion Offset delay variance or Delay Variation? 

[Qin]: Our intention is to define Synchronization Offset as relative value. Synchronization offset is actually the time difference between two media streams
that need to be synchronized. So I like to propose the following change to the defintion of Synchronization Offset in the terminology section.
OLD TEXT:
"
   Synchronization Offset:

      The absolute delay variance of the measured RTP stream relative to
      the reference RTP stream in the multimedia session.

"
NEW TEXT:
"
   Synchronization Offset:

 

      Synchronization between two media streams must be maintained to
     ensure satisfactory QoE. Two media streams can be of the same
    media type belonging to one RTP session or in different media types 
   belonging to one multimedia session. The Synchronization Offset is the
   relative time difference of the two media streams that need to be synchronized.
"
   
  2. Section 3, last Paragraph said: 
  " 
     For example, 
     one audio stream and one video stream belong to the same session and 
     audio stream are transmitted lag behind video stream for multiple 
     tens of milliseconds.  The RTP Flows Synchronization Offset block can 
     be used to report such synchronization offset between video stream 
     and audio stream 
  " 
  Would you like to provide a reference to this example? 

[Qin]: On relevant reference in my mind is BBF Forum document TR-126.
I will put it into the next version.
   
  3. Section 4.2 
  s/Statistics Summary Report Block/RTP Flows Initial Synchronization Delay Report Block 

[Qin]: Good catch, thanks.
   
  4. Section4.2 Definition of Initial Synchronization Delay 
  It is not clear how to use in-band mapping of RTP and NTP-format timestamps to calculate 
  the intial Synchronization Delay, it is better to add text to clarify this. 
   
[Qin]: Okay, I propose the following change to the definition of Initial Synchronization Delay.
OLD TEXT:
"
   Initial Synchronization Delay: 32 bits

      The average delay, expressed in units of 1/65536 seconds, from the
      RTCP packets received on all of the components RTP sessions to the
      beginning of session [RFC6051].  The value is calculated based on
      the information contained in RTCP SR packets or the in-band
      mapping of RTP and NTP-format timestamps [RFC6051].  If there is
      no packet loss, the initial synchronization delay is expected to
      be equal to the average time taken to receive the first RTCP
      packet in the RTP session with the longest RTCP reporting
      interval.

"
NEW TEXT:
"
      The average delay, expressed in units of 1/65536 seconds, from the

      RTCP packets received on all of the components RTP sessions to the

      beginning of session [RFC6051].  The value is calculated based on

      received  RTCP SR packets or the RTP header extension containing in-band

      mapping of RTP and NTP-format timestamps [RFC6051].  If there is

      no packet loss, the initial synchronization delay is expected to

      be equal to the average time taken to receive the first RTCP

      packet in the RTP session with the longest RTCP reporting

      interval or the average time taken to receive the first RTP header 

      extension containing in-band mapping of RTP and NTP-format timestamps.

"
   
  Claire 
   
   
   


------------------------------------------------------------------------------


  _______________________________________________
  xrblock mailing list
  xrblock@ietf.org
  https://www.ietf.org/mailman/listinfo/xrblock