1409737 - WebRTC Inbound to Firefox client does not choose candidate IP for RTP

Status: RESOLVED INVALID

(Core :: WebRTC: Signaling, defect, P2)

Description

[Joshua Young]

Attachment: aboutWebrtc.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

Make a WebRTC call to Firefox. Firefox must be the called party to reveal issues. 


Actual results:

When Firefox is the caller, the call works fine. When Firefox is the callee, audio and video do not appear.

From Chrome, call to Firefox = no audio/video
FreeSwittch Log: https://pastebin.freeswitch.org/view/c90330a0

From Firefox , call to Chrome = good audio/video
Freeswitch Log: https://pastebin.freeswitch.org/view/c417759f


Expected results:

I expected to see audio/video when Firefox is is the callee.

Comment 1

[Joshua Young]

Attachment: Firefox_WebRTC_stats.png

Comment 2

[Joshua Young]

first filed a support request https://support.mozilla.org/en-US/questions/1180274 and support rep suggested filing a bug here.

Comment 3

[Alex Chronopoulos [:achronop]]

I confirm the bug due to the logs and because it's important not to happen.

Comment 4

[Joshua Young]

Is there any further information I can provide for this?
Perhaps some more tests I can do?
Thanks...

Comment 5

[Joshua Young]

I'm happy to assist with troubleshooting. We have customers who are having trouble receiving calls on Firefox.
Thanks...

Comment 6

[Joshua Young]

was hoping to hear anything about this issue...

Comment 7

[Joshua Young]

Just checking in for the week, hopefully i can been of assistance...

Comment 8

[Byron Campen [:bwc]]

Sorry this took so long. It just looks like we aren't getting responses to our STUN requests in the failure case... could you supply a packet capture taken on the machine running Firefox?

Comment 9

[Joshua Young]

Attachment: NO_VIDEO_CHROME_CALLING_FIREFOX.pcapng

This is a no video call when Chrome is Calling party and Firefox is called party.

Comment 10

[Joshua Young]

Attachment: NO_VIDEO_FIREFOX_CALLING_FIREFOX_CAPTURING_INCOMING_CALL.pcapng

This is a no video call when Firefox from another machine is calling party, and firefox on pcap machine is called party.

Comment 11

[Joshua Young]

Attachment: NO_VIDEO_FIREFOX_CALLING_FIREFOX_OUTGOING_CALL.pcapng

This is a no video call when Firefox on pcap machine is calling party, and Firefox on another machine is called party..

Comment 12

[Joshua Young]

Attachment: GOOD_VIDEO_FIREFOX_CALLING_CHROME.pcapng

This is a good video call when Firefox on pcap machines is calling party, and chrome on another machine is called party....

Comment 13

[Joshua Young]

These calls were all made in Local network, so no natting involved...

Basically topology is for calling both ways
Laptop A --> FreeSWITCH --> Laptop B
Laptop B --> FreeSWTICH --> Laptop A

Ok, so tried giving you a complete call scenarios between 4 ways:
Chrome --> Firefox
Firefox --> Chrome
Firefox A --> Firefox B
Firefox B --> Firefox A

I'm using Firefox Nightly...

Hope that helps, sorry if I over did it with too much info...
Just want to get you helpful details...

Comment 14

[Joshua Young]

NO_VIDEO_CHROME_CALLING_FIREFOX.pcapng would probably be the most helpful pcap you asked for... calling the other way works fine between them...

Comment 15

[Byron Campen [:bwc]]

So the callee is getting ICMP errors to its STUN checks, which are being sent to 65.15.69.32 (I'm guessing this is the exterior address). This sounds like the NAT is disallowing hairpinning (not uncommon). The callee is not given any host candidates from within the network (no remote candidates in the 192.168.x.x network), for some reason. So, the callee is unable to reach the caller at all. The only way this can work is if the caller manages to get a STUN check to the callee, so the callee can learn about the caller's 192.168.x.x address. This is what happens in the Chrome case.

Unfortunately, Firefox has a STUN packet filter that drops STUN packets from addresses it has sent nothing to (in effect, Firefox acts like there's a NAT in front of it). This was put in place to help "box in" a compromised content process, minimizing its ability to send/receive network traffic (ie; this was added as a security feature).

If you can figure out why caller's candidates aren't making it across, you should have your solution.

Comment 16

[Joshua Young]

I dont understand your solution... I've enabled ICMP, also Hairpin... Still no video when Firefox is the called party... But I dont see how ICMP or Hairpin are an issues, due to the FreeSWTICH server and Laptops are all on internal network...

Comment 17

[Joshua Young]

Like when I do firefox to firefox call... audio nor video work... is there a setting to just turn off that security feature you mentioned?

Comment 18

[Byron Campen [:bwc]]

(In reply to Joshua Young from comment #16)
> I dont understand your solution... I've enabled ICMP, also Hairpin... Still
> no video when Firefox is the called party... But I dont see how ICMP or
> Hairpin are an issues, due to the FreeSWTICH server and Laptops are all on
> internal network...

   They are on the internal network, but Firefox never got any internal-network candidates for them. Firefox only got candidates like 65.15.69.32, which aren't usable due to whatever network topology/NAT you're using. That's your core problem.