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

Michael Krüger <michael.krueger@voipfuture.com> Tue, 24 July 2012 07:08 UTC

Return-Path: <michael.krueger@voipfuture.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 B06BA11E8125 for <xrblock@ietfa.amsl.com>; Tue, 24 Jul 2012 00:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 3fkWaKl5MLlF for <xrblock@ietfa.amsl.com>; Tue, 24 Jul 2012 00:08:36 -0700 (PDT)
Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id D383A11E8119 for <xrblock@ietf.org>; Tue, 24 Jul 2012 00:08:35 -0700 (PDT)
X-Footer: dm9pcGZ1dHVyZS5jb20=
Received: from mickru-macbook.voipfuture.com ([192.168.1.1]) (authenticated user mkrueger@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.4.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Tue, 24 Jul 2012 08:54:57 +0200
Message-ID: <500E49E3.50500@voipfuture.com>
Date: Tue, 24 Jul 2012 09:08:19 +0200
From: Michael Krüger <michael.krueger@voipfuture.com>
Organization: VOIPFUTURE
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.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>
In-Reply-To: <8D8E6A1D85AA4AD09E35ADC74F2DF8D4@china.huawei.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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 07:08:36 -0000

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
>