Re: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt

[Alan Clark <[e-mail]>]

Qin

Wideband codecs are often used on conference phones - also AMR-WB is the
default codec for 4G LTE.

We have some application notes and standards contributions related to this
on our web site - I'll forward a copy of relevant documents to you "off
list"

Alan



On 8/27/12 10:33 PM, "Qin Wu" <[e-mail]> wrote:

> Hi, Alan:
> Given the popularity of the Japan national standards (i.e.,TTC 201.01) in
> Japan, 
> we can add TTC 201.01 based algorithm as one new calculation algorithm  in the
> QoE Metric Block.
> Currently we still allow support additional 5 new calculation algorithms using
> 3bit CAlg.
> 
> Regarding MoS Reference, are you suggesting we should differentiate low bit
> rate from high bit rate
> or we should differeniate narrowband from wideband?
> It looks to me narrowband and wideband only can be used with audio stream and
> don't apply to video?
> 
> Another question is I am not familiar with the terminology "MoS reference".
> Would you like to point me a reference to explain what "MoS Reference" is?
> Thanks!
> 
> Regards!
> -Qin
>  ----- Original Message -----
> From: "Alan Clark" <[e-mail]>
> To: "Qin Wu" <[e-mail]>; <[e-mail]>; "Al Morton"
> <[e-mail]>
> Sent: Thursday, August 16, 2012 10:58 PM
> Subject: Re: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt
> 
> 
>> 
>> Some further work is definitely needed on this draft with regard to the MOS
>> terminology. The various calculation methods for MOS either already do, or
>> soon will, provide MOS values for narrowband, wideband, super wideband and
>> fullband codecs; these MOS values occupy the same range and hence the QoE
>> block needs to indicate what the MOS reference is.
>> In addition there are national standards (e.g. Japan) that use a different
>> MOS scaling.
>> 
>> Alan
>> 
>> 
>> 
>> On 8/15/12 10:33 PM, "Qin Wu" <[e-mail]> wrote:
>> 
>>> Hi, Al:
>>> Thank for your general comments, I take some time to look at the standards
>>> for
>>> calculation again.
>>> please see my replies inline.
>>> 
>>> Regards!
>>> -Qin
>>> ----- Original Message -----
>>> From: "Al Morton" <[e-mail]>
>>> To: <[e-mail]>
>>> Sent: Thursday, August 02, 2012 5:01 AM
>>> Subject: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt
>>> 
>>> 
>>>> Regarding:
>>>> http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-qoe-02.txt
>>>> 
>>>>>    Calculation Algorithm (CALg):3 bits
>>>>> 
>>>>>          000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)
>>>>>          001 - G.107 [G.107] (Voice)
>>>>>          010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice)
>>>>>          011 - ITU-T P.NAMS [P.NAMS] (Multimedia)
>>>>>          100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia)
>>>>>          101~111 - Reserved for future extension.
>>>>> 
>>>>>       G.107 and P.564 and ETSI TS101 329-5 specify three Calculation
>>>>>       algorithms or MoS algorithms that are used to estimate speech
>>>>>       quality or conversation quality.  P.NAMS and P.NBAMS specify two
>>>>>       MoS algorithms that are used to estimate multimedia quality
>>>>>       including video quality, audio quality and audio-video quality.
>>>> 
>>>> Specifying the standard for the calculation is a good start,
>>>> but these standards all have options and input parameters
>>>> that must also be specified in order to know what the MOS means.
>>> 
>>>> For example, we need to know what codec was used, because G.726
>>>> carries an equipment Impairment factor that limits the upper
>>>> bound on MOS, while G.711 does not.
>>> 
>>> [Qin]: I agree MoS value depends on the codec that is in use. That's why, in
>>> the current draft,
>>> We use 7-bit payload Type in the metric block to signal what codec or
>>> payload
>>> format is
>>>  in use for reporting interval.
>>> Please see the definition of Payload Type (PT) in the section 3.2.1.
>>> 
>>>> 
>>>> Some of the input parameters will be assumed (e.g., at default values)
>>>> while others will be measured, and the distinction between measured
>>>> and assumed parameters should also be made.
>>> 
>>> [Qin]: 
>>> The input parameters may come from Delay metric block, Discard metric block,
>>> Burst Gap metrics block, JB metrics block, loss concealment metric block,
>>> concelament seconds
>>> metrics block, these metrics blocks are defined in other XR Block drafts by
>>> XRBLOCK WG .
>>> 
>>> In QoE metric block, 4 or 5 pameters are defined, i.e.,
>>> a.Segment Type
>>> b.MoS Type
>>> c.MoS algorithm
>>> d. MoS value
>>> In these parameters, a~c can be counted as default values while d is counted
>>> as measured value.
>>> The other default values rely on specific computation model defined in each
>>> standard, e.g.,
>>> P.564, G.104, P.NAMS.
>>> Assume each standard only provide one algorithm or one model, we can use
>>> the
>>> standards name and payload type(i.e.,codec)
>>> to identify each MoS algorithm used or each MoS model used.
>>> 
>>>> As I mentioned, metrics with many optional parameters are somewhat
>>>> difficult to identify in a simple way, as we found with the IPPM
>>>> Metrics Registry (which we withdrew when we found it was insufficient
>>>> to describe the measurement results in an exact way).
>>>> 
>>>> Colin Perkins suggested the possibility a registry for the calculation alg.
>>>> A registry could provide a single value index to a complicated set of
>>>> input parameters and other assumptions, and this might work for you.
>>> 
>>> [Qin]: Yes,depends on the input parameters and option we got, we can
>>> calculate
>>> the different MoS values however the computation model is same and will not
>>> be
>>> affected by the input parameters and options.
>>> So maybe rather than registering MoS algorithm, we should register
>>> assessment
>>> model or computation model.
>>> We can use computation model defined in the standard and payload type as
>>> single value index.
>>> 
>>>> hope this helps,
>>>> Al
>>>> 
>>>> 
>>>> _______________________________________________
>>>> xrblock mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>>> 
>>> _______________________________________________
>>> xrblock mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xrblock
>> 
>> 
>> 
>> _______________________________________________
>> xrblock mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xrblock