Re: [rtcweb] RTP Usage: RTCP XR metrics

[Magnus Westerlund <[e-mail]>]

On 2013-02-20 06:13, Qin Wu wrote:
> Hi, Colin:
> My aim is these block types are RECOMMENDED to be implemented, for
justification on why they are recommened,
> I think we can go to look at four RTCWeb communication requirements:

> "
>    F5            The browser MUST be able to render good quality
>                    audio and video even in the presence of
>                    reasonable levels of jitter and packet losses.
> 
> 
>    F6            The browser MUST be able to handle high loss and
>                    jitter levels in a graceful way.
> 
>    F10           The browser MUST support synchronization of
>                    audio and video.
> 
>    F38          The browser MUST be able to collect statistics,
>                    related to the transport of audio and video
>                    between peers, needed to estimate quality of
>                    service.
> " So my point is if you want to ask browser to ensure good quality
> for both audio and video in the presence of centain level of jitter and losses,
> you should be able to report jitter and losses to help you know what
> current level of jitter and packet loss is. You may need to collect more
> detailed statistics to help you decide what level of jitter and loss you
> don't want to exceed? PDV metrics block tell you more higher resolution of
> jitter comparing with using interarrival jitter provided by RTCP
> SR/RR. Statistics Summary Report Block defined in RFC3611 tell you
> how many packets are lost in a certain sequence number interval.
> burst loss rate, gap loss rate defined in the
> draft-ietf-xrblock-rtcp-xr-summary-stat tell you Proportion of packet
> lost. Therefore these relevant metrics block SHOULD
> be listed as "RECOMMENDED to be implemented", in my opinion.
> 

I don't see the strong requirements of how the WebRTC endpoint
implementation quality requirements (F5, F6 and F10) are strongly linked
to the F38.

One type of arguments is that the peer endpoint being provided with RTCP
XR reports will function better in providing media quality. I don't know
if that is true for the metrics you listed.

A second line of reasoning is around how F38 is addressed. Especially in
the light that the WebRTC endpoints that are browsers will have a stats
API that allows one to get that side of information, assuming that one
has access to influence the JS application and can upload the data to
where it is needed.

For these stats I think the potential motivation for RTCP XR boils down
to this:
1) The peer is not a Browser but has RTCP XR, and one wants to access
its view of the session, thus receiving and gathering RTCP XR reports
enables one to get a better view of the whole RTP session.

2) One want the collection to be in an WebRTC RTP media plane middlebox,
and it should get the endpoints view also, thus RTCP XR is good.

So do people have those reasons, and what information does one really
need in these contexts?

I think some clearer motivations around RTCP XR and each particular
metrics needs to be stated from any proponent.


> In addtion, Browser need to support synchronization of audio and
video, however how do you know a certain browser lost synchronization of
audio and video. I think Synchronization delay and offset metrics can
tell this. Therefore Synchronization delay and offset metrics, in my
opinion, RECOMMENDED to be implemented.

The question is how needs to know that the receiving browser has failed
or selected to not synchronize the media? I don't see that the sender
can do anything different from what they are doing. As I see it all
falls back to knowing what quality level did this session actually
achieve. Especially for synchronization it might be that losing the sync
was better than to increase the audio delay to 1 second as an example.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------