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

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; <[e-mail]>
Sent: Thursday, January 12, 2012 2:50 AM
Subject: Re: [xrblock] Fw: I-DAction:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt


> One more comment inline.
> 
>> -----Original Message-----
>> From: Qin Wu [mailto:[e-mail]]
>> Sent: Monday, January 09, 2012 9:06 PM
>> To: Charles Eckel (eckelcu); [e-mail]
>> Subject: 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)" <[e-mail]>
>> To: "Qin Wu" <[e-mail]>; <[e-mail]>
>> 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.
> 
> I was assuming the intent was for the segment structures defined in
> sections 3.2.1 - 3.2.3 to share the same exact format for the fields up
> to and including the CAlg field.  

[Qin]: That is a good point if we need to include single stream per SSRC segment
with other segment types using the common format in the same draft. But these different 
segment type will not be present in the same XR Block since they deal with different use case
and has distinct usage.

> This could be achieved by allocating space for the Media Type field for
> the single stream per SSC segment even though would not be used.

[Qin]: I like this proposal if we agree one draft is sufficient to 
address the single milestones.

> Cheers,
> Charles
> 
>> 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: [e-mail] [mailto:[e-mail]] On
>> > Behalf Of Qin Wu
>> > Sent: Friday, December 30, 2011 7:53 PM
>> > To: [e-mail]
>> > 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: <[e-mail]>
>> > To: <[e-mail]>
>> > 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
>> > > [e-mail]
>> > > 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
>