WebRTC and MAM Signaling
In this video series different topics will be explained which will help you to understand IOTA. It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.
The main objective of this video is to explain what WebRTC is and demonstrate a proof-of-concept WebRTC MAM signaling implementation. WebRTC (Web Real-Time Communication) was announced in 2011 and is a HTML5 specification supported by Google, Mozilla and Opera, amongst others.
Then follow us on Google News!
WebRTC provides browsers and devices with direct data, voice and video peer-to-peer communication without the need to install plugins or download native apps. WebRTC is supported by most modern browsers such as Chrome, Firefox, Safari and Microsoft Edge.
RTCPeerConnection To setup and create a peer-to-peer connection.
- RTCDataChannel To bidirectional transfer arbitrary data peer-to-peer. Every data channel is associated with an RTCPeerConnection, and each peer connection can have one or more data channels.
If two peers needs to communicate directly with each other they need to know each other public ip address and port. Often a direct connection is not possible because the peers uses a router with a built-in firewall that uses Network Address Translation (NAT).
The Interactive Connectivity Establishment framework (ICE) deals with the process of connecting peers through NATs. A STUN (Session Transversal Utilities for NAT) server allows the peers to discover their public IP address, port and the type of NAT they are behind. This information is used to establish a peer-to-peer connection. A media stream will flow directly between the peers. In most cases (~70%) a STUN server suffice to setup a peer-to-peer connection. If a STUN server cannot establish the connection, ICE uses a TURN (Traversal Using Relay NAT) server. When a TURN server is used, this server relays the media stream between the peers.
The use of a STUN server is preferred above a TURN server because a TURN server uses a lot of processing power. In a WebRTC application the STUN and TURN server locations can be specified. There are public STUN servers available but use them for prototyping or non-mission critical applications.
To create a peer-to-peer connection, the peers must also exchange several types of information first, for example: –
- Their external IP addresses and ports.
- Their codecs and media types that they support.
- When to initialise, close, and modify the communications sessions.
This exchange of information between peers is called signaling and usually an external server is used called a “signaling server” which can store this information, for example in a database. Signaling methods and protocols are not specified by the WebRTC standards.
When Alice initiates a peer-to-peer communication with Bob, Alice is called the local user (aka caller) and Bob is the called the remote user (aka callee). The information send from Alice’s browser to a signaling server is called the “offer”, and Bob’s browser information send to a signaling server is called the “answer”. The offer and answer are written in a so called Session Description Protocol (SDP) format.
To demonstrate the WebRTC signaling process use the following application: https://www.mobilefish.com/download/w…
I have created a proof-of-concept to test if Masked Authenticated Messaging (MAM) can be used as a signaling implementation for WebRTC. See: https://www.mobilefish.com/services/c…
You can use Masked Authenticated Messaging (MAM) as a signaling implementation for WebRTC. However it takes too long to establish a peer-to-peer connection because publishing the offer and answer to the Tangle takes too much time.