Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Reflection Comments from a Recent Experience of Building Three End to End WebRTC Web Applications
49 views
Skip to first unread message
Jason Smith
May 20, 2013, 4:09:32 PM5/20/13
to dev-...@lists.mozilla.org
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?
* Chrome has already decided to unprefix RTCIceCandidate and
RTCSessionDescription. Why hasn't Firefox done so?
* 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?
* 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?
--
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
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?
* Chrome has already decided to unprefix RTCIceCandidate and
RTCSessionDescription. Why hasn't Firefox done so?
* 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?
* 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?
--
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
Eric Rescorla
May 20, 2013, 7:29:33 PM5/20/13
to Jason Smith, dev-...@lists.mozilla.org
On Mon, May 20, 2013 at 1:09 PM, Jason Smith <jsm...@mozilla.com> 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
> 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?
>
are in the SDP at the moment of creation.
> * Chrome has already decided to unprefix RTCIceCandidate and
> RTCSessionDescription. Why hasn't Firefox done so?
>
(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?
>
- 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?
discussion
on the mailing list.
-Ekr
Jason Smith
May 21, 2013, 10:34:12 PM5/21/13
to Adam Roach, dev-...@lists.mozilla.org, Eric Rescorla
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=874724 about the issue.
On 5/20/2013 6:08 PM, Adam Roach wrote:
> "DCB has not been created" message should be impossible to trigger
> from content javascript, no matter what you're calling, no matter what
> parameters you're sending in. This is likely indicative of a more
> serious bug than just an inscrutable error message.
>
>
> --
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863
On 5/20/2013 6:08 PM, Adam Roach wrote:
> On 5/21/13 07:29, Eric Rescorla wrote:
>> > * 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.
>
> Please do file a bug on this, with a repro test if you have one. The
>> > * 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.
>
> "DCB has not been created" message should be impossible to trigger
> from content javascript, no matter what you're calling, no matter what
> parameters you're sending in. This is likely indicative of a more
> serious bug than just an inscrutable error message.
>
>
> --
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863
0 new messages