WebRTC is short for Web Real-Time Communication. Through it, Web developers can easily and quickly develop rich real-time multimedia applications without downloading and installing any plug-ins.

This paper summarizes the relevant knowledge and personal opinions I have learned in the course of exploring WebRTC in the past two days, and explains some basic uses of WebRTC combined with my own practice.

An overview of the

WebRTC allows Web applications to establish point-to-point connections between browsers to stream video, audio, or any other data.

Virtually all modern browsers support WebRTC:

WebRTC provides three core apis:

  • GetUserMedia: You can get a local media stream that contains several tracks, such as video and audio tracks.
  • RTCPeerConnection: Used to establish P2P connections and transmit multimedia data.
  • RTCDataChannel: Establishes a two-way communication data channel that can pass multiple data types.

Through these three apis, we can capture local audio and video streams, and then establish point-to-point connections with other browsers to send audio and video streams to each other. We can also establish a two-way data channel to send text, files and other real-time data.

Get local media streams

With the getUserMedia function, we can make a request for a local media stream:

navigator.getUserMedia(constraints, successCallback, errorCallback);
Copy the code

The function takes three arguments, a constraint, a successful callback, and a failed callback. Once a media stream is successfully acquired, it can be provided to a JavaScript agent that plays the audio or video element locally, postprocesses it, or sends it to the other end.

Here is a simple example of accessing the camera and playing the video on the page:

Check it out on CodePen.

I added WebRTC Adapter to handle browser compatibility. When the button is clicked, the local video is obtained through getUserMedia, and the browser will pop up a box to ask whether the user agrees or not. After the video stream is successfully obtained, the stream is set as the source object of the video.

Point-to-point connections

After obtaining the local media stream, you need to send the media stream to the peer party for an audio and video call. In WebRTC, the communication parties directly establish point-to-point connections, and data does not need to be forwarded by the server.

To establish a connection, you need to know the IP address and port number of the peer. In real networks, hosts are usually located behind the NAT device, which is also called the Intranet. The NAT device translates internal and external communication addresses, for example, mapping 192.168.0.3 to 120.132.92.21:9202. Through NAT, a small number of public IP addresses can represent a large number of private IP addresses, helping to solve the problem of IPv4 address exhaustion. NAT penetration (Intranet penetration) is required to establish connections with devices on the Intranet.

WebRTC establishes P2P connections through Interactive Connectivity Establishment (ICE). ICE is a framework that integrates STUN and TURN protocols to provide a unified implementation of NAT penetration technology.

RTCPeerConnection

In WebRTC, we establish point-to-point connections between communication parties through RTCPeerConnection. This interface provides the implementation of methods to create, hold, monitor and close connections.

To establish the connection, we need a signaling server for exchanging various metadata (signaling) when establishing communication between browsers. At the same time, the STUN or TURN server is required to complete NAT traversal. The establishment of a connection consists of two parts: signaling exchange and setting up ICE candidates.

After a successful connection is established, you can add a stream to RTCPeerConnection via addStream to transmit media stream data, and you can listen for the addStream event to obtain the stream sent by the peer.

Signaling exchange

The signaling exchange process is as follows:

  1. Each communication party (Party A and Party B) creates an INSTANCE of RTCPeerConnection (PC).
  2. A throughcreateOfferMethod to create an OFFER signaling that contains the SDP description of a.
  3. A throughsetLocalDescriptionMethod to set the SDP description of a to the PC instance of a.
  4. User A sends the Offer signaling to user B through the signaling server.
  5. B bysetRemoteDescriptionMethod to set a’s SDP description to B’s PC instance.
  6. bcreateAnswerMethod Establish an SDP description ANSWER signaling including B.
  7. B bysetLocalDescriptionMethod to set b’s SDP description to B’s PC instance.
  8. User B sends the Answer signaling to User A through the signaling server.
  9. A throughsetRemoteDescriptionMethod to set user B’s SDP description to user A’s PC instance.

SDP is the session description protocol used to describe the initialization parameters of streaming media.

Signaling is transmitted through HTTP, WebSocket, and DataChannel.

Adding ICE candidates

Each communication party creates a PC instance configured with the ICE server and listens for icecandidate events. When an ICE candidate becomes available, the ICecandidate event is triggered. The communication parties need to send the ICE candidate information to each other through the signaling server. When you receive the ICE candidate sent from the other side, you call the addIceCandidate method and add it to your PC instance.

The sample

The following is a simple example program, communication is local, eliminating the signaling exchange process.

Check it out on CodePen.

Refer to the link

  • webrtc.org/
  • Implement WebRTC P2P connection
  • Implementation of NAT Traversal under ICE Protocol (STUN&TURN)
  • P2P technology STUN, TURN, ICE detailed explanation
  • WebRTC introduction and simple application