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

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.

>
>