1398228 - https://appear.in doesn't work

Status: RESOLVED WORKSFORME

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Edoardo Viola]

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

Comment 1

[Andreas Pehrson [:pehrsons]]

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.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 3

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 4

[Edoardo Viola]

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

Comment 5

[Daniele "Mte90" Scasciafratte]

Attachment: 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.

Comment 6

[Daniele "Mte90" Scasciafratte]

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

Comment 7

[Daniele "Mte90" Scasciafratte]

Attachment: aboutWebrtc.html

about:webrtc output

Comment 8

[Andreas Pehrson [:pehrsons]]

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?

Comment 9

[Daniele "Mte90" Scasciafratte]

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 :-)

Comment 10

[Daniele "Mte90" Scasciafratte]

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

Comment 11

[Byron Campen [:bwc]]

Was there a proxy configured on this browser? If there was, it might be some interop issue; mtransport's proxy implementation is _very_ rudimentary.

Comment 12

[Daniele "Mte90" Scasciafratte]

No I don't use a proxy on my system, I think that is the same also for Edoardo.

Comment 13

[Byron Campen [:bwc]]

(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.

Comment 14

[Andreas Pehrson [:pehrsons]]

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.

Comment 15

[Andreas Pehrson [:pehrsons]]

There was already an issue, see https://github.com/gorhill/uBlock/issues/3009#issuecomment-329798696

Comment 17

[steve]

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.