Status

()

P2
normal
Rank:
15
RESOLVED WORKSFORME
a year ago
6 months ago

People

(Reporter: edovio, Unassigned)

Tracking

57 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needinfo to reporter 2017-09-11])

Attachments

(2 attachments)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170908100218

Steps to reproduce:

1. Open Firefox
2. Go at the Link https://appear.in/mozita
3. Accept to share the Mic and Webcam
4. Accept to enter in the Room
5. entering in the Room the Page exit with error


Actual results:

The page doesn't work properly when the Browser use Mic and the Camera


Expected results:

Make a good Video Call usin https://appear.in
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
edovio, could you go to the url 'about:crashes' and see if you find this particular crash there? That link would be useful for us. Thanks.
Flags: needinfo?(edovio)
Whiteboard: [needinfo to reporter 2017-09-11]
Specifically, can you explain in more detail what you say here:

"5. entering in the Room the Page exit with error"
and
"The page doesn't work properly when the Browser use Mic and the Camera"

Thanks.
Rank: 15
Priority: -- → P1
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
(Reporter)

Comment 4

a year ago
All remain open and stable but doesn't work the Mic and the Webcam.
 The other Users in the Room cannot see the Webcam and Mic Streaming
Flags: needinfo?(edovio)
Created attachment 8908084 [details]
Screenshot_20170913_103746.png

Screenshot on devtools.
I can check on about:webrtc with a new test right now, in any case the developer edtion doesn't have issues.
In the dev tools now I am getting:
Impossible decode the resource https://d1x2efl61akomv.cloudfront.net/assets/leave-notification.ogg. Errore: Error Code: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004)
Details: RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > mozilla::VorbisDataDecoder::ProcessDecode(mozilla::MediaRawData*): vorbis_synthesis:-135
Impossible decode the resource https://d1x2efl61akomv.cloudfront.net/assets/enter-notification.ogg. Errore: Error Code: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004)
Details: RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > mozilla::VorbisDataDecoder::ProcessDecode(mozilla::MediaRawData*): vorbis_synthesis:-135
Created attachment 8908085 [details]
aboutWebrtc.html

about:webrtc output
So two things we see here (thanks fippo for bouncing your thoughts on this):

The remote SDP says `a=recvonly` for both audio and video. That suggests that the remote side didn't have functioning local camera/microphone capture. Can you confirm whether that was the case?

There are no ice candidates gathered. Could it be that you have an extension installed that limits webrtc to not leak local ip addresses? uBlock has a setting like that for instance. You can check this by searching for "media.peerconnection.ice.proxy_only" on about:config -- it's set to true if an extension has made such a setting.

Byron, can you comment on whether this is expected? Shouldn't TURN candidates still work in proxy-only mode?
Flags: needinfo?(mte90net)
Flags: needinfo?(docfaraday)
Uh sorry, yes I done a test on my same laptop so for the second browser there wasn't the camera and mic.
I will do a check asap with the phone so the log will be better.
I am using ublock origin and this maybe can explain the issue, I will do a check also for this :-)
Flags: needinfo?(mte90net)
Confirmed that this parameter as false resolve the issue.
It is the case to open a ticket to uBlock to add an alert when WebRTC is used about it
Was there a proxy configured on this browser? If there was, it might be some interop issue; mtransport's proxy implementation is _very_ rudimentary.
Flags: needinfo?(docfaraday)
No I don't use a proxy on my system, I think that is the same also for Edoardo.
(In reply to Andreas Pehrson [:pehrsons] from comment #8)
> So two things we see here (thanks fippo for bouncing your thoughts on this):
> 
> The remote SDP says `a=recvonly` for both audio and video. That suggests
> that the remote side didn't have functioning local camera/microphone
> capture. Can you confirm whether that was the case?
> 
> There are no ice candidates gathered. Could it be that you have an extension
> installed that limits webrtc to not leak local ip addresses? uBlock has a
> setting like that for instance. You can check this by searching for
> "media.peerconnection.ice.proxy_only" on about:config -- it's set to true if
> an extension has made such a setting.
> 
> Byron, can you comment on whether this is expected? Shouldn't TURN
> candidates still work in proxy-only mode?

No proxy was configured, so no I would not expect this to work.
Thanks Byron.

The issue here is that uBlock origin has an option called "Prevent WebRTC from leaking local IP addresses", but really it sets the webrtc IPHandlingPolicy "disable_non_proxied_udp" which blocks all non-proxied data.

Having a proxy is rare so for most people this breaks WebRTC completely. uBlock origin is also doing more than they claim, in that they also prevent leaking of your public IP address.

Setting the IPHandlingPolicy to "default_public_interface_only" would prevent leaking local addresses (host candidates) but still allow WebRTC to work for services providing STUN and/or TURN servers (which can leak your public address).

I'll file an issue with uBlock.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
Duplicate of this bug: 1449531

Comment 17

6 months ago
I am sure there are more users scratching their head. Thanks for chiming in on the uBlock Origin bug and filing the Chrome bug to resolve this properly.
You need to log in before you can comment on or make changes to this bug.