WebRTC consist of 3 main parts MediaStream: Allows access of media on user machine i.e camera and microphone RTCPeerConnection: Set up a peer connection RTCDataChannel: create a channel between peers for bidirectional connection for arbitrary data (we won’t use it for our video conference app)
•webrtc = real time communication •find a peer to peet path to exchange video and audio in an efficient and low latency •standadized api •rich communnication browser,mobile
•A wants to connect to B • A finds out all possible ways the public can connect to it • B finds out all possible ways the public can connect to it • A and B signal this session information via other means • WhatsApp, QR, Tweet, WebSockets, HTTP Fetch... • A connects to B via the most optimal path • A & B also exchanges their supported media and security
inside webrtc
• NAT • STUN, TURN • ICE • SDP • Signaling the SDP
8992:10.0.0.2:GET:4.4.4.4:80 | 10.0.0.1<=router=> 5.5.5.5. | 4.4.4.4:80 3333:5.5.5.5:GET:4.4.4.4:80 | 80:4.4.4.4:200 OK:5.5.5.5:3333
outside wild shouldnot know about the A's internal address so here router or gateway comes as a hero router maintains a NAT table
INTERNAL IP | INTERNAL PORT | EXTERNAL IP | EXT PORT | DEST IP | DEST PORT 10.0.0.2. 8992. 5.5.5.5. 3333. 4.4.4.4. 80
router receive the response from 4.4.4.4:80 indentfiy who is 5.5.5.5:3333 translate to internal ip
NAT TRANSLATION METHOD
• One to One NAT (Full-cone NAT) • Address restricted NAT • Port restricted NAT • Symmetric NAT for this webrtc is useless rather conside a websocket connection
• One to One NAT (Full-cone NAT) Packets to external IP port on the router always maps to internal IP port without exceptions
INTERNAL IP | INTERNAL PORT | EXTERNAL IP | EXT PORT | DEST IP | DEST PORT 10.0.0.2. 8992. 5.5.5.5. 3333. 4.4.4.4. 80
address restricted NAT : • Packets to external IP:port on the router always maps to internal IP:port as long as source address from packet matches the table (regardless of port) • Allow if we communicated with this host:port before
INTERNAL IP | INTERNAL PORT | EXTERNAL IP | EXT PORT | DEST IP | DEST PORT
10.0.0.2. 8992. 5.5.5.5. 3333. 4.4.4.4. 80
if the reqest server is new reject
communication may have occurred before from dns records,udp or any other mean
port restricted NAT : • Packets to external IP:port on the router always maps to internal IP:port as long as source address from packet matches the table • Allow if we communicated with this host:port before
80 4.4.4.4 200 ok 5.5.5.5 3333 22 3.3.3.3 200 ok 5.5.5.5 3333 => deined as not recognized
INTERNAL IP | INTERNAL PORT | EXTERNAL IP | EXT PORT | DEST IP | DEST PORT
10.0.0.2. 8992. 5.5.5.5. 3333. 4.4.4.4. 80
10.0.0.2 9999 5.5.5.5 4444 3.3.3.3 80
Symmetric NAT : • Packets to external IP port on the router always maps to internal IP port as long as source address and port from packet matches the table • Only Allow if the full pair match
80 4.4.4.4 200 ok 5.5.5.5 3333 => only full match of ip:port is supported
what is stun ? • Session Traversal Utilities for NAT • Tell me my public ip address/port through NAT • Works for Full-cone, Port/Address restricted NAT • Doesn't work for symmetric NAT • STUN server port 3478, 5349 for TLS • Cheap to maintain
10.0.0.2 10.0.0.1 5.5.5.5 (9.9.9.9:3478) [stun server]
8992:10.0.0.2 STN 9.9.9.9:3478 => 3333 : 5.5.5.5 STN 9.9.9.9:3478 => 3333:5.5.5.5 STN 9.9.9.9:3478
INTERNAL IP | INTERNAL PORT | EXTERNAL IP | EXT PORT | DEST IP | DEST PORT 10.0.0.2 8992 5.5.5.5 3333 9.9.9.9 3478
STUN IS Nothing but a public response for discovery
10.0.0.2 | 5.5.5.5:3333 lets connect as full cloned nat allow everyone 7.7.7.7:4444 192.168.1.2
STUN DOESNT WORK ON SYMMETRIC NAT
TURN :
• Traversal Using Relays around NAT • In case of Symmetric NAT we use TURN • It's just a server that relays packets • TURN default server port 3478, 5349 for TLS • Expensive to maintain and run
ICE : • Interactive Connectivity Establishment • ICE collects all available candidates (local IP addresses, reflexive addresses - STUN ones and relayed addresses
- TURN ones) • Called ice candidates • All the collected addresses are then sent to the remote peer via SDP
SDP :
•Session Description Protocol • A format that describes ice candidates, networking options, media options, security options and other stuff • Not really a protocol its a format • Most important concept in WebRTC • The goal is to take the SDP generated by a user and send it "somehow" to the other party
sdp sample :
v=0 0=- 9148204791819634656 3 IN IP4 127.0.0.1 S=-t=0 0 a=group:BUNDLE audio video data a=msid-semantic: WMS kyaiqbOs7S2h3€oSHabQ3JIBqZ67cFqZmWFN m=audio 50853 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4 192.168.1.64 a=rtep:50853 IN IP4 192.168.1.64 a=candidate:3460887983 1 dp 2113937151 192.168.1.64 50853 typ host generation O a=candidate:3460887983 2 up 2113937151 192.168.1.64 50853 typ host generation 0
SDP Signaling : • Send the SDP that we just generated somehow to the other party we wish to communicate with • Signaling can be done via a tweet, QR code, Whatsapp, WebSockets, HTTP request DOESN'T MATTER! Just get that large string to the other party
WEBRTC :
- A wants to connect to B
- A creates an "offer", it finds all ICE candidates, security options, audio/video options and generates SD, the offer is basically the SDP
- A signals the offer somehow to B (whatsapp)
- B creates the "answer" after setting A's offer
- B signals the "answer" to A
- Connection is created
in simple format : • We will connect two browsers (Browser A & Browser B) • A will create an offer (sp) and set it as local description • B will get the offer and set it as remote description • B creates an answer sets it as its local description and signal the answer (sdp) to A • A sets the answer as its remote description • Connection established, exchange data channel
• Pros • P2p is great! low latency for high bandwidth content • Standardized API I don't have to build my own • Cons • Maintaining STUN & TURN servers • Peer 2 Peer falls apart in case of multiple participants
for the security vulnerability reffered to the doc : NAT SLIPSTREAMING https://medium.com/dsc-sastra-deemed-to-be-university/nat-slipstreaming-1a94351dd518
Open two browsers Open DevTools on both Paste peerA.js content in first browser dev tools Copy the SDP offer generated JSON Got to the second browser and create "offer" object and set it to the SDP you copied (signled) Paste peerB.js content in second browser dev tools Go back to First browser (peer A) and paste the content of peerA_Final.js use sendChannel.send() to send data from peerA use remoteConnection.channel.send() to send data from peerB
PEER A : const localConnection = new RTCPeerConnection()
localConnection.onicecandidate = e => { console.log(" NEW ice candidate!! on localconnection reprinting SDP " ) console.log(JSON.stringify(localConnection.localDescription)) }
const sendChannel = localConnection.createDataChannel("sendChannel"); sendChannel.onmessage =e => console.log("messsage received!!!" + e.data ) sendChannel.onopen = e => console.log("open!!!!"); sendChannel.onclose =e => console.log("closed!!!!!!");
localConnection.createOffer().then(o => localConnection.setLocalDescription(o) )
PEER B :
const remoteConnection = new RTCPeerConnection()
remoteConnection.onicecandidate = e => { console.log(" NEW ice candidnat!! on localconnection reprinting SDP " ) console.log(JSON.stringify(remoteConnection.localDescription) ) }
remoteConnection.ondatachannel= e => {
const receiveChannel = e.channel;
receiveChannel.onmessage =e => console.log("messsage received!!!" + e.data )
receiveChannel.onopen = e => console.log("open!!!!");
receiveChannel.onclose =e => console.log("closed!!!!!!");
remoteConnection.channel = receiveChannel;
}
remoteConnection.setRemoteDescription(offer).then(a=>console.log("done"))
//create answer await remoteConnection.createAnswer().then(a => remoteConnection.setLocalDescription(a)).then(a=> console.log(JSON.stringify(remoteConnection.localDescription))) //send the anser to the client
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent