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

Exactly.

Regards!
-Qin
----- Original Message ----- 
From: "Alan Clark" <alan.d.clark@telchemy.com>
To: "Hendrik Scholz" <hs@123.org>; <xrblock@ietf.org>
Sent: Monday, July 16, 2012 8:53 PM
Subject: Re: [xrblock] WGLC foraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

> Hi Hendrik
> 
> It is quite likely that RTCP XR reports could be generated by something that
> is not the literal endpoint, for example a B2BUA, transcoding gateway or
> trunking gateway. From this perspective, there would often be issues that
> affect media quality after the measurement point.
> 
> The draft should make it clear that the reported metrics apply to the
> termination point of the RTP stream, whether that is the eventual endpoint
> or not. This would be consistent with RFC3550.
> 
> Regards
> 
> Alan
> 
> 
> 
> On 7/16/12 8:43 AM, "Hendrik Scholz" <hs@123.org> wrote:
> 
>> 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.
>> 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)?
>> 
>> line 137:
>> There is a superfluous space after '[MONARCH]'
>> 
>> I have no further comments.
>> 
>> Regards,
>>   Hendrik
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock