Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

From: Qin Wu <[email-masked]>
Date: Mon, 3 Jun 2013 12:03:53 +0000

Hi, Roni:
Please see my reply inline.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, May 31, 2013 10:51 PM
To: 'Shida Schubert'; 'xrblock'
Cc: 'xrblock-chairs'
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Hi,
I reviewed the document and it look good. I have one comment.
In the offer answer section it will be good to explain if the threshold is
declared by the offer or is it negotiated.

[Qin]: Since media sent by the entity that
 generated the SDP in one direction, I think the threshold is declared by the offer.

Small nit in the beginning of section 4
"This sub-block described here are intended" should be " This sub-block
described here is intended"

[Qin]: Good catch, thanks.

Roni
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shida Schubert
> Sent: 29 May, 2013 7:54 PM
> To: xrblock
> Cc: xrblock-chairs
> Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> 
> This is an announcement of a 2 weeks XRBLOCK WG last call on "Report Block
> for Concealment metrics Reporting on Audio Applications"
> prior to requesting publication of the document as a proposed standard.
> 
>  As per discussion at the last meeting, we are running a second WGLC on
this
> draft.
> 
> Please send your comments, including nits, to the list by the
> 
> 12th of June
> 
> If you read the draft and you see no issues, concerns, or nits, please
express
> the fact that you have no issue progressing the draft on the list as well.
> 
> The latest version can be found here:
> 
> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> 
> Regards
> 
> Shida as co-chair
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: "Roni Even" <[email-masked]>
Date: Mon, 3 Jun 2013 15:10:50 +0300

Hi Qin,
This is OK, it should be mentioned in the document that this parameter is
declared by the offerer.
Roni

> From: Qin Wu [mailto:[email-masked]]
> Sent: 03 June, 2013 3:04 PM
> To: Roni Even; 'Shida Schubert'; 'xrblock'
> Cc: 'xrblock-chairs'
> Subject: RE: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> 
> Hi, Roni:
> Behalf Of Roni Even
> [Qin]: Since media sent by the entity that  generated the SDP in one
> direction, I think the threshold is declared by the offer.
> 
> > This is an announcement of a 2 weeks XRBLOCK WG last call on "Report
> > Block for Concealment metrics Reporting on Audio Applications"

---

From: Qin Wu <[email-masked]>
Date: Mon, 3 Jun 2013 12:14:43 +0000

Yes, I agree with you. Thanks!

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Monday, June 03, 2013 8:11 PM
To: Qin Wu; 'Shida Schubert'; 'xrblock'
Cc: 'xrblock-chairs'
Subject: RE: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Hi Qin,

---

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Jun 2013 17:01:30 +0100

Shida,

I've read the draft, and believe it's in reasonable shape to progress. I would be interested in hearing the authors' rationale for choosing ms as the measurement unit rather than RTP timestamp units, however. It would seem that there might be an argument for using RTP timestamp units, so the reports can exactly line-up with the audio data in the RTP packets.

Colin

On 29 May 2013, at 17:53, Shida Schubert wrote:
> This is an announcement of a 2 weeks XRBLOCK WG last call on 
> "Report Block for Concealment metrics Reporting on Audio Applications" 
> As per discussion at the last meeting, we are running a second 
> WGLC on this draft.
> 
> express the fact that you have no issue progressing the draft on the
> list as well. 
> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Thu, 13 Jun 2013 05:34:51 +0000

Colin,
Yes, you are right.
The length of time represented by audio playload in the RTP packet is usually measured using ms.
Another rationale is concealment metrics are just terminal related end system metrics and its 
calculation does not need to rely on RTP timestamp in the RTP packet.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: Wednesday, June 12, 2013 12:02 AM
To: Shida Schubert
Cc: xrblock-chairs; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Shida,

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Jun 2013 23:10:19 +0100

Qin,

The length of time represented by an audio payload tends to be an integer number of milliseconds for frame-based codecs, but can have an arbitrary length for sample-based codecs. Using RTP timestamp units might allow you to precisely match up the timings, if that matters. Plus, don't you have RTP timestamp units, but would need to convert to milliseconds?

Colin

On 13 Jun 2013, at 06:34, Qin Wu wrote:
> Another rationale is concealment metrics are just terminal related end system metrics and its calculation does not need to rely on RTP timestamp in the RTP packet.
> 
> Regards!
> -Qin

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Jun 2013 03:20:33 +0000

Good points. I fully agree.
However changing measurement unit from RTP timestamp unit to ms may cause measurement unit inconsistency.

Taking loss concealment metrics block as an example, both 32 bit On-time Playout Duration field and 16 bit Mean Playout Interrupt Size uses the same measurement unit (ms), if we only change measurement unit for all 32 bit fields that carry loss concealment metrics to RTP timestamp unit, this cause
Some fields in the block use "ms" as unit, some field uses RTP timestamp unit.

Taking concealment seconds metrics as another example, "SCS Threshold" field also uses milliseconds as unit.

Let me know what you think of this?

Regards!
-Qin
-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Tuesday, June 18, 2013 6:10 AM
To: Qin Wu
Cc: Shida Schubert; xrblock-chairs; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Qin,

Colin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Jun 2013 18:19:48 +0100

Qin,

Makes sense, thanks. 

Colin

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Jun 2013 00:35:54 +0000

Thanks!

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, June 20, 2013 1:20 AM
To: Qin Wu
Cc: Shida Schubert; xrblock-chairs; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Qin,

Makes sense, thanks. 

Colin

---

From: Kevin Gross <[email-masked]>
Date: Sun, 30 Jun 2013 09:24:28 -0600

I doesn't quite make sense to me.

It seems like reporting in RTP timestamp units would make things better for
both the reporter and reportee. The reporter won't need to maintain a
separate higher-precision counter and then do a conversion for reporting.
(Or not implement a higher-precision counter and under report in the
presence of frequent short events.) The reportee receives higher-precision
reports.

SCS threshold might be better represented as a fraction 0/255 to 255/255.
This resolves your mixed-units concern and allows a wider range of SCS
behavior.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Wed, Jun 19, 2013 at 6:35 PM, Qin Wu <[email-masked]> wrote:

> > Taking loss concealment metrics block as an example, both 32 bit On-time
> Playout Duration field and 16 bit Mean Playout Interrupt Size uses the same
> measurement unit (ms), if we only change measurement unit for all 32 bit
> fields that carry loss concealment metrics to RTP timestamp unit, this cause
> > Subject: Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> >
> > Qin,
> >
> > The length of time represented by an audio payload tends to be an
> integer number of milliseconds for frame-based codecs, but can have an
> arbitrary length for sample-based codecs. Using RTP timestamp units might
> allow you to precisely match up the timings, if that matters. Plus, don't
> you have RTP timestamp units, but would need to convert to milliseconds?
> >
> > Colin
> >
> >
> >
> >> Another rationale is concealment metrics are just terminal related end
> system metrics and its calculation does not need to rely on RTP timestamp
> in the RTP packet.
> >>
> >> Regards!
> >> -Qin
> Behalf Of Colin Perkins
> >> Subject: Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> >>
> >> Shida,
> >>
> >> I've read the draft, and believe it's in reasonable shape to progress.
> I would be interested in hearing the authors' rationale for choosing ms as
> the measurement unit rather than RTP timestamp units, however. It would
> seem that there might be an argument for using RTP timestamp units, so the
> reports can exactly line-up with the audio data in the RTP packets.
> >>
> >> Colin
> >>
> >>
> >>