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 Friday, 9 May 2014 00:37:34 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC