Re: Stats proposal, updated

On 07/20/2012 12:49 PM, Harald Alvestrand wrote:
> On 07/02/2012 05:56 PM, Stefan Hakansson LK wrote:
>> On 06/28/2012 11:53 AM, Harald Alvestrand wrote:
>>> I'm on holiday, but wanted to respond to this briefly....
>>>
>>> On 06/25/2012 09:22 AM, Stefan Hakansson LK wrote:
>>>> On 06/21/2012 02:24 PM, Harald Alvestrand wrote:
...
>>>> One drawback is that only the receiving app would get the stats
>>>> associated with the PeerConnection transport.
>>> I think this is a fatal flaw - it means that the sender can't tell if
>>> the recipient is suffering packet loss, for instance. Given that the
>>> information is already delivered to the sender node by means of RTCP, it
>>> seems strange not to give access to it locally. I don't see a reason to
>>> accept this drawback.
>>
>> The sender's app could see if the receiver's app send the info over
>> (e.g using the data channel).
> Only if they're the same app, or have standardized another interface for
> that purpose. We already have RTCP.

It is true that the app developers would have to agree on interface and 
format (as well as frequency etc.) to exchange this info. That could be 
done as a standard, or by just agreeing. However, if two apps, developed 
independently, are to interoperate, this would just be an additional 
thing to agree on. Say I have domain mydomain.com, and have my users 
registered there. You operate your independent yourdomain.com, with your 
users etc. If my app would be to interoperate with your, we would have 
to agree on a lot of things, like how users in the two domains are able 
to find each other,  if (and how) we exchange presence info of our 
users, how we exchange invitations to communicate (sure, it could be an 
SDP object, but how is it sent?), how we exchange accept/reject, and so 
on. It is not like my app can send an SDP offer to my web server 
(perhaps over a WebSocket), and things then just happen. Agreeing on how 
to exchange stats would just be a minor addition to all other things 
needed (and that we don't standardize) to agree on.

But I do see the value of the sender of RTP being able to monitor the 
quality when the other end is a GW (to legacy perhaps). It might be 
difficult to make that GW send statistics to my app. OTOH, ideally you 
would like stats from the other end-point in that case, as there may be 
packets dropped, jitter etc. on the other side of the GW. But knowing 
what happens up to the GW is of course helpful.

Received on Sunday, 22 July 2012 18:54:18 UTC