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

I checked the spec and you're right, it's written explicitly.

On Fri, May 9, 2014 at 2:36 PM, Justin Uberti <juberti@google.com> wrote:
> 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.
>>>
>>>
>

Received on Tuesday, 13 May 2014 08:18:41 UTC