Ice candidate not being generated for VPN interface

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
2 years ago
4 months ago

People

(Reporter: balwant.bisht, Unassigned)

Tracking

51 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needinfo 2016/10/27 to reporter])

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161024172922

Steps to reproduce:

I am trying to establish webrtc call with MCU server on our VPN. But Firefox not generating ice candidate for my VPN interface due to which ice connection with MCU is failing.


Actual results:

Firefox fail to establish ice connection with MCU. Firefox 51 not generating ice candidate for my VPN interface, but the same is working fine in Firefox 50.


Expected results:

Firefox to generate ice candidate for my VPN interface and ice connection should establish.

Updated

2 years ago
Component: WebRTC → WebRTC: Networking
Do you have by any chance installed any of the extensions to not trickle private IP addresses or changed any user pref around that topic?
An easy way of double checking should be to try it with a fresh user profile on about:profiles.

Also of interest:
- what is the OS?
- do you have Multi-Process turned on (check for 'Multiprocess Windows' on about:support)?
Flags: needinfo?(balwant.bisht)
Whiteboard: [needinfo 2016/10/27 to reporter]

Comment 2

2 years ago
I suspect this is a result of the new IP protection code; unless camera/microphone access is granted, only the default route (not the VPN, probably) will be used.
(Reporter)

Comment 3

2 years ago
(In reply to Nils Ohlmeier [:drno] from comment #1)
> Do you have by any chance installed any of the extensions to not trickle
> private IP addresses or changed any user pref around that topic?
> An easy way of double checking should be to try it with a fresh user profile
> on about:profiles.
> 
> Also of interest:
> - what is the OS?
> - do you have Multi-Process turned on (check for 'Multiprocess Windows' on
> about:support)?

OS: Mac Os Sierra (10.12)
Multi-Process turned on: Yes enabled by default
(Reporter)

Comment 4

2 years ago
(In reply to Byron Campen [:bwc] from comment #2)
> I suspect this is a result of the new IP protection code; unless
> camera/microphone access is granted, only the default route (not the VPN,
> probably) will be used.

Byron Campen is correct. 

If I am joining with camera/microphone access then PeerConnection is getting established. But the problem is, we establish PeerConnection with MCU first and camera/microphone is only accessed when user press camera/microphone unmute button in UI. So this new IP protection change will break our use case.

Comment 5

2 years ago
(In reply to Balwant Bisht from comment #4)
> (In reply to Byron Campen [:bwc] from comment #2)
> > I suspect this is a result of the new IP protection code; unless
> > camera/microphone access is granted, only the default route (not the VPN,
> > probably) will be used.
> 
> Byron Campen is correct. 
> 
> If I am joining with camera/microphone access then PeerConnection is getting
> established. But the problem is, we establish PeerConnection with MCU first
> and camera/microphone is only accessed when user press camera/microphone
> unmute button in UI. So this new IP protection change will break our use
> case.

I can see that. But this is what is in the spec right now (https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-02). I think it is a little flawed, personally, but the workaround is simple.
Nothing actionable here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
(Reporter)

Updated

4 months ago
Flags: needinfo?(balwant.bisht)
You need to log in before you can comment on or make changes to this bug.