Uploaded May 2018 | Updated September 2026, 2 weeks ago
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 25 of the IOTA tutorial.
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.
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.
WebRTC uses the following main component JavaScript APIs:
- 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.
- MediaStream (more commonly known by its JavaScript function getUserMedia)
It gives access to a stream object that represent video (camera) and audio (microphone) streams.
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:
mobilefish.com/download/webrtc/webrtc_noserver.html
I have created a proof-of-concept to test if Masked Authenticated Messaging (MAM) can be used as a signaling implementation for WebRTC.
See: mobilefish.com/services/cryptocurrency/mam_webrtc.html
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.
In a production like environment this is not acceptable, but for prototyping or just for demo applications its perfect.
When using MAM it is recommended to compress your data, which will decrease the time to publish this data to the Tangle.
For example you can use the lz-string compression javascript library.
See: pieroxy.net/blog/pages/lz-string/index.html
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 25 of the IOTA tutorial.
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.
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.
WebRTC uses the following main component JavaScript APIs:
- 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.
- MediaStream (more commonly known by its JavaScript function getUserMedia)
It gives access to a stream object that represent video (camera) and audio (microphone) streams.
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:
mobilefish.com/download/webrtc/webrtc_noserver.html
I have created a proof-of-concept to test if Masked Authenticated Messaging (MAM) can be used as a signaling implementation for WebRTC.
See: mobilefish.com/services/cryptocurrency/mam_webrtc.html
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.
In a production like environment this is not acceptable, but for prototyping or just for demo applications its perfect.
When using MAM it is recommended to compress your data, which will decrease the time to publish this data to the Tangle.
For example you can use the lz-string compression javascript library.
See: pieroxy.net/blog/pages/lz-string/index.html
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota
