Closed Bug 1566095 Opened 5 years ago Closed 1 year ago

Error processing ICE candidate

Categories

(Core :: WebRTC, defect, P2)

68 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: elatllat, Unassigned)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(1 file)

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.

Component: Untriaged → WebRTC
Keywords: regression
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

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

Attached image image (2).png
Status: UNCONFIRMED → NEW
Ever confirmed: true

Byron, any thoughts here?

Flags: needinfo?(docfaraday)
Priority: -- → P2

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?

Flags: needinfo?(drno)

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.

Flags: needinfo?(drno)
Regressed by: 1318167
Keywords: regression

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

Flags: needinfo?(docfaraday)

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

See Also: → 1570673
Keywords: regression
Has Regression Range: --- → yes
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: