WEBRTC Server Setup

1.WebRTC Backend Service:

• Room server for calls

  The room server is used to create and manage call session status maintenance, is the two sides call or multiparty calls, join and leave the room and so on, we temporarily follow the Google deployment on the Gae platform APPRTC this room server implementation, the Gae The app's source code can be obtained on the github.com. The implementation is a Python-based Gae app that we need to download Google Gae's offline development package to our own Linux server to run the project and build a room server in the continental Internet environment.

• Signaling server for calls (signaling server)

  A signaling server is a role used to manage and assist a call terminal to establish a point-to-point call to the center. This role is responsible for the task:

1. Connection control message used to control the initiation or termination of communication
2. Messages used to advertise each other when an error occurs
3. Media stream metadata for each side, such as decoder, decoder configuration, bandwidth, media type, etc.
4. Key data used to establish a secure connection between the two
5. Data on the network that the outside world can see, such as WAN IP address, port, etc.

The specific protocol implementation of the signaling server is not strictly regulated, as long as the function is implemented.
We still use the GO language and WebSocket-based signaling server Collider provided by Google and the above room server can be obtained on Github. Get the running environment of GO language on our own Linux server to run the signaling. server.

• Firewall Hole-Punching server (Stun/turn/ice server)

  Most of us currently connect to the Internet in the back of a firewall or behind a home (NAT) router that configures a private subnet, which causes our computers to have IP addresses that are not WAN IP addresses and therefore cannot communicate directly with each other. Because of this scenario, we have to find a way to get through these firewalls or home (NAT) routers so that two of the computers in the private network can communicate with each other.

STUN (simple traversal of the UDP over-nats,nat UDP easy traversal); Stun protocol servers are used to solve these problems:

1. Detects and discovers if the communication is hiding behind a firewall or NAT router.

2. Determine the IP and port and NAT type of the WAN exposed by the intranet client; The stun server uses this information to assist in establishing peer-to-peer UDP traffic between computers in different intranets.

Stun protocol is a good solution to the general home (NAT) router environment of the hole, but for most of the enterprise network environment is not very good.

A new solution is required: TURN (Traversal Using Relay NAT, which allows the connection of TCP or UDP across a NAT or firewall. Turn is a client-server protocol. Turn's Nat penetration method is similar to stun, by obtaining a NAT through the application layer's public address, but the terminal that implements the turn client must interact with turn server before the communication begins, and requires turn server to generate "relay port". That is relayed-transport-address. Then TURN server establishes a peer, the remote endpoint (remote endpoints), to begin the relay (relay) action, TURN client exploits Relay The port transmits the data to the peer, which is then forwarded to the turn client of the other party. Transfer data via the server's newly generated peer.

The ICE protocol is a comprehensive NAT traversal solution that combines the first 2 protocols.

UDP-based communication is established through the Offer/answer model. Ice is an extension of the Offer/answer model by including multiple IP addresses and ports in the offer and answer SDP (Session Description Protocol), and then pairing the IP addresses in the local SDP and remote SDP. The connectivity test is then performed through peer-to-peer connectivity checks, and if the test passes indicates that the transport address pair can establish a connection. Where the IP address and port (that is, the address) has the following: The local address, the Server-reflexive address (the address that the intranet address is mapped by NAT), the relayed address (the address that corresponds to the turn forwarding server), and the peer from the stun server Reflexive address and so on.

2. Room server and Signaling Server setup:

We set up this series of backend servers in an Ubuntu Linux server on the public network.

Server code we chose Googlechrome's Open source project, which can be found on GitHub:

Https://github.com/GoogleChrome/webrtc

Some examples of this project can be obtained at the following URL:

http://googlechrome.github.io/webrtc/

Running Google's room server in our own server APPRTC needs to rely on Google App Engine SDK for Python and Grunt.

First, build the room server APPRTC

1. First we install Grunt:

[email protected]:~/$ sudo apt-get install npm
[email protected]:~/$ sudo apt-get install nodejs-legacy
[email protected]:~/$ sudo npm -g install grunt-cli

1. Download the source of the project to a directory:

[email protected]:~/$ cd ~;
[email protected]:~/$ git clone https://github.com/GoogleChrome/webrtc.git;

1. Terminal shell switches the current working directory to the previous step of the downloaded project directory WEBRTC, and then installs the grunt and grunt dependencies:

[email protected]:~/$ cd webrtc;
[email protected]:~/webrtc$ npm install;

1. Before running the APPRTC room server we need to grunt compile the JS file of the project and the like:

[email protected]:~/webrtc$ grunt;

The above compilation process will automatically download and install the Google App Engine SDK to the current directory.

[email protected]:~/webrtc$ ls
bower.json   google_appengine         Gruntfile.js  LICENSE.md    README.md        samples
build        google_appengine_1.9.17.zip  images        node_modules  run_python_tests.py  webtest-master
CONTRIBUTING.md  grunt-chrome-build       index.html    package.json  run_python_tests.sh  webtest-master.tar.gz

Next, we need to add the directory of the Google App Engine SDK to the system environment variable$PATHand make it effective.

[email protected]:~/webrtc$ echo "export PATH=$PATH:$PWD/google_appengine" > ~/.bash_profile
[email protected]:~/webrtc$ source ~/.bash_profile

This time we can directly run our room server APPRTC. Use the following command to turn on (hostname: vpn.wuqiong.tk can use their own to give me the money IP address instead):

[email protected]:~/webrtc$ dev_appserver.py --host vpn.wuqiong.tk  samples/web/content/apprtc/

Build the signaling server again

Signaling server We still use the WebSocket-based signaling server in the go language provided in the Google Chrome WEBRTC project: Collider.

We need to install the Go Language Run environment support first:

[email protected]:~/webrtc$ sudo apt-get install golang-go

Then create a new directory (Collider_root) in our user directory to store this collider go Code program.

[email protected]:~/webrtc$ mkdir -p ~/collider_root;
[email protected]:~/webrtc$ export COLLIDER_ROOT=$HOME/collider_root; //也可以加入~/.bash_profile

The next step is to link the WENRTC project directory below the COLLIDER code directory to $collider_root/src down, prepare for the subsequent compilation work;

[email protected]:~/webrtc$ ln -sf $PWD/samples/web/content/apprtc/collider/collider $COLLIDER_ROOT/src/
[email protected]:~/webrtc$ ln -sf $PWD/samples/web/content/apprtc/collider/collidermain $COLLIDER_ROOT/src/
[email protected]:~/webrtc$ ln -sf $PWD/samples/web/content/apprtc/collider/collidertest $COLLIDER_ROOT/src

After all the preparation, we will mainly compile and install collider:

[email protected]:~/webrtc$ go get collidermain
[email protected]:~/webrtc$ go install collidermain

This time, the signaling server binaries are installed on the $collider_root/bin. You can turn on the run signaling server with the following command:

[email protected]:~/webrtc$ $COLLIDER_ROOT/bin/collidermain -port=8089 -tls=false

The signaling server is temporarily running in non-TLS mode. Because our self-signed certificate WebSocket can't communicate.

3.stun/turn/ice Server Build-up

We opted for a richer coturn as our NAT traversal server, the project is an open source project in C + + language, Project address: https://code.google.com/p/coturn/or we download the compiled package directly, In the following site can download our corresponding platform package: http://turnserver.open-sys.org/downloads/v4.4.1.2/Open this URL, according to our server type select Download, I now choose the Debian and Ubuntu system packages:

cd ~;wget http://turnserver.open-sys.org/downloads/v4.4.1.2/turnserver-4.4.1.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz 

Then unpack the package:

tar xvfz turnserver-4.4.1.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz

Read the installation manualINSTALLfiles in detail and follow the instructions to install them:

 
 
$ sudo apt-get update
$ sudo apt-get install gdebi-core
$ sudo gdebi coturn*.deb

Then edit the configuration file to open the system default boot configuration:

$ vim /etc/default/coturn

Remove the comment from the file that opened the edit aboveTURNSERVER_ENABLED=1and save the exit.

Then edit the Coturn configuration file according to the actual situation/etc/turnserver.conf, for example, I open the configuration entry as follows:

listening-device=eth0
listening-ip=~~106.186.127.xxx~~
relay-device=eth0
relay-ip=~~106.186.127.xxx~~
Verbose
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=diveinedu user=diveinedu:0x06b2afcf07ba085b7777b481b1020391 user=diveinedu:diveinedu
stale-nonce cert=/etc/turn_server_cert.pem pkey=/etc/turn_server_pkey.pem
no-loopback-peers
no-multicast-peers
sha256
mobility
no-cli

The self-signed certificate cert and Pkey configured above is generated with the OpenSSL command:

sudo openssl req -x509 -newkey rsa:2048 -keyout 99999 -nodes

After all the configuration of the wall server is complete, everything is ready before you start the command:

service coturn start;

Settings for room servers and signaling servers

After three servers are built, we need a certain amount of consolidation to enable them to work together: constants.py in the APPRTC directory is a configuration file for some constant configuration information, such as the following settings:

 
#TURN_BASE_URL = ‘https://computeengineondemand.appspot.com‘
TURN_BASE_URL = ‘http://apprtc.diveinedu.com‘
#TURN_URL_TEMPLATE = ‘%s/turn?username=%s&key=%s‘
TURN_URL_TEMPLATE = ‘%s/turn.php?username=%s&key=%s‘
#CEOD_KEY = ‘4080218913‘
CEOD_KEY = ‘diveinedu‘

#WSS_HOST_PORT_PAIR = ‘apprtc-ws.webrtc.org:443‘
WSS_HOST_PORT_PAIR = ‘apprtc.diveinedu.com:8089‘

Since our signaling server does not have the Secure Socket mode enabled, we need to change the APPRTC code to do the following changes in apprtc.py:

 
 
def get_wss_parameters(request):
  ws_host_port_pair = request.get(‘wshpp‘)
  ws_tls = request.get(‘wstls‘)

  if not ws_host_port_pair:
    ws_host_port_pair = constants.WSS_HOST_PORT_PAIR

  if ws_tls and ws_tls == ‘false‘:
    wss_url = ‘ws://‘ + ws_host_port_pair + ‘/ws‘
    wss_post_url = ‘http://‘ + ws_host_port_pair
  else:
    wss_url = ‘ws://‘ + ws_host_port_pair + ‘/ws‘
    wss_post_url = ‘http://‘ + ws_host_port_pair
  return (wss_url, wss_post_url)

Change the original WSS and HTTPS scheme to WS and HTTP, and do not allow the client or browser to use SSL links. Of course, if there is a certificate issued by the signing authority of the third-party root certificate, it is not necessary.

The corresponding signaling server also needs to do a little bit of setup: Edit Collider/collidermain/main.go, modify the settings of your own room server URL:

 
//var roomSrv = flag.String("room-server", "https://apprtc.appspot.com", "The origin of the room server")
var roomSrv = flag.String("room-server", "http://apprtc.diveinedu.com:8080/", "The origin of the room server")

After these simple room servers and the custom settings of the signaling server, we built a simple service based on the Google project's own WEBRTC.

Open http://apprtc.diveinedu.com:8080/with Google Chrome, register your room and you'll be able to make a video call. Of course, the previous WEBRTC for iOS framework will allow direct video calls to the browser and iOS native apps.

This document is organized by the Changsha Camp David Education .

WEBRTC Server Setup