Re: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt

Hi, Charles:
Thank for your detailed review, please see my replies inline.
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Qin Wu" <bill.wu@huawei.com>; <xrblock@ietf.org>
Sent: Tuesday, January 10, 2012 7:44 AM
Subject: RE: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt

(As an individual)

Hi Qin,

I read the draft and have the following comments:

Section 3.2.1-3, the descriptions of segment type, media type, and MoS
type are not consistent. Section 3.2.1 is missing the media type, and
the length of the MoS type field is not consistent.

[Qin]: Unlike Multi-layer per SSRC segment and Multi-Channel per SSRC segment,
single stream per SSRC segment applies to all the media types or all the applications.
Thefore in the format of single stream per SSRC segment, we don't allocate one bit to 
distinguish between different media type.

As for the length of the MoS type field,  I am not sure I catch your comment.
since we allocate 4 bit for MoS type in all three type of segments we defined in this document.

Section 3.2.2, I agree with the editor's note that additional
information on the sub stream id field is needed.

[Qin]: I think the movtiation to define Sub stream identifier is to identify each layer using SSID from base layer, 
enhancement layer 1, enhancement layer 2, etc since SSRC is not sufficient to identify each of them when they 
share the same SSRC.

Maybe we can directly assign each layer with the integer value from 0 to n using the following mapping:
SSID     SSID description
 0           base layer
1            enhancement layer 1
2            enhancement layer 2
...............
n            enhancement layer n

Section 3.2.3, it is not clear to me how the Channel identifier will be
used. With 4 bits, you can identify the channel, but how do you express
how many channels there are. For example, don't you need to be able to
say, this is channel 2 of 5, or 1 or 2, etc.? Is the assumption that you
will always have a segment for each channel; therefore, the number of
channels is always defined implicitly by the number of channel segments?

[Qin]: That's a good question.
I think the number of channel should be indicated in SDP signaling to each associated RTP payload type.
One example is RFC3640 "RTP Payload Format for Transport of MPEG-4 Elementary Streams"
Please see the section 3.3.1 of RFC3640
"
3.3.  Usage of this Specification

3.3.1.  General

The general form of an rtpmap attribute is:

   a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
             parameters>]

   For audio streams, <encoding parameters> specifies the number of
   audio channels: 2 for stereo material (see RFC 2327 [5]) and 1 for
   mono.
"
.

As a general comment, I too would like to hear comments from those who
are doing application MoS calculations.

Cheers,
Charles

> -----Original Message-----
> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
> Behalf Of Qin Wu
> Sent: Friday, December 30, 2011 7:53 PM
> To: xrblock@ietf.org
> Subject: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> 
> One more update to QoE metric reporting draft.
>  http://www.ietf.org/internet-drafts/draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> 
> This draft defines three segment type to support the following three
> different cases:
> 1. multimedia session where each type of media are sent in a separate
>    RTP stream or the layered video session where each layer video are
> sent in a separate RTP
>    stream.
> 2. the layered video session where multi-layer video are carried in
the
> same RTP stream
> 3. the multi-channel audio session where multi-channel voice data are
> carried in the same RTP stream
> 
> Comparing with the first case, the second and third cases more focus
on
> application specific MoS value reporting
> and but deal with the situation where the case 1 canot  deal with.
> 
> Comments and suggestions are welcome. It will be good to also hear the
> opinion from people
> who are doing VOIP application MoS calculation.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: <internet-drafts@ietf.org>
> To: <i-d-announce@ietf.org>
> Sent: Saturday, December 31, 2011 11:38 AM
> Subject: I-D Action:
draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt
> 
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > Title           : RTCP XR Blocks for QoE metric reporting
> > Author(s)       : Geoff Hunt
> >                          Alan Clark
> >                          Qin Wu
> >                          Roland Schott
> >                          Glen Zorn
> > Filename        : draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt
> > Pages           : 18
> > Date            : 2011-12-30
> >
> >   This document defines an RTCP XR Report Block and associated SDP
> >   parameters that allow the reporting of QoE metrics for use in a
> range
> >   of RTP applications.
> >
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock