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.
Yes, it's a same there's no way to do connections based on IP at this moment... It was discussed some time ago on the W3C WebRTC mail list but don't know where it went :-/
The effect might be an encrypted, hard-to-block (barring deep packet inspection at all the edges or shutting off all access) communication tool. Identity verification would be important for some uses, but not for others.
OOB negotiation via any other channel can be used to join a network (see the article on serverless WebRTC)
http://blog.printf.net/articles/2013/05/17/webrtc-without-a-...
Still, props to the guy for creating the article. I didn't know that you could serialise/manipulate the SDP session descriptions before I read it.
WebRTC is inherently dependant on centralised servers.
Unlike in traditional P2P, where there is simply the problem of bootstrapping the node (getting some initial connections into the network), in WebRTC this style of doing things is barely supported.
Instead you need to exchange RTCSessionDescription's (SDP blobs) through a createAnswer/Reply API, which is doesn't facilitate your typical 'connect to a node by their IP'. These session descriptions need be tweaked according to who is connecting and what parameters, so it also doesn't allow for a node to forward another nodes details (to form an overlay).
I've been researching the process of building a true P2P application on top of web technologies, but sadly and frustratingly this is stumping my progress. The only solution would be to expose a more 'raw' connection API by creating an RTCSessionDescription based on IP addresses. It's possible to hack together a solution whereby you tweak the data in the SDP blob (see http://en.wikipedia.org/wiki/Session_Description_Protocol), but this is too cumbersome.