Re: icecandidate event with no candidate

I haven't yet found a scenario where that's really important. If you lose
connectivity on one transport but not another, it's theoretically possible
you could take different actions (i.e. losing audio vs video), but that
could ripple pretty far (e.g. need to createOffer to restart just a single
transport).

In short, my general feeling is that the existing oniceconnectionstate
callback is sufficient for the current API. If we do a lower-level API in
the future, we could expose these additional details.


On Wed, May 1, 2013 at 8:28 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

>  On 4/26/13 6:27 AM, Justin Uberti wrote:
>
>
>
>
> On Thu, Apr 25, 2013 at 1:23 AM, Adam Bergkvist <
> adam.bergkvist@ericsson.com> wrote:
>
>> On 2013-04-25 06:36, Justin Uberti wrote:
>>
>>> In the Lyon discussion, we specifically agreed to use
>>> onicecandidate(null) rather than invent a new callback for the
>>> icegatheringstate change, as it was felt that such a callback would be
>>> redundant, and would also not meet all the needs of the trickle-ice
>>> proposal.
>>>
>>
>>  Yes, that was our decision at the time. I'm just forwarding feedback
>> from developers who think it's a bit strange and unintuitive. Especially
>> with regards to the name of the event and how similar things work in other
>> APIs.
>>
>
>  Understood.
>
>
>>
>> How would a separate "gathering done"-event not meet all the needs of the
>> trickle-ice proposal?
>
>
>  Because it needs to know when each transport (m= line) is done
> gathering, not just when it's completely done. onicecandidate could be
> tweaked to do this by surfacing a Candidate object with the m= line info
> filled in, but no candidate.
>
> I guess you could just as well have a "gathering done" event per
> transport. You have obviously identified a need to know when gathering is
> done per transport. Do you think we should also expose the connection state
> per transport (and not only for the entire PeerConnection)?
>
> Stefan
>
>
>> /Adam
>>
>>
>>
>>
>
>