4 ms·

Is this hosted anywhere? I created https://omen.tv/ https://omen.tv/ just last weekend. Similar in that it's powered by WebRTC, but it's designed for casting y

Is this hosted anywhere? I created https://omen.tv/ https://omen.tv/ just last weekend. Similar in that it's powered by WebRTC, but it's designed for casting your screen (e.g. Jackbox Games) to other people's TVs. My greatest annoyances with WebRTC were: 1. WebRTC requires a STUN server, and despite the spec initially supporting default ICE servers, it has since been pulled out into an extension because browser vendors don't want to provide servers[1]. There are free STUN servers (Google etc.) but... 2. Double NAT clients. STUN is inevitably going to discover double NAT clients. The only way to connect these clients is through a proxy. Specifically a TURN server. Unlike STUN servers, these are not light-weight, and I can totally understand why browser vendors don't offer them by default. So inevitably any WebRTC use still requires a self-hosted TURN server. 3. Inconsistent access to streams across browsers. In particular the getDisplayMedia[2] API provides poor availability of the audio stream. Courtesy of Apple doing Apple things, I don't believe it's even possible to implement this API on macOS as there's no audio loopback device. I worked around this for my use-case by installing BlackHole[3] (which is great software!) However, the loopback device appears as an input e.g. like a microphone, so isn't technically the display audio. For this all to be smooth I think all these pain points need to be addressed. Issue 1 and 2 require NAT to be kicked to the curb, come on IPv6! Issue 3, requires Apple to expose a loopback device and browsers to implement support. These aren't insurmountable issues, but they're unfortunately out of our hands as day-to-day devs. [1] https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/getDefaultIceServers https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConn... [2] https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... [3] https://github.com/ExistentialAudio/BlackHole https://github.com/ExistentialAudio/BlackHole

tonetheman 6y ago
For your points 1 and 2... you need those servers to be hosted away from your end points. ICE will not work otherwise and they are ultimately legit servers that someone has to work to keep running or pay for. The STUN one is easy really but the TURN servers need to be able to proxy traffic. Twillio provides STUN/TURN servers and they are fairly cheap. I am sure there are others.
esaym 6y ago
STUN servers? I thought ipv4 was dead by now...
- nurettin 6y ago
  I thought low hanging fruits have all been collected by now.
asiachick 6y ago
can some one tell me why I want NAT kicked to the curb? I like the idea that you get slightly less info from me behind nat. I have 14-15 devices but if I understand, from the outside my NAT they look like one device. I like that honestly though maybe I shouldn't. That it's harder to do peer to peer is partly the point.
iforgotpassword 6y ago
Ad 2) this is false, double Nat doesn't automatically mean you need a proxy. It still depends on Nat type, it just increases the chances that one of them is a "hard one", to speak in terms of recent post about this problem: https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105
- Benjamin_Dobell 6y ago
  I'm unaware of any NAT setup that allows double NAT'd clients to directly communicate with each other. Quite happy to learn different if you'll point me toward a specific NAT setup that'd allow this. Just off the top of my head, the only way I could see this working is if the NATs themselves aren't transparent, and offer an API to manually map address/port pairs.
  - saurik 6y ago
    I don't understand how double NAT would cause a problem: you send a UDP packet out to someone on the public Internet (maybe STUN) and it will punch two holes; assuming you don't have low quality symmetric NAT, packets sent to the outer NAT on the egress port will be translated to the egress port on the inner NAT which will translate back to the original port on the client. Why do you think this would fail?
  - iforgotpassword 6y ago
    Why would it not allow this? Read the article I linked, it explains why double Nat is not really different. A specific Nat setup would be my home connection, or pretty much anyone using the same ISP. It's CGN and then another Nat at home. Stun works fine with that.
    - deleted 6y ago
      [deleted]
  - mlyle 6y ago
    Friendly NATs map, for UDP, e.g. (source address, source port) to (one of our outside addresses, port). Anyone who sends packets back to that outside address gets packets to you. So, you bind 192.168.100.55:5555 and send a packet to a STUN server 1.2.3.4:3478. This creates a mapping between, 192.168.100.55:5555 and an outside port, we'll call it 81.82.83.84:12345. And the STUN server tells you back, in a reply, "you're 81.82.83.84:12345". Then your friend sends a packet from his private address to 81.82.83.84:12345. It reaches your NAT, and is translated to 192.168.100.55:5555 and you receive it. Replying to this packet lets you send packets to him.
sradman 6y ago
The client-side script.js [1] appears to have a hard coded list of well known STUN/TURN endpoints, some with credentials. The identity and access management is non-existent at this point of the project’s roadmap. A client needs the hostname of the Talk Node.js server along with a unique “room” name to connect, as far as I can tell after a quick glance of server.js [2]. [1] https://github.com/vasanthv/talk/blob/master/www/script.js https://github.com/vasanthv/talk/blob/master/www/script.js [2] https://github.com/vasanthv/talk/blob/master/server.js https://github.com/vasanthv/talk/blob/master/server.js
jitbit 6y ago
I was playing around to create something similar and these problems were EXACTLY what I bumped into. STUN is a must for discovery, TURN is a must if both people are behind NATs, Apple support is meh... So, to sum up, for a webRTC p2p app you need to: 1-3) The things you mentioned. 4) Code your own signaling server to transmit events like "call", "hung up", "room" tracking, etc.
- MayeulC 6y ago
  > TURN is a must if both people are behind NATs This is not what double NAT means. If both people are behind single NAT, STUN is enough. I think it is also enough if one person (or both) are behind more than one regular NAT, which is what double-nat usually means. Where STUN doesn't work is symmetric NAT [1], where different destination servers will receive a packet with different source ports, even if the original source port was the same. It also doesn't work in a few, lesser-used NAT types [2]. [1] https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT https://en.wikipedia.org/wiki/Network_address_translation#Sy... [2] https://en.wikipedia.org/wiki/STUN#Limitations https://en.wikipedia.org/wiki/STUN#Limitations
MayeulC 6y ago
Since most IPv6 routers I have seen have default firewall rules similar to NAT (allow outgoing, and incoming only if part of a valid session), STUN servers would probably still be required, wouldn't they?
- Benjamin_Dobell 6y ago
  Not to my knowledge. With IPv6 you know each other's public address, and can thus "hole punch" directly. The problem with NAT is you don't even know the IP address you're attempting to establish a connection to.
  - saurik 6y ago
    Yeah; and this is why IPv6 is a bit evil and CGNAT+PMP (not that any clients are smart enough to do PMP correctly, which is stupid; and sadly not enough Internet is behind true CGNAT) is epic: you lose nothing (due to the explicit port mapping control) and get what amounts to free anonymity (unlike IPv6, which tattoos an identifier on you as if that's a feature).
    - MayeulC 6y ago
      Well, what you say is true to some extent, but there are some privacy extensions... And I don't think you should rely on having an obfuscated/shared IP for anonymity. There are better tools for this, like Tor, I2P, Freenet, etc. IPv6 was designed back in the 90s, where we had much less concerns about tracking, privacy and anonymity. But IPv4 is even more ancient, and, make no mistake, CGNAT is not designed to make you more anonymous, so you could be fooled by a false sense of security. Maybe we need to sell IPv6 as a way to track users to boost its adoption? And develop those privacy-conscious networks on top of it? Regardless, IPv4 and NAT are not consumer-friendly when it comes to self-hosting and p2p, so as long as these are the norm, software silos will be at an advantage.
  - MayeulC 6y ago
    You are right, I forgot about this. Though, as always, you need to obtain your peer's IP trough a side channel (also the case without firewall), if your firewall isn't too picky about answering to blocked requests, and doesn't meddle with source ports, punching a hole should be quite straightforward (one side just has to co-ordinate with the other to pretend the firewall didn't block the first incoming packet, right?).
arendtio 6y ago
One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind. I think the biggest issue is that often you have to set up a STUN/TURN server in an extra environment. In the XMPP world, ejabberd has come to the point, where it brings most things you need today in a single package (XMPP, HTTPS, Lets-enrypt, STUN/TURN, ...). That way you add about 5 lines to a config file and get STUN and TURN with little effort. I like that simplicity and if you don't, you are still free to use an external STUN/TURN server.
- Benjamin_Dobell 6y ago
  > One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind. My apologies if it reads that way. They are indeed standardised web technologies used in a whole host of environments. For example, Valve run STUN servers for their (now deprecated, but very much still in use) Steam P2P APIs; which are backed by a custom UDP protocol.
jokowueu 6y ago
I've been trying to find something like omen tv forEVER !!!. Webrtc existed for a while now but no one bother making something like this
TedDoesntTalk 6y ago
I enjoyed sharing my entire full screen with omen.tv and watching infinity -- just like pointing a video camera at a mirror.
throw14082020 6y ago
Do you need STUN for all signalling methods? Like what if you choose carrier pigeons or manually typing in the SDP?
redindian75 6y ago
it is hosted here: http://talk.vasanthv.com http://talk.vasanthv.com

tonetheman 6y ago

For your points 1 and 2... you need those servers to be hosted away from your end points. ICE will not work otherwise and they are ultimately legit servers that someone has to work to keep running or pay for. The STUN one is easy really but the TURN servers need to be able to proxy traffic. Twillio provides STUN/TURN servers and they are fairly cheap. I am sure there are others.

esaym 6y ago

STUN servers? I thought ipv4 was dead by now...

nurettin 6y ago
I thought low hanging fruits have all been collected by now.

asiachick 6y ago

can some one tell me why I want NAT kicked to the curb? I like the idea that you get slightly less info from me behind nat. I have 14-15 devices but if I understand, from the outside my NAT they look like one device. I like that honestly though maybe I shouldn't. That it's harder to do peer to peer is partly the point.

iforgotpassword 6y ago

Ad 2) this is false, double Nat doesn't automatically mean you need a proxy. It still depends on Nat type, it just increases the chances that one of them is a "hard one", to speak in terms of recent post about this problem: https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105

Benjamin_Dobell 6y ago
I'm unaware of any NAT setup that allows double NAT'd clients to directly communicate with each other. Quite happy to learn different if you'll point me toward a specific NAT setup that'd allow this. Just off the top of my head, the only way I could see this working is if the NATs themselves aren't transparent, and offer an API to manually map address/port pairs.
- saurik 6y ago
  I don't understand how double NAT would cause a problem: you send a UDP packet out to someone on the public Internet (maybe STUN) and it will punch two holes; assuming you don't have low quality symmetric NAT, packets sent to the outer NAT on the egress port will be translated to the egress port on the inner NAT which will translate back to the original port on the client. Why do you think this would fail?
- iforgotpassword 6y ago
  Why would it not allow this? Read the article I linked, it explains why double Nat is not really different. A specific Nat setup would be my home connection, or pretty much anyone using the same ISP. It's CGN and then another Nat at home. Stun works fine with that.
  - deleted 6y ago
    [deleted]
- mlyle 6y ago
  Friendly NATs map, for UDP, e.g. (source address, source port) to (one of our outside addresses, port). Anyone who sends packets back to that outside address gets packets to you. So, you bind 192.168.100.55:5555 and send a packet to a STUN server 1.2.3.4:3478. This creates a mapping between, 192.168.100.55:5555 and an outside port, we'll call it 81.82.83.84:12345. And the STUN server tells you back, in a reply, "you're 81.82.83.84:12345". Then your friend sends a packet from his private address to 81.82.83.84:12345. It reaches your NAT, and is translated to 192.168.100.55:5555 and you receive it. Replying to this packet lets you send packets to him.

sradman 6y ago

The client-side script.js [1] appears to have a hard coded list of well known STUN/TURN endpoints, some with credentials. The identity and access management is non-existent at this point of the project’s roadmap. A client needs the hostname of the Talk Node.js server along with a unique “room” name to connect, as far as I can tell after a quick glance of server.js [2]. [1] https://github.com/vasanthv/talk/blob/master/www/script.js https://github.com/vasanthv/talk/blob/master/www/script.js [2] https://github.com/vasanthv/talk/blob/master/server.js https://github.com/vasanthv/talk/blob/master/server.js

jitbit 6y ago

I was playing around to create something similar and these problems were EXACTLY what I bumped into. STUN is a must for discovery, TURN is a must if both people are behind NATs, Apple support is meh... So, to sum up, for a webRTC p2p app you need to: 1-3) The things you mentioned. 4) Code your own signaling server to transmit events like "call", "hung up", "room" tracking, etc.

MayeulC 6y ago
> TURN is a must if both people are behind NATs This is not what double NAT means. If both people are behind single NAT, STUN is enough. I think it is also enough if one person (or both) are behind more than one regular NAT, which is what double-nat usually means. Where STUN doesn't work is symmetric NAT [1], where different destination servers will receive a packet with different source ports, even if the original source port was the same. It also doesn't work in a few, lesser-used NAT types [2]. [1] https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT https://en.wikipedia.org/wiki/Network_address_translation#Sy... [2] https://en.wikipedia.org/wiki/STUN#Limitations https://en.wikipedia.org/wiki/STUN#Limitations

MayeulC 6y ago

Since most IPv6 routers I have seen have default firewall rules similar to NAT (allow outgoing, and incoming only if part of a valid session), STUN servers would probably still be required, wouldn't they?

Benjamin_Dobell 6y ago
Not to my knowledge. With IPv6 you know each other's public address, and can thus "hole punch" directly. The problem with NAT is you don't even know the IP address you're attempting to establish a connection to.
- saurik 6y ago
  Yeah; and this is why IPv6 is a bit evil and CGNAT+PMP (not that any clients are smart enough to do PMP correctly, which is stupid; and sadly not enough Internet is behind true CGNAT) is epic: you lose nothing (due to the explicit port mapping control) and get what amounts to free anonymity (unlike IPv6, which tattoos an identifier on you as if that's a feature).
  - MayeulC 6y ago
    Well, what you say is true to some extent, but there are some privacy extensions... And I don't think you should rely on having an obfuscated/shared IP for anonymity. There are better tools for this, like Tor, I2P, Freenet, etc. IPv6 was designed back in the 90s, where we had much less concerns about tracking, privacy and anonymity. But IPv4 is even more ancient, and, make no mistake, CGNAT is not designed to make you more anonymous, so you could be fooled by a false sense of security. Maybe we need to sell IPv6 as a way to track users to boost its adoption? And develop those privacy-conscious networks on top of it? Regardless, IPv4 and NAT are not consumer-friendly when it comes to self-hosting and p2p, so as long as these are the norm, software silos will be at an advantage.
- MayeulC 6y ago
  You are right, I forgot about this. Though, as always, you need to obtain your peer's IP trough a side channel (also the case without firewall), if your firewall isn't too picky about answering to blocked requests, and doesn't meddle with source ports, punching a hole should be quite straightforward (one side just has to co-ordinate with the other to pretend the firewall didn't block the first incoming packet, right?).

arendtio 6y ago

One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind. I think the biggest issue is that often you have to set up a STUN/TURN server in an extra environment. In the XMPP world, ejabberd has come to the point, where it brings most things you need today in a single package (XMPP, HTTPS, Lets-enrypt, STUN/TURN, ...). That way you add about 5 lines to a config file and get STUN and TURN with little effort. I like that simplicity and if you don't, you are still free to use an external STUN/TURN server.

Benjamin_Dobell 6y ago
> One and two read as if STUN and TURN are specific technologies build for WebRTC, but as far as I know, those are just the standard technologies for handling P2P-scenarios with consumer level usability in mind. My apologies if it reads that way. They are indeed standardised web technologies used in a whole host of environments. For example, Valve run STUN servers for their (now deprecated, but very much still in use) Steam P2P APIs; which are backed by a custom UDP protocol.

jokowueu 6y ago

I've been trying to find something like omen tv forEVER !!!. Webrtc existed for a while now but no one bother making something like this

TedDoesntTalk 6y ago

I enjoyed sharing my entire full screen with omen.tv and watching infinity -- just like pointing a video camera at a mirror.

throw14082020 6y ago

Do you need STUN for all signalling methods? Like what if you choose carrier pigeons or manually typing in the SDP?

redindian75 6y ago

it is hosted here: http://talk.vasanthv.com http://talk.vasanthv.com