- From: Eric Rescorla <ekr@rtfm.com>
- Date: Thu, 8 May 2014 15:30:59 -0700
- To: Iñaki Baz Castillo <ibc@aliax.net>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CABcZeBOmX=F-OCpv0uqg_nKvtrhw8iNNocCU6w_oTtZ15Bp6Sg@mail.gmail.com>
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. -Ekr > > Thanks a lot. > > > -- > Iñaki Baz Castillo > <ibc@aliax.net> > >
Received on Thursday, 8 May 2014 22:32:07 UTC