Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

"Roni Even" <> Thu, 20 December 2012 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2AE221F863B for <>; Thu, 20 Dec 2012 00:47:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 58fiUrBM6gK7 for <>; Thu, 20 Dec 2012 00:47:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5C18B21F8635 for <>; Thu, 20 Dec 2012 00:47:06 -0800 (PST)
Received: by with SMTP id e53so1525995eek.19 for <>; Thu, 20 Dec 2012 00:47:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=/xGcA96ccJnTXfhmtrWVWkXs5qM3GhL2arQNHUQfOY8=; b=rWxkq96yaP+MAu5LGqwT/8aiE4GUAUSgrfivKXAM7GaPkpXhuL+QBYVIFkuyWYH/ry lU+TnDpc/GYKjUd1shg5Jex05dBkvsIBPofFmqR7sps0c55n8CqtJc3etio7NOPaRFJP 14EAZehI/+ruX4AbheEe9y5+a216hcNkQ0v+imxCFG/mj/+UG9uksk3blSBdZJOh+NJs C+U/CCsF/sKR43qD1LMQgY5gzvgNUN1+YcSbgmk7rHlheqySZjMi+Pw8i952POS1u2x3 JM6FcSwyMSJ+Iih1aUaUSHUzLWnzkFm7TgD13x5xLv9t9K33SKfqwmjd1TaSx/xuNUTW rMzg==
X-Received: by with SMTP id c1mr21705136eem.8.1355993225365; Thu, 20 Dec 2012 00:47:05 -0800 (PST)
Received: from RoniE ( []) by with ESMTPS id q44sm14107153eep.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 00:47:04 -0800 (PST)
From: Roni Even <>
To: 'Qin Wu' <>, "'Romascanu, Dan (Dan)'" <>,
References: <> <03ed01cdddea$abe24170$03a6c450$> <>
In-Reply-To: <>
Date: Thu, 20 Dec 2012 10:44:17 +0200
Message-ID: <046a01cdde8e$34df8ac0$9e9ea040$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFQjZvMYLqHDMrRdEtJf889psq3PQJqcleCAZdBnl6Y+/MH4A==
Content-Language: en-us
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Dec 2012 08:47:07 -0000

Hi Qin,
Thanks for the explanation. I see no problem with the current parameters. I
assume that we can define  later a second report block that will cover the
other parameters and it will be inline with the concepts of the monitoring

-----Original Message-----
From: Qin Wu [] 
Sent: 20 December, 2012 3:57 AM
To: Roni Even; 'Romascanu, Dan (Dan)';
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Hi, Roni:
Thank for raising this issue.
 In this draft, we are not choosing to report all indications in the first
priority and second priority. Instead, we are choosing to report all the
parameters that can be easily gathered by parsing the TS header. What we
ignore is all the other PSI/SI related parameters in the first priority and
second priority. These parameters usually fixs and repeatly occur in the
received stream and need deep parsing not only TS header but also TS payload
which introduce complexity in the test and measurment instrument. However I
do agree with you these PSI/SI related parameters are still very important
parameters. Any error of these PSI/SI related parameters will lead to very
serious quality problem.

Regarding the option you proposed, I am not favoring the second approach
since it doesn't solve the problem you raised and we already clarified the
parameter we are taking belong to 1st and 2nd prioirty in the description
before the format. I checked section 5.3.5 of TR 101.290, which provide TS
parameters in transmission system with "reduced SI data". I think if we
really want to take some new parameters, we like to choose to take
additional missing parameters in the 1st and 2nd priority of section 5.3.5,
which belong to "reduced SI data".

Otherwise we prefer to leave as it is. 

----- Original Message -----
From: "Roni Even" <>
To: "'Romascanu, Dan (Dan)'" <>; <>
Sent: Wednesday, December 19, 2012 9:13 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

> Hi,
> Sorry for the late posting.
> I noticed that ETSI TR 101 290 has eight first priority and eight second
> priority indications (section 5.2.1 and 5.2.2) while here we list only
> of them claiming that the others do not apply to all MPEG implementations.

> I do not have a major problem with keeping the XR block as is but we can
> look at two other options.
> 1. Have all 16 indications.
> 2 Add two new parameters " # of First Priority Errors"  and   "# of Second
> Priority Errors  "
> Roni Even
> -----Original Message-----
> From: [] On Behalf
> Of Romascanu, Dan (Dan)
> Sent: 29 November, 2012 2:48 PM
> To:
> Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> This is a Working Group Last Call for
> Please read and review this document, and send your comments, questions
> concerns to the WG list before December 13, 2012. If you have no comments
> and you believe that the document is ready for submission to the IESG as a
> Standards Track document please send a short message as well to help us in
> determining the level of review and consensus. 
> Thanks and Regards,
> Dan
> _______________________________________________
> xrblock mailing list
> _______________________________________________
> xrblock mailing list