- From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
- Date: Sat, 19 Oct 2013 07:35:02 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Thanx for response- comments inline. 19 okt 2013 kl. 04:37 skrev "Harald Alvestrand" <harald@alvestrand.no>: > On 10/18/2013 11:54 PM, Göran Eriksson AP wrote: >> Hi Harald, >> >> Great to see the updated proposal for stats parameters uploaded on the W3C WebRTC Wiki, http://www.w3.org/2011/04/webrtc/wiki/Stats- this makes it much easier to discuss it before it ends up in the spec. It would be nice to see some other outstanding stuff there as well in time for TPAC. >> >> Now, a few comments and questions (not a complete list, :-)): >> >> 1. Have You considered stats for RTCDataChannel? > > Considered, yes; written something, no. Ok, will bring this up in a separate mail thread. >> >> 2. RTCRTPStreamStats >> It is not obvious to me what "transportId" is about, especially since nothing like a "transport object" is in the API. > > The transport has to exist as a conceptual object, but it's not exposed by the rest of the API at the moment. > It's the ID of the RTCTransport stats object. > > I'm not sure about the name, but what I was thinking of was (in ICE terms) the "connection" that one negotiates candidate pairs for; RTP tends to call it a "session", pre-BUNDLE SDP tended to call it an M-line. I need to check the terminology draft again to see what the best name is this week. Yeah- picking the name of an object representing the transport not a trivial thing I think. Apart from the alternatives You mention Path or TransportPath has come to my mind, relating to Media Path in Your rtcweb overview document. The reason i think relating to ICE connection is not sufficient is that we may have differentiated treatment on a flow level, the flows on an ICE connection for instance being separated into flows using DSCP's, getting different behaviour. But as You say- there are several alternatives. > >> >> 3. RTCInboundRTPStreamStats >> Perhaps a comment about meaning of "jitter" and how it is measured/calculated (unless obvious from context in spec) would be helpful? > > Needs to reference the corresponding line in RFC 3550. >> >> 4. RTCMediaStreamTracks >> I note that frames received and decoded are included. In Media Source Extentions, there are possibilities to get stats on the video element about frames dropped, corrupted, displayed, etc (https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#htmlvideoelement-extensions)- I believe it would be good if we try to align with that API, at least when it comes to parameters.' > > Thanks for the pointer - I think alignment wold be most valuable. >> >> 5. RTCTransport >> I was looking for information for which DSCP class that was used for a track and thought it may be in this dictionary. Such information could become useful in debugging an application I expect. > > As soon as we've locked down what DSCP code points vary over, we should expose it as a stat. > At the moment, I think it's an attribute of either a MediaStreamTrack or an SSRC - the former if all simulcast/layers/repair flows etc have the same DSCP; the latter if it can vary across the layers. I saw in the IETF RMCAT list also someone mentiong an idea of the browser chaning the DSCP when web app running in the background (meaning the tab with the web app not in focus). Such things should also be exposed in the stats. But I suggest we just add some //comments about this in the wiki text and then wait for the DSCP issue settle a bit more. > , >> >> Many Regards >> Göran >
Received on Saturday, 19 October 2013 07:35:28 UTC