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

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.