Open Bug 831926 Opened 11 years ago Updated 1 year ago

can't create a peer connection on without network connection

Categories

(Core :: WebRTC: Networking, defect)

Product:
Core
Component:
WebRTC: Networking
Version:
21 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Blocking Flags:
backlog parking-lot

People

(Reporter: akligman, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [games:p?]) 

I can't create a peer connection between two tabs via loopback interface when my network connection is disabled. The following error is raised:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [IPeerConnection.initialize] @ resource://gre/components/PeerConnection.js:278
Whiteboard: [games:p?]
Oh my gosh. That's what I have initially filed as bug 824919 but wasn't able to reproduce later. Not sure which combination of network resources I have had initially working.
From the bug you linked:

> This is an intentional design feature. The chance of loopback addresses working
> in any operational scenario is vanishing and they just clutter up the ICE candidate
> list. Moreover, as a general matter, we don't intend for PCs to work in offline mode.

Is this still true going forward? It does not evoke a positive emotional state.
What does the spec say or how does Chrome behave in offline mode?
The spec doesn't say.
Right now we purposely disable PeerConnections in offline mode because they depend on STUN servers which aren't available offline.
Whiteboard: [games:p?] → [games:p?][webrtc][blocking-webrtc-]
Whiteboard: [games:p?][webrtc][blocking-webrtc-] → [games:p2][webrtc][blocking-webrtc-]
Blocks: gecko-games
Is there an actual need for this?  We explicitly disabled it since there's no way they can work.  What's the usecase?
backlog: --- → parking-lot
Flags: needinfo?(mmucci)
Whiteboard: [games:p2][webrtc][blocking-webrtc-] → [games:p2]
(In reply to Randell Jesup [:jesup] from comment #6)
> Is there an actual need for this?  We explicitly disabled it since there's
> no way they can work.  What's the usecase?

Hello Randell, I'm not the person to contact for this bug as I'm not working on game related features.
Flags: needinfo?(mmucci)
Jesup: Note that there is now an about:config setting to let you make connections purely on localhost.
(In reply to Eric Rescorla (:ekr) from comment #8)
> Jesup: Note that there is now an about:config setting to let you make
> connections purely on localhost.

Right, though I presume that wasn't the intent of this bug originally.

NI to mbest instead since ack's account is disabled; feel free to revector or decide we don't care about this anymore
Flags: needinfo?(mbest)
The primary uses case here was for testing and development if I remember correctly.  Let's get Luke's take on this one.
Flags: needinfo?(mbest) → needinfo?(hkirschner)
Also ping Digitardal for insight into the utility.
Flags: needinfo?(luke)
I'm not aware of any current developer complaints about this, so I can't contribute much wrt priority.
Flags: needinfo?(luke)
I also haven't heard of use cases for this, but it would be great to enable. I can definitely see this use case when testing (develop WebRTC apps while being offline) or for tooling (writing performance dashboard that connects to an app/tab using WebRTC as channel).
Flags: needinfo?(hkirschner)
Should not be hard to add a check for media.peerconnection.ice.loopback user pref and if it is on skip the the safety check here https://dxr.mozilla.org/mozilla-central/source/dom/media/PeerConnection.js#404 if there is interest in doing that.
(In reply to Randell Jesup [:jesup] from comment #6)
> Is there an actual need for this?  We explicitly disabled it since there's
> no way they can work.  What's the usecase?

(In reply to Harald Kirschner :digitarald from comment #13)
> I also haven't heard of use cases for this, 

Here's mine:
I'm running cotorn locally for STUN/ICE: https://github.com/coturn/coturn.
I'm developing a PC for another language/runtime (Node.js, Python, Ruby, etc).
I want to connect a PC in a browser to a PC outside of the browser running locally.

It may be the case that the SDP token generated by cotorn does not reflect the local address.

(In reply to Randell Jesup [:jesup] from comment #5)
> Right now we purposely disable PeerConnections in offline mode because they
> depend on STUN servers which aren't available offline.

What if I'm running coturn locally?
To be more explicit about use case:

WebRTC Peer Connections are awesome. Thanks to SCTP, they provide fine grain control over reliability and ordered delivery.

Developers want to connect browser peers to Non-browser peers over WebRTC Peer Connections.

Today, it's possible to connect browser to browser peers, but quite difficult to connect a browser to a non browser peer over WebRTC Peer Connection.

Alan was asking, because he was/is working on it: https://github.com/js-platform/node-webrtc.  I'm also looking to do this.

The network requirement is an ARTIFICIAL limitation that makes automated testing difficult, since a STUN/ICE server can be stood up locally.
Whiteboard: [games:p2] → [games:p?]
Nor chrome neither firefox cannot resolve peerconnection without internet connection.
For test and develop purposes.
Every time enable modem to notebook is suck stuff.
Try to set media.peerconnection.ice.loopback in about:config to true, it should enable usage of the loopback interface on Linux or Mac.
On one hand I still don't see what you are accomplishing with a PeerConnection if the network is down. Maybe with the little exception of developers wanting to work on something which does not require a working ICE connection.

But then I also don't see the harm caused by letting people create PeerConnections in offline mode, and simply let ICE layer time out.

:bwc what do you think about lifting this ancient limitation?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #3)

What does the spec say or how does Chrome behave in offline mode?

According to Dean Shandler on Stack Overflow, in Chrome it works in offline mode:

So, after spending too many hours trying to solve this I found that in Chrome this works offline just fine. So I’ll just stick to that –
Dean Shandler
Jan 6 at 9:55

Source: https://stackoverflow.com/questions/70597885/how-can-i-use-webrtc-offline#comment124812304_70600805

They needed a low latency stream for a robotics project that may not make use of an active internet connection.

Currently trying to spoof a network connection in Linux to fool Firefox so I can develop & test my code in remote locations.

Severity: minor → S4

On one hand I still don't see what you are accomplishing with a PeerConnection if the network is down.

Testing.

Developing solutions for arbitrary restrictions or omissions in browsers.

WebRTC is useful for communicating between different browsing contexts in the same browser, between different browsers on the same machine, and between browsers and local applications.

(In reply to guest271314 from comment #22)

On one hand I still don't see what you are accomplishing with a PeerConnection if the network is down.

Testing.

Developing solutions for arbitrary restrictions or omissions in browsers.

WebRTC is useful for communicating between different browsing contexts in the same browser, between different browsers on the same machine, and between browsers and local applications.

Is media.peerconnection.ice.loopback not sufficient to make this work for you?

Some context. I am actually testing on Chromium 111. That is how I found this bug. There is a requirement at large to transfer an ArrayBuffer from an MV3 ServiceWorker to arbitrary Web pages https://github.com/GoogleChrome/chrome-extensions-samples/pull/782. I achieved that using the ServiceWorker as a signaling server for an offscreen document and arbitrary Web page https://github.com/guest271314/offscreen-webrtc. I am not sure if Chrome provides a means to set ICE loopback, for the case of transferring data from Chrome to an open Firefox instance - when offline https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c.

When I disable networking no offer is created.

I can hardcode the necessary values. Just need guidance of how to do that.

When you say "no offer is created", are you talking about Firefox or Chrome?

Chromium 111. Using this https://stackoverflow.com/a/54985729. Then checking chrome://webrtc-internals.

https://github.com/pion/offline-browser-communication appears to hardcode the necessary data.

There has to be, or should be a way, a way in WebRTC land to establish a data channel connection on the same machine when networking is disabled, for cases such as I described above.

I asked on discuss-webrtc over here https://groups.google.com/g/discuss-webrtc/c/Z6Uam24dQoo.

(In reply to Byron Campen [:bwc] from comment #25)

When you say "no offer is created", are you talking about Firefox or Chrome?

Evidently Chrome does have this flag --allow-loopback-in-peer-connection which didn't change anything offline.

This code https://stackoverflow.com/a/54985729 with media.peerconnection.ice.loopback set to true doesn't work on Firefox Nightly 110.0a1 (2022-12-18) (64-bit) either.

At console on file: protocol using above-linked code

WebRTC: RTCSessionDescription's members are readonly! Writing to them is deprecated and will break soon! dc-offer.html:51
WebRTC: ICE failed, add a STUN server and see about:webrtc for more details

From about:webrtc

PR_Connect failed: -5980

PR_Connect failed: -5980

ICE(PC:{...} ... (id=... url=file:///home/user/dc-answer.html)): failed to find default addresses

PR_Connect failed: -5980

PR_Connect failed: -5980

ICE(PC:{...} 1671597235911775 (id=... url=file:///home/user/dc-answer.html)): failed to find default addresses

PR_Connect failed: -5980

PR_Connect failed: -5980
...
media.peerconnection.ice.loopback: true

(In reply to Byron Campen [:bwc] from comment #23)

(In reply to guest271314 from comment #22)

On one hand I still don't see what you are accomplishing with a PeerConnection if the network is down.

Testing.

Developing solutions for arbitrary restrictions or omissions in browsers.

WebRTC is useful for communicating between different browsing contexts in the same browser, between different browsers on the same machine, and between browsers and local applications.

Is > Is media.peerconnection.ice.loopback not sufficient to make this work for you? not sufficient to make this work for you?

I tried again on Nightly 110 with media.peerconnection.ice.loopback set to true and ICE servers passed to RTCPeerConnection anyway based on the previous errors thrown

const config = {
  iceServers: [{
    urls: "stun:stun.1.google.com:19302"
  }]
};
const pc = new RTCPeerConnection(config);

at console

Uncaught DOMException: Can't create RTCPeerConnections when the network is down

If you're getting that error, I don't think you even have a loopback interface. When I turn off interfaces other than loopback, I can create an RTCPeerConnection in the JS console just fine, at least on OS X. Maybe linux behaves differently?

(In reply to Byron Campen [:bwc] from comment #29)

If you're getting that error, I don't think you even have a loopback interface. When I turn off interfaces other than loopback, I can create an RTCPeerConnection in the JS console just fine, at least on OS X. Maybe linux behaves differently?

$ uname -a 
Linux ... 5.15.0-43-generic ... x86_64 x86_64 x86_64 GNU/Linux


$ ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
...

Creating a RTCPeerConnection is not the issue. Did you create a data channel pair using this code https://stackoverflow.com/a/54985729 when WiFi, or whatever Internet connection you have established was disabled?

I was referring to the "Uncaught DOMException: Can't create RTCPeerConnections when the network is down" error you mentioned in comment 28. I cannot replicate that.

If you are able to create a PC, then there's another hurdle. Datachannel-only means we are not allowed to use any local IP addresses except the one used to load the webpage (see https://datatracker.ietf.org/doc/html/rfc8828#name-modes-and-recommendations), and when loading from a file: URL, there is no such IP address. You might be able to get this to work if you served up a webpage on localhost.

I was referring to the "Uncaught DOMException: Can't create RTCPeerConnections when the network is down" error you mentioned in comment 28. I cannot replicate that.

I can. I can record the screen if you need visual confirmation.

Per this https://stackoverflow.com/a/52671844 it doesn't appear that WebRTC establishes a peer connection on the same machine when loopback is enabled and external networking is not enabled.

Some other relevant posts: https://stackoverflow.com/a/70600805, https://bugs.chromium.org/p/webrtc/issues/detail?id=11859, https://bugzilla.mozilla.org/show_bug.cgi?id=1659672.

If you are able to create a PC, then there's another hurdle. Datachannel-only means we are not allowed to use any local IP addresses except the one used to load the webpage (see https://datatracker.ietf.org/doc/html/rfc8828#name-modes-and-recommendations), and when loading from a file: URL, there is no such IP address. You might be able to get this to work if you served up a webpage on localhost.

It would be helpful to state that in a specification and MDN documentation.

In the field I expected WebRTC to work offline and on file: protocol. I have no reason to expect otherwsie per official specification and MDN documentation.

Well, it is stated in a specification, but it is an IETF specification instead of a w3c specification. I think something on MDN would be helpful though.

So, the MDN documentation does not cover usage very much, so it is hard to say where it would make sense to talk about this gotcha. MDN points to external sources for guidance on usage and examples. I wonder if we should go to the effort of writing our own...

Right on the WebRTC front page. Conspicuously. Right here at Interoperability https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API. I filed this on MDN https://github.com/mdn/content/issues/23134. For web-compat I would use the same language in the W3C specification and https://github.com/webrtc/samples.

I wonder if we should go to the effort of writing our own...

I am not a proponent of not disclosing limitations of a specification or API dues to the perhaps exotic or specialized use-cases from the field in specifications and documentations. Oh, well, only a few users might actually do this. Until some partner or stakeholder has a use case then pushes their ideas into paperwork and implementation that might just happen to be similar to the one a user brought up years ago.

Consider this https://github.com/GoogleChrome/developer.chrome.com/pull/3947#issuecomment-1274250421

I thank @guest271314 for his contribution, but I am still against this addition. I think a very small percentage of the readership will be aware of speechSynthesis, and so most of our readers will just be confused by this.

re me advising Google authors who are pushing getDisplayMedia() that their naming convention is simply untrue, because getDisplayMedia() and getUserMedia() on Chrome *do not capture system audio. At best the Tab is captured, I filed an issue https://github.com/GoogleChrome/developer.chrome.com/issues/3957 really for users in the field who happen to want to actually capture speakers on Chrome or Chromium

Now it just so happens there is a user who wants to capture speakers https://stackoverflow.com/questions/74825984/overconstrainederror-when-requesting-speakers-stream-via-getusermedia-in-chrome ("I've also tried to record the speaker output, but that failed too." https://github.com/GoogleChrome/chrome-extensions-samples/issues/627#issuecomment-1367212114), and was not privy to the multiple issues I filed urging specification authors and implementers to support capture of audio to speakers and headphones.

Worth the churn? If your goal is to be open and honest about what is really going on with your API, in every way, you must be the primary source for information, in all ways. As soon as you begin thinking the little people with their little use cases is too small for you you lose credibility as the source, for not just writing out what is possible and what is not.

Why should users in the field have to get information from other users in the field about the restrictions, limitations of Web API's? Until some "stakeholder" or "partner" all of a sudden has a project, then all hands on deck to satisfy corporate. The choice is yours. Impeccable documentation literally speaks for itslef. Up to you WebRTC folks. That's my 2 cents.

You need to log in before you can comment on or make changes to this bug.