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

[Alan Clark <[e-mail]>]

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" <[e-mail]> 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