How WebRTC Works
Browser compatibility
WebRTC has a global ~62% compatibility rate in 2016.
You can use it safely on most of the major desktop browsers.
http://caniuse.com/#search=webrtc
Parts of WebRTC
WebRTC has 3 major parts built into the browser.
- Audio engine
- Video engine
- Transport layer
Audio & Video engine
You can access the media stream trough the getUserMedia API.
1 | navigator.getUserMedia({video:true, audio:false}, |
This asks for permission to use the webcam or microphone according to the given constraints.
The media stream is represented as a Blob object in Javascript ( immutable objects that represent raw data ). The createObjectUrl method creates a DOM String that represents the media stream for the current session and can be used as source on video elements.
Transport Layer
The transportation layer can be used trough the RTCPeerConnection object.
The job of the RTCPeerConnection object is to maintain the session and state of a peer connection in the browser. It also handles the setup and creation of a peer connection.
To connect people you also need a signaling server which is not defined in the WebRTC standard.
Signaling Server
Most of the time WebSockets is used for the signaling server.
For production some people advise to use socket.io (http://socket.io/) which is built on top of WebSockets.
You can also use traditional frameworks like XMMP.
Example connection
A connection between user1 and user2:
- user1 calls CreateOffer()
- user1 sets local session description
- user1 sends its session description to user2 trough the signaling server
- user1 sends its Ice candidate to user2
- user2 sets the incoming session description from user1 as remote session description
- user2 calls createAnswer() and passing user1 session description
- user2 also send its local session description to user1
- user1 sets its remote session description what he got from user2
- user2 sends its Ice candidate to user1
A connection starts with an offer from one user.
This sends the sdp file to the server that gets sent to the offered user.
The sdp file contains information about media codecs etc. used by the offering party. These sdp files are exchanged so both client has his and the other clients sdp saved.
To finalize the the peer to peer connection you also need to use the ICE framework ( built into the browser ) that uses either STUN or TURN protocols to figure out the correct local / remote IP of the peers. Depending on the users network configuration ICE either uses STUN or TURN.
During the setup of the RTCPeerConnection object you can specify a STUN or TURN server that is mainly used to get the outside IP of the client.
1 | var configuration = { |
After the peer connection has been established we can use the other peers media stream the same way as the local stream.
1 | yourConnection.addStream(stream); |