Re: Stats proposal, updated

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:
>> As usual, apologies for the formatting, and errors in the WebIDL is a
>> certainty, not a possibility.
>>
>> I've tried to insert the level of indirection that allows us to return a
>> set of objects for (say) a media stream with FEC that uses multiple
>> SSRCs rather than just a single object.
>
> I think the proposed stats to track look like a good start, but I 
> think that an additional one that could be of interest is the actual 
> interface/network used. The app gets to know (sort of) what interfaces 
> that are available since the candidates are handled by the app. But 
> knowing what interface that was in actual use could be very helpful.
>
> Regarding the API, an alternative approach could be to tie this more 
> to the tracks of the MediaStreams, e.g. add something to the 
> MediaStreamTrack interface:
>
>     void getInfo(Function handler);
>
> The info delivered would depend on the source of the track. For tracks 
> in local (i.e. generated locally and not delivered by a 
> PeerConnection) MediaStreams, the info would be things like sampling 
> rate, channels (mono, 5.1) for audio; resolution and frame rate for 
> video. If the MediaStream has traveled over a PeerConnection, the info 
> listed in your document (packets received/lost, ssrc, codec, ) would 
> be appended.
>
> This would associate the stats to a MediaStreamTrack, getting rid of 
> referencing problems (when MediaStreams are added or removed) if the 
> local/remoteStreams is used. In addition, if the corresponding info is 
> requested for data channels, it could easily be added to those.
>
> 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.

> But as said, the main receiver of stats is the service provider, and 
> reporting per MediaStreamTrack allows the service provider to 
> correlate stats (perhaps using the MediaStream label). And in most 
> cases it is the same application in both ends, and the receiving end 
> could share the stats with the sending end (perhaps using the data 
> channel) if desired.
This won't work in the case where the app is written to communicate with 
something that is not itself (such as a media gateway). I don't see a 
reason to accept this limitation.

> If there are different apps used, they could still agree on stats 
> exchange (just as they would have to agree on a bunch of other things 
> to get things working) if desired.
>
> Stefan
>
>>
>> Comments welcome!
>>
>>                       Harald
>>
>
>
>

Received on Thursday, 28 June 2012 09:54:00 UTC