4 ms·

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent widespread adoption.

geocar 13y ago
I'm not convinced. WebRTC is supported by huge corporations with massive resources. If they had decided to use IPv6 instead of SDP for addressing, I can't imagine there would be any difficulty in user adoption, and they could only improve service adoption.
- taf2 13y ago
  Don't most users of the internet not have IPv6 addresses. I know my FIOS and business Comcast lack IPv6 support... I can only imagine that means everyone in a very large radius around my hometown are in the same boat of zero IPv6... That said, I agree it would be nice if the browser vendors handled networks that block all traffic that is not over TCP port 80 and TCP port 443, but I'm certain that it's because WebRTC is non-trivial and we have it's usefulness goes beyond peer to peer...
  - geocar 13y ago
    WebRTC isn't just non-trivial: It's hard, and the hardest part is the fact that every service provider has to implement a complex network configuration that is difficult to test and exercise. Even tunnelling IPv6 would be preferable, but my point was about making browser vendors do "the hard work" instead of making service providers.
- AshleysBrain 13y ago
  SDP is a session description protocol, not an addressing protocol. WebRTC will be able to use IPv6 addressing in future, too, and supporting IPv4 where possible means it's practical to use now as well.
  - geocar 13y ago
    > SDP is a session description protocol, not an addressing protocol SDP is most certainly an addressing protocol. It's a very complicated one that uses many binary tokens including IPv4 addresses (or IPv6 adddresses) and port numbers, cookies, and keys. That some of the binary tokens used in the SDP addresses are discovered using ICE/STUN (sometimes) complicates service providers greatly.
vladimirralev 13y ago
TURN/ICE is supposed to work just fine on symmetric NATs. Chrome even supports single-socket TCP relays, which can't be broken easily by any sane firewall. I personally have a few boxes testing it with only TCP 80 port allowed and it still finds a way to connect. A few tricks on the TURN side have to be employed but it's pretty robust. Whatever issue the OP has to be a bug or configuration issue. There are known problems and I still see a lot of freezes, protocol or hardware compatibility issues, CPU overload and so on, but straight Chrome to Chrome connections seem robust.
- alexfreska 13y ago
  Not all people have Chrome or latest version of Chrome and I think a fairly recent version is required to relay over TCP.

geocar 13y ago

I'm not convinced. WebRTC is supported by huge corporations with massive resources. If they had decided to use IPv6 instead of SDP for addressing, I can't imagine there would be any difficulty in user adoption, and they could only improve service adoption.

taf2 13y ago
Don't most users of the internet not have IPv6 addresses. I know my FIOS and business Comcast lack IPv6 support... I can only imagine that means everyone in a very large radius around my hometown are in the same boat of zero IPv6... That said, I agree it would be nice if the browser vendors handled networks that block all traffic that is not over TCP port 80 and TCP port 443, but I'm certain that it's because WebRTC is non-trivial and we have it's usefulness goes beyond peer to peer...
- geocar 13y ago
  WebRTC isn't just non-trivial: It's hard, and the hardest part is the fact that every service provider has to implement a complex network configuration that is difficult to test and exercise. Even tunnelling IPv6 would be preferable, but my point was about making browser vendors do "the hard work" instead of making service providers.
AshleysBrain 13y ago
SDP is a session description protocol, not an addressing protocol. WebRTC will be able to use IPv6 addressing in future, too, and supporting IPv4 where possible means it's practical to use now as well.
- geocar 13y ago
  > SDP is a session description protocol, not an addressing protocol SDP is most certainly an addressing protocol. It's a very complicated one that uses many binary tokens including IPv4 addresses (or IPv6 adddresses) and port numbers, cookies, and keys. That some of the binary tokens used in the SDP addresses are discovered using ICE/STUN (sometimes) complicates service providers greatly.

vladimirralev 13y ago

TURN/ICE is supposed to work just fine on symmetric NATs. Chrome even supports single-socket TCP relays, which can't be broken easily by any sane firewall. I personally have a few boxes testing it with only TCP 80 port allowed and it still finds a way to connect. A few tricks on the TURN side have to be employed but it's pretty robust. Whatever issue the OP has to be a bug or configuration issue. There are known problems and I still see a lot of freezes, protocol or hardware compatibility issues, CPU overload and so on, but straight Chrome to Chrome connections seem robust.

alexfreska 13y ago
Not all people have Chrome or latest version of Chrome and I think a fairly recent version is required to relay over TCP.