Re: Stats proposal, updated

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:
>>>> 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.
>
> I got no comment on th above part (which was the most important!). Any 
> views?

Yes, I ignored that, since specific stats aren't defined in the proposal 
yet.
I was kind of assuming that the local/remote IP address of the interface 
in use was available as a "statistic", which gives the same result (I 
think).

>
>>>
>>> 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.
>
> 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.

>
>>
>>> 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.
>
> That depends on what ways the media GW has a way to communicate with 
> the app.
>
> Anyway, I certainly has nothing against exposing stats to the sender 
> app as well, but I think we should do something about the API in that 
> case. I don't like the idea that "removeStream" would create empty 
> entries in the local/remoteStream arrays.
Then let's remove "removeStream" altogether, and have the streams 
remain, but in the Closed state.

>
>>
>>> 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 Friday, 20 July 2012 10:50:22 UTC