Re: [xrblock] WGLC foraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

----- Original Message ----- 
From: "Hendrik Scholz" <hs@123.org>
To: <xrblock@ietf.org>
Sent: Monday, July 16, 2012 8:43 PM
Subject: Re: [xrblock] WGLC foraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

> Hi,
> 
> line 238:
> This definition is based on the assumption that the observer
> is co-located with the RTP receiver and thus a packet loss/delay
> cannot happen after observation. For RTCP this would be true
> I suppose unless somebody comes up with the idea of generating
> RTCP reports on B2BUAs.
> In case of a 'mid point' monitoring approach the loss/discard numbers 
> may be wrong as a packet may have been lost/delayed on the remaining
> path.

[Qin]: You are right.
Just to clarify this metric is 'transport -related terminal metric', that is to say
this metric will be only measured at the terminal or any endpoints that consume or 
terminate the media stream.

> Should we add a statement to indicate that this is end-to-end (I am
> aware of companies who want to segment the RTP path and generate hop by
> hop RTCP)?

[Qin]: Okay, I propose the following change to the 1st paragraph in the section 3.
OLD TEXT:
"
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the RTP system.

"
NEW TEXT:
"
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the terminal or RTP system that terminates the stream.
"

> line 137:
> There is a superfluous space after '[MONARCH]'

[Qin]: Good catch and will fix this.

> I have no further comments.
> 
> Regards,
>  Hendrik
> 
> -- 
> Hendrik Scholz <hs@123.org>
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock