Author: Kang Shaojun

Signaling service

From the above we know that two clients negotiate media information and network information, then how to exchange? Do you need a middleman to do the exchange? So we need a Signal server to forward each other’s media information and network information. When we develop apps based on WebRTC API, we can connect each other’s apps to the Signal Server (usually built on the public network, or a LAN accessible to both ends). With the help of the signaling Server, we can realize the exchange of SDP media information and Candidate network information. Signaling server not only exchange media information SDP and network information Candidate, such as: room management, user list, user in, user out of IM functions. As shown in the figure.

The term used to describe network information in WebRTC is candidate, as shown below.

  1. Media Negotiation: SDP
  2. Network negotiation: candidate

Connection is established

After introducing the meaning of the individual parts of the ICE framework, let’s take a look at how the framework works as follows. 1. The two parties exchange SessionDescription data through a third-party server.

2. The Peer obtains its OWN NAT structure, subnet IP address, public IP address, and port from the STUN Server through STUN protocol. The IP address and port pair are called ICE Candidate.

3. The Peer parties exchange their ICE Candidates through a third-party server and should use the same NAT to set up the connection, while the system should use an asymmetric NAT to set up the connection. Public network candidates identified by the STUN Server are required to communicate.

4. If the public network Candidate discovered only through STUN Server still fails to establish a connection, in other words, at least one of the connected parties is under symmetric NAT, then the client under symmetric NAT needs to seek the forwarding service provided by TURN Server. The Candidate is then keyed to the Peer.

5. The Peer sends packets to the destination IP port and establishes an encrypted long connection based on the key involved in SessionDescription and the content to be transmitted.

A(local) and B(remote) represent two persons. Initialize and create A PeerConnection respectively, and add local media streams to the PeerConnection. The processing flow is as follows.

  1. Create A Offer
  2. A Save Offer(set local description)
  3. A sends an Offer to B
  4. B Save Offer(set remote description)
  5. B. create Answer
  6. B Save Answer(Set local description)
  7. B sends the Answer to A
  8. A Save Answer(Set remote description)
  9. A sends the Ice Candidates to B
  10. B sends the Ice Candidates to A
  11. User A and User B receive and play the media stream from the other party

Here we do not introduce the use of specific API and code writing, just need to understand the principle and process of connection establishment and call.

WebRTC Group: 425778886 open source address:github.com/kangshaojun