rtc chat v2

New features:

  • Ability to receive WebRTC calls, just like phone calls
  • Relayed WebRTC communication for better privacy

Connecting two browsers

WebRTC capable browsers can communicate with each other, but they need help from a 3rd party for finding and connecting to each other. One main objective of rtc chat service is to provide this help. And to do so in privacy preserving ways. Two alternative connect methods are being offered. hers


  • Secret word rendezvous service

With this method, two users agree upon one secret word and a time to connect. They both open the rtc chat rendezvous service, enter the secret word and rtc chat server will immediately connect the two. No registration or user accounts required.


  • Personal callee service

Alternatively, a user can open the rtc chat callee service in a browser tab and run it in the background. This allows the user to await incoming calls from any number of other users (from anyone having access to the callee's companion caller URL).


Both connect methodes work fully independent of any 3rd party internet infrastructure. This has two implications. 1. When using rtc chat, no 3rd party servers will be contacted by the clients. 2. It is easily possible to deploy rtc chat server in intranet, and even in ad hoc mesh networking environments.


Receiving WebRTC calls

In order to wait for incoming calls, a user must first retrieve a pair of custom callee and caller URL's from the rtc chat callee service.

  • Step 1: The user will copy a custom "caller URL" to the clipboard. The caller URL is like a phone number. This URL is for sharing with friends. By opening the caller URL in a browser, others will be able to call this user. A sample caller URL:

    https://timur.mobi:8000/call:xx-xx-xx-xx

  • Step 2: The user will now activate her personal callee service. At this point, the user is advised to bookmark the custom callee URL. A sample callee URL:

    https://timur.mobi:8078/callee:xxxx-xxxx-xxxx-xxxx


Callee and caller URL's are disposable. You can create new URL-pairs as often as you like. They automatically outdate and get discarded when not used for three month (92 days).


Whenever someone opens a caller URL - while the companion callee URL is awaiting calls - caller and callee will get connected. The caller will see the dialog shown at the top of this page and is asked to enter some name to identify herself towards the callee. When the "Call" button is hit, the callee will receive an audio notification, similar to a phone ringing.


The callee will see the name of the caller and will get the option to answer the call or to just mute the signal. In case the callee answers the call, the WebRTC link will be established and a chat application will be started on both sides. At this moment, the https-connections used for signaling, will get dropped.


If the caller has requested to use a P2P-link (rather than a relayed connection), the callee gets to choose between relayed and P2P link. The callee has the final say in this regard.


P2P vs. relayed WebRTC

Users can choose between two WebRTC communication links: P2P or relayed. In P2P mode both clients will talk directly to each other. This results in the best possible transfer rates.


In relayed mode, all WebRTC traffic will be routed through one or more relay servers. When using a relayed communication link, the two clients will not expose their original IP addresses.


rtc chat v2 by default uses a relayed communication link. A P2P link will only be established, if it is requested by both clients. (See "Use P2P link" option in the dialog box shown at the top of this page.)


Relayed WebRTC

WebRTC communications normally use direct P2P - or, if this is not possible, are routed by a TURN server. The users IP address is exposed to the other client in both cases.


In order to keep the users IP address and network topology private, rtc chat v2 makes use of a UDP proxy mechanism to relay all WebRTC traffic.


Starting a session, both browsers will send their SDP (Session Description Protocol) "offers" and "answers" over HTTPS to the rtc chat rendezvous service. To establish a relayed WebRTC communication link, the rendezvous service will modify the SDP data on the fly. Sample SDP offer:

{\"type\":\"offer\",\"sdp\":\"v=0\\r\\no=Mozilla-SIPUA-23.0 16265 0 IN IP4 0.0.0.0\\r\\ns=SIP Call\\r\\nt=0 0\\r\\na=ice-ufrag:04cadde4\\r\\na=ice-pwd:19ff4ab3f7abfa186e97c4ea0aaceaf4\\r\\na=fingerprint:sha-256 61:6F:5D:31:F4:08:CC:10:CB:D7:86:A4:49:66:BD:AC:40:6C:BA:E5:DF:1B:19:EE:DC:B5:2C:F2:77:26:F9:3C\\r\\nm=application 49206 SCTP/DTLS 5000 \\r\\nc=IN IP4 109.74.203.226\\r\\na=fmtp:5000 protocol=webrtc-datachannel;streams=16\\r\\na=sendrecv\\r\\na=candidate:0 1 UDP 2112356607 192.168.3.198 49206 typ host\\r\\na=candidate:1 1 UDP 1692991487 109.74.203.226 49206 typ srflx raddr 192.168.3.198 rport 49206\\r\\na=candidate:0 2 UDP 2112356606 192.168.3.198 33259 typ host\\r\\na=candidate:1 2 UDP 1692991486 109.74.203.226 33259 typ srflx raddr 192.168.3.198 rport 33259\\r\\n\"}

In particular:


c=IN IP4 109.74.203.226
a=fmtp:5000 protocol=webrtc-datachannel;streams=16
a=sendrecv
a=candidate:0 1 UDP 2112356607 192.168.3.198 49206 typ host
a=candidate:1 1 UDP 1692991487 109.74.203.226 49206 typ srflx raddr ...
a=candidate:0 2 UDP 2112356606 192.168.3.198 33259 typ host
a=candidate:1 2 UDP 1692991486 109.74.203.226 33259 typ srflx raddr ...


IP address 109.74.203.226 appears three times in this SDP offer. It is the IP address of our UDP forwarding proxy. The rtc chat rendezvous service has put this IP address here, replacing the original public IP address of the client device. At the same time, it has started a UDP forwarding proxy instance, configured with the client's original IP address as it's target. The modified SDP offer will be delivered to the other client. And the same thing happens - the other way around - with the SDP answer coming back from the other client.


The two browsers are being forced into using the transparent UDP forwarding proxy for all their WebRTC communications. In fact, with a WebRTC link configured this way, the two browsers will assume, that the UDP forwarding proxy IS the other client. Neither of the two clients will be able to gain knowledge of the other clients real IP address. This is unlike using ICE/TURN for relayed WebRTC. So with rtc chat, you get to use all the advantages of WebRTC (end-to-end encryption, realtime two-way audio/video delivery*, etc.), but without your IP address being exposed.


Note: on the timur.mobi demo server, audio/video delivery, as well as file transfers, are currently - due to bandwidth issues - not available when using a relayed communication link.


Code

The v2 server consists of roughly 800 lines of code. This includes rendezvous + callee service, UDP proxy, STUN service and http server. rtc chat is really small. Memory footprint is about 7 MB for light use. For example, it is easily possible to run the rtc chat server in the back of a Galaxy Nexus phone running Ubuntu phablet OS.

github.com/mehrvarz/rtcchat2


More