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

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

From: Justin Uberti <juberti@google.com>
Date: Thu, 8 May 2014 17:36:46 -0700
Message-ID: <CAOJ7v-0HaiPWjKQD0Xphu6ci+wr=+pdjwR=p5EO4mg34zDdGww@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, May 8, 2014 at 3:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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.
>
>
Agree, and is surprising. I don't see that behavior at
http://googlechrome.github.io/webrtc/samples/web/content/peerconnection-states/
.

Please file a bug.

>
>
Received on Friday, 9 May 2014 00:37:34 UTC

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