Web development

Server-to-Server WebRTC


WebRTC can work Peer-to-Peer and Peer-to-Server, where in the role of a feast, usually acts as a browser or mobile application. In this article, we'll show you how WebRTC works in Server-to-Server mode, what it does and how it works.
Scaling, Origin-Edge
Where can the inter-server WebRTC be needed? The Origin-Edge pattern immediately comes to mind, which is used to scale the broadcast to a large audience.

The user sends a WebRTC video stream to the Origin-WebRTC server from a browser or mobile device.
Origin-server distributes the stream to several Edge-servers.
Edge servers distribute the stream to end users on their browsers and mobile applications.

In modern CDN for video delivery, the RTMP protocol is actively used when publishing a stream to the Origin server and sending the stream to the Edge server, and end users receive a picture already by HTTP.
The advantage of WebRTC, in comparison with this approach, can be guaranteed low latency of broadcast, which can not be achieved by means of delivery of RTMP / HTTP, especially if the nodes are geographically dispersed.
However, for us, the inter-server WebRTC did not start with scaling.
Load tests
They were always in one form or another. Automatic and semi-automatic, synthetic and close to what users do. We used and use load testing to catch multi-threaded bugs, control resource leaks, optimizations, and many other things that can not be caught in normal testing.

On the latest tests, we raised Linux-servers without a GUI in the cloud and launched scripts that start many processes of the Google Chrome browser on the virtual desktop X11. Thus, real WebRTC browsers were launched that pulled and played WebRTC video streams from the Web Call Server, thereby creating a load as close as possible to the real one. For the server it looked like a real user opened a browser and took the video stream, fully using the WebRTC-stack of the browser, including decoding and rendering video.

The disadvantage of this method of testing was the performance of the test system. It's hard enough to run many Chrome processes on one Linux system, even when using a powerful server with megameters of memory and CPU. As a result, you had to raise a lot of servers and somehow manage / monitor them.

Another limitation was the lack of flexibility - we could not control the processes of chromium. There were only two operations:

Raise the process and open the required URL
Kill the process. When the URL was opened, the HTML page was loaded and an automatic connection to the server, already using JavaScript, Websocket + WebRTC, occurred. So the audience load was simulated.

A flexible load testing tool was required that would allow load on the server close to real, control software testing programmatically and ensure high testing performance.
Testing WebRTC Server-Server
We came to the conclusion that the nodes of our server can themselves become load generators if they are properly hooked to the servers being tested.

This idea was implemented in the form of WebRTC pulling . A single WCS server can pull a thread from another WCS server over WebRTC. To do this, we introduced the internal abstraction of WebRTCAgent - an object that rises on the testing node and pulls the WebRTC stream from the tested node, connecting to the tested node by Websocket + WebRTC.
After that, we took control of WebRTCAgent on REST. As a result, the load testing was reduced to calling / pull - methods on the REST interface of the testing node.

When using the inter-server WebRTC, we were able to increase the performance of load testing by about 7 times and significantly reduce the use of resources, compared to the scheme when we started the processes of Google Chrome.

So, we managed to pull WebRTC streams from other servers. The testing server connected to the tested Websocket, and as a decent browser, installed the ICE connection, DTLS, and pulled the SRTP streams on itself, it turned out to be true WebRTC pulling.

Remained very little to get a full-fledged model of Origin-Edge. To do this, it was necessary to throw such a pulling into the WCS server engine as the published stream, i.e. make it look like a stream from a webcam, and such threads WCS already knows how to distribute on all available protocols: WebRTC, RTMP, RTMFP, Websocket Canvas, Websocket MSE, RTSP, HLS.
Origin-Edge on WebRTC
It turned out that we did inter-server WebRTC for load testing, but as a result we implemented Origin-Edge scheme for scaling WebRTC broadcasts, and here's how it works:
The green line shows how the video traffic passes.

1. A user from a browser or mobile application, using a webcam, sends a WebRTC video stream named stream1 to the WCS1-Origin server. The process of sending a video stream using the web sample Two Way Streaming looks like this:
And this is the JavaScript code that is responsible for publishing the video stream through the Web API (Web SDK):

session.createStream({name:'steram1',display:document.getElementById('myVideoDiv')}).publish(); 2. Next, we call the WCS2-Edge server on the REST / HTTP API and give the command to pick up the video stream from the Origin server.



uri: wss://wcs1-origin.com:8443

remoteStreamName: stream1,

localStreamName: stream1_edge,

The WCS2 server connects to WebSockets to the WCS1 server at wss: //wcs1-origin.com: 8443 and receives a stream named stream1 by WebRTC.

After this, you can run a REST command

/rest-api/pull/find_all to display all the current pull connections.

Or the team

/rest-api/pull/terminate To close the pull-connection with the Origin WebRTC server.

3. Finally, we take the stream from the Edge server by WebRTC in the player . Enter the name of the stream stream1_edge and start playing it.
The WCS server supports several playback methods. To change the technology, simply drag up MSE or WSPlayer to play the stream not by WebRTC, but by MSE (Media Source Extensions) or WSPlayer (Websocket - player for iOS Safari).
Thus, the Orign-Edge scheme worked out and we got the scalability of the WebRTC server with low latency.

It should be noted that scalability has worked on RTMP before. The WCS server can re-publish incoming WebRTC streams to one or more servers using RTMP. In this case, support for inter-server WebRTC was a step towards reducing the overall system latency.
And again about load testing
For normal load testing, it remains to write the Web interface as a REST client that manages pull-sessions. This interface was named Console and took the following form:

Using the console, you can pull individual WebRTC streams using the current node as an Edge server. Through the same interface, you can add one or more nodes and run load tests on them with a performance rating.

There is still a lot to do and deconstruct. In particular, it's interesting to work with dynamic bitrates on the server-to-server WebRTC-channel and compare server-to-server patency with RTMP. But right now we have Orign-Edge on WebRTC and the right load tests, which give a close to real load, which can not but rejoice!
WCS5 - WebRTC server Web Call Server 5
Two Way Streaming is an example of streaming a video stream from a browser
WebRTC Player is an example of video stream playback in the browser with the ability to change WebRTC, MSE technologies , Flash, WSPlayer
Skull 11 october 2017, 9:37
Vote for this post
Bring it to the Main Page


Leave a Reply

Avaible tags
  • <b>...</b>highlighting important text on the page in bold
  • <i>..</i>highlighting important text on the page in italic
  • <u>...</u>allocated with tag <u> text shownas underlined
  • <s>...</s>allocated with tag <s> text shown as strikethrough
  • <sup>...</sup>, <sub>...</sub>text in the tag <sup> appears as a superscript, <sub> - subscript
  • <blockquote>...</blockquote>For  highlight citation, use the tag <blockquote>
  • <code lang="lang">...</code>highlighting the program code (supported by bash, cpp, cs, css, xml, html, java, javascript, lisp, lua, php, perl, python, ruby, sql, scala, text)
  • <a href="http://...">...</a>link, specify the desired Internet address in the href attribute
  • <img src="http://..." alt="text" />specify the full path of image in the src attribute