Firefox ICE failed, Chrome OK (data channels)

[Jérôme Bajou]

Hello,

I adapted the demo videoRoom to my needs (only one publisher (video + audio), any other user is consuming the feed, data channel is enabled both ways). It works like a charm with Chrome, but I'm having troubles to make it work with Firefox 51 (64 bits).

The only difference I can see is the following error, which I can see only in firefox console (Chrome si doing just fine):

ICE failed, see about:webrtc for more details

It happens the first time I try to use data channel to send a chat message. To be more precise, let's call user A the user sending its video, and user B the user consuming.

A (Firefox) can send chat message to B (Firefox)

B (Firefox) CANNOT send chat message to B (Firefox)

A (Chrome) can send chat message to B (Firefox)

B (Firefox) can send chat message to B (Chrome)

Video/audio is working no with all test configurations.

My setup:

I have a Webserver hosted on my dev machine (locally) speaking with a server hosting janus (Janus is behind apache, which is used to forward ports from 80 to whatever janus is using to avoid firewall issues)

Firefox ICE debugging:

http://pastebin.com/uU7cuxm4

I don't really know where to look to make it work with Firefox, and my ICE knowledge is definitely not good enough to get out of this by myself.

Any help would be much appreciated

Thanks a lot in advance,

Jerome

[Mirko Brankovic]

I think the problem might be the way you handle candidates in B (listener) user.

The fact that first scenario works (where ff is sending offer and then receiving answer) and doesn't work on scenario two (where user receives offer abd then prepare answer), that tells me that it might be a problem with receiving offer.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jérôme Bajou]

Hello Mirko,

thanks for quick feedback.

Here is the createOffer:

if (dataOnly !== undefined && dataOnly !== null) {
     var media = {
     audioRecv: true,
     videoRecv: true,
     audioSend: false,
     videoSend: false,
     data: true
     };
     } else {
     var media = {
     audioRecv: false,
     videoRecv: false,
     audioSend: useAudio,
     videoSend: true,
     data: true
     };
     }
     
     this.pluginHandle.createOffer(
     {
     media: media,
     success: function (jsep) {
     // Got publisher, let's configure the feed
     var configure = {'request': 'configure', 'audio': useAudio, 'video': true};
     self.pluginHandle.send({'message': configure, 'jsep': jsep});
     
     // Update button
     $('#publish-btn').data('publishing', true);
     },
     error: function (error) {
     console.log('WebRTC error');
     console.log(error);
     if (useAudio) {
     // try again with no audio
     } else {
     self._error(error);
     }
     }
     }
     );

And here is the createAnswer:

     this.janus.attach(
     {
     plugin: 'janus.plugin.videoroom',
     success: function (pluginHandle) {
     remoteFeed = pluginHandle;
     console.log('Plugin attached for subscriber');
 var listen = { "request": "join", "room": self.options.room_id, "ptype": "listener", "feed": id };
 remoteFeed.send({"message": listen});
     },
     error: this._error,
     onmessage: function (msg, jsep) {
     var event = msg["videoroom"];
 if(event != undefined && event != null) {
 if (event === 'attached') {
 // Display the feed
 remoteFeed.rfindex = self.feeds.length + 1;
 remoteFeed.rfid = msg['id'];
 remoteFeed.rfdisplay = msg['display'];
 
 self.feeds[self.feeds.length + 1] = remoteFeed;
 
 console.log("Successfully attached to feed " + remoteFeed.rfid + " (" + remoteFeed.rfdisplay + ") in room " + msg["room"]);
 } else if (event === 'slow_link') {
 if ($('.slow-link').is('hidden'))
 $('.slow-link').removeClass('hidden').delay(2000).addClass('hidden');
 }
 }
 if(jsep !== undefined && jsep !== null) {
 remoteFeed.createAnswer(
 {
 jsep: jsep,
 media: {audioSend: false, videoSend: false, data: true},
 success: function (jsep) {
 var body = {'request': 'start', 'room': self.options.room_id};
 remoteFeed.send({'message': body, 'jsep': jsep});
 },
 error: function (error) {
 self._error(JSON.stringify(error));
 },
 }
 );
 }
 
     },

Am I doing something wrong ?

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

[Lorenzo Miniero]

Please don't paste these huge chunks of text inline. As explained in the guidelines, use services like pastebin or gist like that.

Check the causes for the failure using the Admin API.

L.

[Jérôme Bajou]

Yeah, well, it didn't look huge to me. I'll do better next time.

So I had a look at the Admin API, and the only difference I could spot is the selected-pair item. It is set to "2 <-> 1" when the listener can send data, "1 <-> 1" otherwise.

Could you give me more information about what it means, and how I could get a constant behaviour between Chrome and Firefox ? I don't really get how the same code can produce such a different result.

Here are the handle info:

First attempt:

Emitter, firefox: http://pastebin.com/T10HUerP

Receiver, firefox: http://pastebin.com/ztPL8m9j

Second attempt:

Emitter, CHROME: http://pastebin.com/hbwVk4bH

Receiver, firefox: http://pastebin.com/1QQP2XiY

Thanks in advance,

Jerome

[Lorenzo Miniero]

Il giorno venerdì 24 marzo 2017 16:00:53 UTC+1, Jérôme Bajou ha scritto:

Yeah, well, it didn't look huge to me. I'll do better next time.

If I scroll 3-4 times and I still don't see the end of it, it's huge :-P

Anything that fills more than a screen makes it unreadable to me.

 

So I had a look at the Admin API, and the only difference I could spot is the selected-pair item. It is set to "2 <-> 1" when the listener can send data, "1 <-> 1" otherwise.

Those numbers refer to the candidates Janus and the browser have negotiated. One doesn't mean the other is wrong. You may want to check if the same pair is what the browser is using as well (chrome://webrtc-internals), just in case they ended up using a different one for some reason.

 

Could you give me more information about what it means, and how I could get a constant behaviour between Chrome and Firefox ? I don't really get how the same code can produce such a different result.

Here are the handle info:

First attempt:

Emitter, firefox: http://pastebin.com/T10HUerP

Receiver, firefox: http://pastebin.com/ztPL8m9j

Second attempt:

Emitter, CHROME: http://pastebin.com/hbwVk4bH

Receiver, firefox: http://pastebin.com/1QQP2XiY

Why two different host addresses? Is one private and one public? Is only one meant to be used? Try explicitly disabling one of the two in janus.cfg for ICE so that libnice only uses the one you want to be used:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.cfg.sample.in#L153

L.

[Jérôme Bajou]

On Friday, March 24, 2017 at 5:31:01 PM UTC+2, Lorenzo Miniero wrote:

Il giorno venerdì 24 marzo 2017 16:00:53 UTC+1, Jérôme Bajou ha scritto:

Yeah, well, it didn't look huge to me. I'll do better next time.

If I scroll 3-4 times and I still don't see the end of it, it's huge :-P

Anything that fills more than a screen makes it unreadable to me.

Gotcha, depending on your resolution, it might look massive. 

 

So I had a look at the Admin API, and the only difference I could spot is the selected-pair item. It is set to "2 <-> 1" when the listener can send data, "1 <-> 1" otherwise.

Those numbers refer to the candidates Janus and the browser have negotiated. One doesn't mean the other is wrong. You may want to check if the same pair is what the browser is using as well (chrome://webrtc-internals), just in case they ended up using a different one for some reason.

I fail to see any refrence to selected-pair in the webRTC tab of firefox...

 

Could you give me more information about what it means, and how I could get a constant behaviour between Chrome and Firefox ? I don't really get how the same code can produce such a different result.

Here are the handle info:

First attempt:

Emitter, firefox: http://pastebin.com/T10HUerP

Receiver, firefox: http://pastebin.com/ztPL8m9j

Second attempt:

Emitter, CHROME: http://pastebin.com/hbwVk4bH

Receiver, firefox: http://pastebin.com/1QQP2XiY

Why two different host addresses? Is one private and one public? Is only one meant to be used? Try explicitly disabling one of the two in janus.cfg for ICE so that libnice only uses the one you want to be used:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.cfg.sample.in#L153

The server has two public ips (failover), I disabled one, no much luck. I'm starting to think about an iptable issue. What port range should be opened for janus to work properly (UDP)? 

Here is a small snippet from the logs that makes me think I should open some ports:

Mar 24 16:46:26 ns1 kernel: iptables_INPUT_denied: IN=eth0 OUT= MAC=00:25:90:72:11:b4:10:bd:18:e4:50:40:08:00 SRC=94.66.124.93 DST=188.165.255.53 LEN=120 TOS=0x00 PREC=0x00 TTL=54 ID=59622 PROTO=UDP SPT=65312 DPT=38292 LEN=100

Mar 24 16:46:28 ns1 kernel: iptables_INPUT_denied: IN=eth0 OUT= MAC=00:25:90:72:11:b4:ec:30:91:e0:df:c0:08:00 SRC=94.66.124.93 DST=188.165.255.53 LEN=120 TOS=0x00 PREC=0x00 TTL=54 ID=2317 PROTO=UDP SPT=56957 DPT=42257 LEN=100

Thanks for your help, I think we're getting there...

[Lorenzo Miniero]

Il giorno venerdì 24 marzo 2017 16:51:24 UTC+1, Jérôme Bajou ha scritto:

On Friday, March 24, 2017 at 5:31:01 PM UTC+2, Lorenzo Miniero wrote:

Il giorno venerdì 24 marzo 2017 16:00:53 UTC+1, Jérôme Bajou ha scritto:

Yeah, well, it didn't look huge to me. I'll do better next time.

If I scroll 3-4 times and I still don't see the end of it, it's huge :-P

Anything that fills more than a screen makes it unreadable to me.

Gotcha, depending on your resolution, it might look massive. 

 

So I had a look at the Admin API, and the only difference I could spot is the selected-pair item. It is set to "2 <-> 1" when the listener can send data, "1 <-> 1" otherwise.

Those numbers refer to the candidates Janus and the browser have negotiated. One doesn't mean the other is wrong. You may want to check if the same pair is what the browser is using as well (chrome://webrtc-internals), just in case they ended up using a different one for some reason.

I fail to see any refrence to selected-pair in the webRTC tab of firefox...

Firefox has a nice matrix that shows nominated and selected candidates, it should be on top of each PeerConnection section.

 

 

Could you give me more information about what it means, and how I could get a constant behaviour between Chrome and Firefox ? I don't really get how the same code can produce such a different result.

Here are the handle info:

First attempt:

Emitter, firefox: http://pastebin.com/T10HUerP

Receiver, firefox: http://pastebin.com/ztPL8m9j

Second attempt:

Emitter, CHROME: http://pastebin.com/hbwVk4bH

Receiver, firefox: http://pastebin.com/1QQP2XiY

Why two different host addresses? Is one private and one public? Is only one meant to be used? Try explicitly disabling one of the two in janus.cfg for ICE so that libnice only uses the one you want to be used:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.cfg.sample.in#L153

The server has two public ips (failover), I disabled one, no much luck. I'm starting to think about an iptable issue. What port range should be opened for janus to work properly (UDP)? 

By default libnice will pick random ports to use, no constraint. If you need a range, configure it in janus.cfg (rtp_port_range) so that it matches your rules (or bend the rules to make them fit the range you'll specify there). Of course, the smaller the range, the less peerconnections you'll be able to serve at the same time.

L.

[Jérôme Bajou]

Hello,

Sorry for the late feedback.

I opened ports 16384 to 32767 UDP, configured rtp_port_range accordingly, and... no luck. I can see in netstat that the ports in the range are used (which is good), but when Firefox is emitter, Chrome cannot send data through the datachannel.

I really don't get it...

[Ju Ju]

Do you have the last version of Firefox ?

Are you using M$ ?

Yesterday the peerconnection cannot establish (regarding the pcap the issue was with DTLS establishment) with M$ + Firefox (no pb under MacOS or Linux) until I download and re install the last version

J- 

[Lorenzo Miniero]

You should check the Admin API to see why it fails:

http://www.meetecho.com/blog/understanding-the-janus-admin-api/

L.