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

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.