Re: get ice candidate in use in connected/completed state

On 06/20/2014 08:49 PM, Iskren Chernev wrote:
> 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.

Media transports are bound to RTP sessions. The BUNDLE drafts (and a lot
of JSEP, and several pieces of the -transport- draft) are talking about
how one assigns MediaStreamTracks to RTP sessions.

It's possible to assign each MediaStreamTrack to a separate RTP session,
all video tracks to one RTP session and all audio tracks to another, or
put them all on the same RTP session.

It might be a good idea to read up a little on the basic concepts here -
it helps in formulating more clearly what you want to know.
>
>> 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.
Sounds like a good place to start. If it turns out that a consistent set
of operations is important to a lot of people, we can think about making
other ways to access them - a year or so down the road.

-- 
Surveillance is pervasive. Go Dark.