On Mon, May 20, 2013 at 1:09 PM, Jason Smith <[email protected]> wrote:
> Hi Everyone, > > In preparation for a presentation I was doing talking about How to Build > Your First WebRTC Application, I ended up going to through the full process > of building three different end to end WebRTC Web Applications. As a > result, I have some reflection comments, questions, etc below on the > experience I had while building these applications with the current state > of our implementation: > > * Chrome required establishing ICE between two remote peers, while > Firefox did not. Why is this the case? Do we ever fire anything but > a null candidate back from onicecandidate in Firefox? > Firefox also does ICE. It just doesn't do *trickle* ICE. The ICE candidates are in the SDP at the moment of creation. > * Chrome has already decided to unprefix RTCIceCandidate and > RTCSessionDescription. Why hasn't Firefox done so? > It's not at all clear that this is a good idea. These are top-level APIs (i.e., they are called correctly by the programmer.) So if you are going to prefix RTCPeerConnection, these seem like they should be prefixed as well. I appreciate that there are disagreements about whether we should prefix anything, but once you are going to, you should be consistent. * In the process of building an interoperable WebRTC application > between Chrome and Firefox, when I did not provide > DtlsStrpKeyAgreement to true as an optional constraint to Chrome, > Firefox would fail to establish the handshake by reporting an error > of "DCB has not been created" during the addIceCandidate function. > Why is this the case? > There seem to be several questions. - Why doesn't it work? Because the offer without DTLS is incompatible with Firefox, which requires DTLS. - Why is there a lame error message? File a bug. * addIceCandidate in the W3C spec only supports one argument, but > Firefox's implementation supports more than one argument. Why are we > doing something different here? We think the spec is wrong and is likely to change. See the extensive discussion on the mailing list. -Ekr _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
