W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Firefox automatically provides local ICE candidates (it does not fire onicecandidate)

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 8 May 2014 15:30:59 -0700
Message-ID: <CABcZeBOmX=F-OCpv0uqg_nKvtrhw8iNNocCU6w_oTtZ15Bp6Sg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
We'v


On Thu, May 8, 2014 at 3:02 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> Hi,
>
> When calling createOffer/Answer in Firefox, the success callback
> provides me with a SDP that already includes local ICE candidates, so
> there is no onicecandidate event for those candidates (but just for
> candidates discovered via STUN).
>

Actually, it's more complicated. Firefox will return whatever candidates
are available at the time you call CreateOffer/CreateAnswer. After
discussion at IETF we agreed that it would be better to have all
candidates trickle, so we're planning to change this.


Is this "valid" as per spec?
>

That's a more complicated philosophical question, since the specs are
just drafts and this was kind of a point of vagueness/disagreement.

As a practical matter, FF will do this for quite some time
(and would continue to do so even if we changed the code today) so
you have to live with it for a while.


BTW: In Chrome the oniceconnectionstatechange fires 3 times per
> PeerConnection with this data:
>
>      iceConnectionState: "completed"
>      iceGatheringState: "complete"
>
> This is, there is no "new", "checking" or "connected" values for
> iceConnectionState.
>
>
> Again: how "valid" is this as per spec?
>

This sounds wrong.

-Ekr


>
> Thanks a lot.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
>
Received on Thursday, 8 May 2014 22:32:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC