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

Qin Wu <> Tue, 24 July 2012 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EEF821F858F for <>; Tue, 24 Jul 2012 03:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.327
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7xcQZQZUg7gp for <>; Tue, 24 Jul 2012 03:05:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0877021F858E for <>; Tue, 24 Jul 2012 03:05:10 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.2.3-GA FastPath) with ESMTP id AIA38368; Tue, 24 Jul 2012 06:05:10 -0400 (EDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 03:03:19 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 03:03:17 -0700
Received: from w53375 ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 18:00:42 +0800
Message-ID: <>
From: Qin Wu <>
To: Michael Krüger <>
References: <><> <> <> <> <> <>
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: []
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX
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: Tue, 24 Jul 2012 10:05:12 -0000

I tend to agree, thanks again for your clarification.

----- Original Message ----- 
From: "Michael Krüger" <>
To: "Qin Wu" <>
Cc: "Hendrik Scholz" <>; <>
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