Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Note that no peer-to-peer data goes through the server; The server acts only to broker connections.

Q1. Does this support connecting to a peer behind a NAT device?

Q2. Does this support connecting two peers each behind its own NAT?

Because a vast majority of real world cases will fall into either of these two categories.



It is NAT reversal, even there are still many issues to be solved with the ICE. WebRTC team is working fast in this aspect...

BTW, consider that they are shipping first final version in march so NAT reversal is important. YEY!


It uses SDP to exchange ICE candidates. At the moment the SDP tries to multiplex video/audio and SCTP (data channel).


Does WebRTC have any sort of extension mechanism whereby I can drop in my own version of NAT traversal logic?

Speaking from past experience, STUN and ICE are OK, but they got the whole process fundamentally wrong. They let the clients drive the traversal process. This is substantially inferior to letting a dedicated mediating server do that instead. I did that with one of my past projects and it helped with connecting peers in a large number of obscure scenarios.


You should hack the Chromium webkit for this.


you can add one or more TURN server(s) into the mix, but apart from that there is no other way using just Javascript.


ICE/STUN (which is used by WebRTC and thus PeerJS) support NAT traversal in all cases but a pair of symmetric NATs, which means some single digit percentage of connections will not work. For those cases, WebRTC/PeerJS support using a TURN server which proxies the data, not ideal but it allows the library to work.


AFAIK, you will be/are able to add TURN server addresses to the mix. It is possible that chrome uses google's TURN servers by default.


Handles NAT traversals


Any details?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: