User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Try to join meet.google.com from an eduroam connection.

Actual results:

The WebRTC connection fails with Firefox while it is working with Chrome.
The strange thing is that it seems to work with whereby.com with both.

Expected results:

I don't understand while it fails with Firefox.

Here is the Chrome log dump from the same connection.

I cannot reproduce this, but you have a lot of IP addresses. Does this happen reliably for you? Is Chrome not using the IP addresses starting with 172.?

I don't know I was not able to findout on chrome side.

Byron, are there more logs that would be helpful here?

I suppose a packet capture might shed some light on this.

Do you mean using wireshark for instance?

Here is the Firefox Wireshark capture

Here is the Chrome wireshark capture.

I don't (In reply to Rémy Hubscher [:natim] from comment #7)

Created attachment 9161626 [details]
firefox-capture.pcapng

Here is the Firefox Wireshark capture

I don't see any stun packets at all in this capture; what is in about:webrtc for this call?

It looks like this

I am wondering if it is because Firefox tries to connect the stun server in UDP rather than TLSv1.2 TCP.

I see candidate pairs being started, but there's no stun packets at all in that packet capture. Does this happen with a fresh profile? Is there some firewall software that might be interfering?

(In reply to Rémy Hubscher [:natim] from comment #11)

I am wondering if it is because Firefox tries to connect the stun server in UDP rather than TLSv1.2 TCP.

Is UDP blocked for you?

The network administrator told me so (UDP is blocked)

Ok, that's probably part of the problem. I see no sign in the logging that a TURN server has been configured at all; this deployment seems to be relying on ICE TCP to handle cases where UDP is blocked, but ICE TCP does not appear to be working. Looking into it.

Ah, the TCP candidates from meet are malformed:

ICE(PC:1594050578679667 (id=8589934604 url=https://meet.google.com/new?hs=195)): Error parsing attribute: candidate:2113930494 1 tcp 2113930494 108.177.15.127 19305 typ host tcptyp active generation 0

That needs to be tcptype

https://tools.ietf.org/html/rfc6544#section-4.5

😅 well found.

I checked today and I'm seeing tcptype, not tcptyp in the raw candidates.

Hello Dan,

I double checked today and I still have connections issues with Firefox while it works with Chrome.
Would you like to pair on the issue to help figure out how it could be fixed?

Hi Rémy,

I'm sorry to hear you're still having connectivity problems here. I double checked today, and it seems that this has regressed on meet.google.com, I'm seeing tcptyp and not tcptype again. Or possibly I misread things when I checked a few weeks ago.

I appreciate the offer to pair on this, but as far as I can tell, this is an issue with Meet, not Firefox.

Ok I will try to find someone from the meet team to have a look.

It seems to be fixed with Firefox 81.0

Actually not, it worked until someone entered the room 😕

One of my users reported the issue from bug 1665368 on Google Meet (the exact error message matches). Commenting here because that could be related.