Re: icecandidate event with no candidate

On 2013-04-26 06:27, Justin Uberti wrote:
>
>
>
> On Thu, Apr 25, 2013 at 1:23 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto: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.

Ok, I see.

But it's still questionable if the event that indicates that gathering 
is done should be called "icecandidate". From your description, it seems 
like we have two different types of events; one for each transport and 
another when gathering is completely done.

Ideally, we should use one event type (like "gatheringdone") and 
different targets for this. The event that reports status for the 
individual transports should be fired on some object that represents 
that transport, and the "completely done"-event fired on the 
PeerConnection. We currently don't have anything that represents a track 
being sent with a PeerConnection (transport object), but we might get 
one when we get back to the priority and bitrate discussions.

/Adam

Received on Monday, 29 April 2013 13:51:31 UTC