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

I don't think an event is supposed to be fired for "new". That is the
initial state.


On Thu, May 8, 2014 at 5:45 PM, Alex Gouaillard <
alex.gouaillard@temasys.com.sg> wrote:

> The state is set initially but the corresponding event is not fired for
> "new", and AFAIK never was. "Checking" was triggering an event.
> The demo is manually fetching the state first, hiding the fact that no
> event was ever fired.
>
> Sent from my iPhone
>
> On 9 May, 2014, at 8:36 AM, Justin Uberti <juberti@google.com> wrote:
>
>
>
>
> 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.
>
>>
>>