- From: Alex Gouaillard <alex.gouaillard@temasys.com.sg>
- Date: Tue, 13 May 2014 16:18:14 +0800
- To: Justin Uberti <juberti@google.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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