Exchanging WebRTC RTCPeerConnection signals manually

Question

I read that RTCPeerConnection doesn't care about the transport mechanism chosen to exchange signals (websocket, google channel, etc..). Do you think it would be possible to collect those signals, encode them with JSON and ask the user to send them to the other peer using an external mechanism (chat, email, ...) in order to completely bypass the need of a remote server?

I've done a little POC and this seems working only when both peers are on the same machine; any clue?

Thanks!

Answer 1

Yes. As long as each client receives the other client's SDP (which includes the ICE Candidates), you should be able to establish a PeerConnection. WebRTC is decoupled from the Signalling mechanism the application developers adopt. But it is imperative that these signals are transmitted, so that each client knows which IP-Port combination it should be paying attention to.

Now requesting the users to manually exchange and process these signals might turn out to be a tedious task. I'd recommend setting up a simple Server using Socket.io that would let you relay the signals with ease. You can always use AJAX Polling too.

Answer 2

Yes you can send it over email or any other transport. I don't think the result for the user will be the best, but it's one way to do it.

I would explain to you that the user that receives the SDP offer, must enter it in the browser, get the SDP answer, and send it back to the user that started the request. But I assume that when you say it works locally, you are doing all that.

You must wait for the ICE candidates too, as you are sending the offer and answers one time only, in order to allow peers to connect.