827932 - WebRTC PeerConnection issues

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Mamadou]

User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

Steps to reproduce:

Basic testing on Windows 8 and Vista using Nightly 20.0a1 to add support for Firefox on sipML5 project


Actual results:

1) The RTP profiles for audio and video medias are not correct. Firefox uses "RTP/SAVPF" instead of "UDP/TLS/RTP/SAVPF". 
2) Both "window.mozRTCSessionDescription" and "window.RTCSessionDescription" are defined but any attempt to create an SDP with "window.RTCSessionDescription" fails. 
3) The initial SDP created using PeerConnection::createOffer() or PeerConnection::createAnswer() contains all ICE candidates (not an issue of course) and I guess this is why "onicecandidate" callback is never called. The problem is that there is no way to known if ICE gathering is finished or not. When using XMPP this is not a problem as it's possible to send candidates alone but with SIP this is not allowed. 
4) Firefox fails to recover from ICE role conflict when it has lower priority. 
5) In response to the DTLSv1 hello message from my SIP gateway to Firefox, I receive an error (Level: Fatal, Description: Bad Certificate). I'm sure that certificates are correct, they are used for both HTTPS and WSS (off course not only why I say it's correct).

Comment 1

[Adam Roach [:abr]]

(In reply to Mamadou from comment #0)

You're probably better off filing a different bug for each issue you've encountered.

> 1) The RTP profiles for audio and video medias are not correct. Firefox uses
> "RTP/SAVPF" instead of "UDP/TLS/RTP/SAVPF". 
> 2) Both "window.mozRTCSessionDescription" and "window.RTCSessionDescription"
> are defined but any attempt to create an SDP with
> "window.RTCSessionDescription" fails.

I don't believe the current W3C spec allows direct creation of SDP by the JavaScript application. You need to use createOffer() and createAnswer() to generate these objects. I could be mistaken -- if you see something in a current W3C document that says you should be able to do this, please file a bug pointing to the section of the document that describes the behavior that we don't implement.

> 3) The initial SDP created using PeerConnection::createOffer() or
> PeerConnection::createAnswer() contains all ICE candidates (not an issue of
> course) and I guess this is why "onicecandidate" callback is never called.
> The problem is that there is no way to known if ICE gathering is finished or
> not. When using XMPP this is not a problem as it's possible to send
> candidates alone but with SIP this is not allowed. 

You are correct that Firefox does not yet implement trickle ice, so you won't ever get additional candidates for the local description. We do, however, handle receiving trickle ice from the remote end.

In terms of the issue you describe (about knowing when the ICE candidates are done): this is a known gap in the current specification; the "icechange" events are currently marked "TODO" in the most recent WebRTC specification. For the moment, you can assume you have all the candidates from Firefox as soon as you get your description back from calling createOffer() or createAnswer().

I'm not sure how Chrome currently handles informing the application that all candidates have been collected, but (as there is no standard in this space), it will be proprietary to Chrome for the moment. Hopefully this gets nailed down in the W3C fairly soon.

> 4) Firefox fails to recover from ICE role conflict when it has lower
> priority.

I'm not entirely sure what you mean here. Can you please file a separate bug with detailed steps describing how to replicate the failure you're seeing?

> 5) In response to the DTLSv1 hello message from my SIP gateway to Firefox, I
> receive an error (Level: Fatal, Description: Bad Certificate). I'm sure that
> certificates are correct, they are used for both HTTPS and WSS (off course
> not only why I say it's correct).

This is going to be impossible to replicate without more information. If you could capture additional information about the failure (e.g. a packet trace, debug logs, etc) and attach it to a new bug, it would give us something to work with.

Thanks for taking the time to let us know about these issues! I'm excited to see more people using our WebRTC interfaces.

Comment 2

[Adam Roach [:abr]]

(In reply to Adam Roach [:abr] from comment #1)

> I don't believe the current W3C spec allows direct creation of SDP by the
> JavaScript application.

Okay, I appear to be mistaken here -- there is an application-visible constructor defined. Please file a separate bug with instructions about how to replicate the problem you're seeing. Thanks!

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Marking as Invalid; please file individual items instead for any you believe are real issues or bugs - it's hard to act on "PeerConnection Issues" with 5 different reports of different types.  (I believe at least one has been filed as a separate bug already and gotten action.)  Thanks!

Comment 4

[daniel]

I've opened a more specific issue for the "UDP/TLS/RTP/SAVPF" support:

https://bugzilla.mozilla.org/show_bug.cgi?id=1058006