- From: Iskren Chernev <iskren@imo.im>
- Date: Fri, 20 Jun 2014 11:49:04 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jun 20, 2014 at 12:58 AM, Harald Alvestrand <harald@alvestrand.no> wrote: > On 06/20/2014 01:48 AM, Iskren Chernev wrote: >> >> @harald thank you for the link. I'm looking forward to it being >> implemented. >> >> I'm currently using the stats interface of google chrome >> (non-standard), but as Raju pointed out -- it would be much better if >> the connected/completed event can have the candidate it connected >> through. > > > In the case of multiple transports, it will be somewhat complex, though - > you can't indicate just one of the transports, and if you indicate all of > them, how do you know which one you're looking for? By multiple transports do you mean that, audio and video streams might be sent through separate candidates (transports?). Is this good in the real world or just a side effect of PeerConnection being generic. > If the data is already provided, it seems better in a first iteration to let > you answer these questions for yourself - by firing off a getStats call from > the onstatechange handler, and getting the data you want. I guess I'll end up doing exactly that.
Received on Friday, 20 June 2014 18:49:52 UTC