Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX

Qin Wu <bill.wu@huawei.com> Tue, 24 July 2012 10:05 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 0EEF821F858F for <xrblock@ietfa.amsl.com>; Tue, 24 Jul 2012 03:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.327
X-Spam-Level:
X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 7xcQZQZUg7gp for <xrblock@ietfa.amsl.com>; Tue, 24 Jul 2012 03:05:11 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0877021F858E for <xrblock@ietf.org>; Tue, 24 Jul 2012 03:05:10 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIA38368; Tue, 24 Jul 2012 06:05:10 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 03:03:19 -0700
Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 03:03:17 -0700
Received: from w53375 (10.138.41.149) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 18:00:42 +0800
Message-ID: <DB550CE4CF5240DC977EE59045929AA2@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Michael Krüger <michael.krueger@voipfuture.com>
References: <50040877.8040400@123.org><21EDE4323D7E465383A56DE5E1D6C853@china.huawei.com> <50068386.3040409@123.org> <1DB68734A3A342A8859EDEF1AE566491@china.huawei.com> <500D5C22.1080908@voipfuture.com> <8D8E6A1D85AA4AD09E35ADC74F2DF8D4@china.huawei.com> <500E49E3.50500@voipfuture.com>
Date: Tue, 24 Jul 2012 18:00:40 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
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
Cc: xrblock@ietf.org
Subject: Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX
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: Tue, 24 Jul 2012 10:05:12 -0000

I tend to agree, thanks again for your clarification.

Regards!
-Qin
----- Original Message ----- 
From: "Michael Krüger" <michael.krueger@voipfuture.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "Hendrik Scholz" <hs@123.org>; <xrblock@ietf.org>
Sent: Tuesday, July 24, 2012 3:08 PM
Subject: Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX


> Hi, Qin,
> 
> Am 24.07.12 05:20, schrieb Qin Wu:
>> Hi,Michael:
>> Thank for your clarification.
>> One thing I am not clear to your idea  is how to calculate MoS value or Rating value based on stream data from multiple sources?
>> Currently in QoE XR draft, we support MoS calculation per SSRC or MoS calculation per audio channel?
>> It seems you claim you can calculate MoS values based on audio data from multi-channels? 
>> Is that MoS value is the weighted mean of MoS value of each channel? If in that case, what the weight for each 
>> channel MoS calculation?
>> Maybe this is just implemenation specific issue, however I am interested to listen to that.
>> 
> Thank you for your interest.
> Of course we have not reinvented MOS. Our approach is related to ITU-T
> P.564. The audio test samples used in that standard have a minimum
> length of 8-seconds. We therefore assume that one must evaluate at least
> this period of time, to determine a reliable MOS value. What we try to
> achieve with monitoring live traffic, is to determine for every
> individual flow of a VoIP call MOS values for every 10-second segment.
> This provides us with many MOS values over the duration of an individual
> call. Most network impairments are of transient nature, so for every
> call the result will be a distribution of MOS scores falling into one of
> the 5 classes. Depending on the number of seconds in each of the
> classes, it is possible to assess how many seconds of a call have been
> with which quality on the MOS scale 1-5. If this data is available for a
> single flow, call, etc. the seconds of the 5 classes can be aggregated
> over all flows/calls performed between VoIP operators, operators and
> customers, or simply SIP-trunks. This will e.g. allow to come up with
> new SLA agreements where the agreement could possibly be that 99% of all
> VoIP minutes must be in the highest MOS class. The accuracy of this is
> pretty high, since one determines MOS values for only a few seconds of a
> call, bringing every impairment to attention via a lower MOS value for
> the segment in which the impairment occurred. No averaging over a call
> is done, so the distribution of MOS values like this, truly reflects the
> monitored quality.
> 
> Does this make sense to you as well?
> 
> Regards,
> Michael
> 
>> Regards!
>> -Qin
>> 
> 
>