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

Steps to reproduce:

Visit https://appr.tc/ with the latest firefox release and the latest chrome release and try to have a audio video call.

https://github.com/webrtc/samples/issues/1202

Actual results:

audio only from firefox to chrome

Expected results:

audio and video in both directions.

(Not confirmed. Just moving to the right component.)
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1113861-firefox-69-beta-on-linux-bringing-better-performance?p=1114055#post1114055

FF 68 broke WebRTC

Hi,
we've managed to reproduce the reported behavior on release 68 version, receiving only windows side. I will mark the bug as new in order to have it verified by a developer.

Regards
David

Byron, any thoughts here?

I'm guessing the addIceCandidate error is just Chrome not liking the end-of-candidates signal from the latest spec. Media is flowing both ways though, and we're using bundle, so I doubt the addIceCandidate error has anything to do with one-way audio. I just tested with nightly and release on OS X, and I get audio and video both ways.

I can try testing on linux a little bit later.

Would have been better to add support for receiving, and wait for other browsers to support end-of-candidates-signal before implementing the the sending part. But looks like it will get fixed soon-ish;

https://bugs.chromium.org/p/chromium/issues/detail?id=978582

Nils, do we know what regressed this?

So when we implemented bug 1318167 we broke interop with Chrome. But this only affects the very last ICE message which effectively say "I have no more ICE candidates for you". So it should not affect the call establishing.

I was not able to repro lack of video. For me audio and video are both working in both directions. Which is what I would expect: this results in JS return errors on the Chrome side, but should not affect the call itself.

Thanks Nils, given that, probably not worth tracking for 68?

Besides the ICE candidate error we actually found a problem with sending black video in bug 1570673.