| That's not totally true. It's true that WebRTC currently needs a handshake server and that SDPs are a sh*t, but on ShareIt! (http://shareit.es), my own WebRTC P2P filesharing application, I have solved it using anonimous XMPP servers thanks to my framework WebP2P.io. Currently is not working just because I only was able to find one public XMPP server (Jappix.net) and they recently closed the access and with exams I'm not able to fix it (it's working using a PubNub backend channel, but only for Chromium <= v25 since recent ones generate incredible big and useless SDP strings), but it's functional. Also, regarding to using another nodes as intermediary, with the old filetransfer-only protocol (I'm changing it to be more generic and create an agnostic-protocol network, but currently I'm really busy to finish it) I was able to connect two peers between them using just the WebRTC P2P network, so YES, IT'S POSSIBLE!!! :-D Yes, I have been working very hard the last year trying to create a production-grade P2P application (I need to work to make it more robust, by the way...), and also thanks to it I've won the last week the "Most Innovative Project" on the national spanish VII Universitary Free Software Championship :-D http://www.concursosoftwarelibre.org/1213/premiados-vii-cusl |
What I was referring to was the lack of any API for signalling over already obtained network information (such as IP) rather than using a server for the initial signalling when you could use direct communications immediately after NAT has been traversed.