WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.
Basically, it is intended for applications with peer-to-peer architecture and video and audio streaming.
As well as audio and video, WebRTC supports real-time communication for other types of data.
The RTCDataChannel API enables a peer-to-peer exchange of arbitrary data, with low latency and high throughput.
It can use reliable (TCP) or unreliable (UDP) messages.
Components diagrams (infrastructure):
There are the following components:
- Signaling server. Signaling is the process of coordinating communication. This signaling process needs a way for clients to pass messages back and forth. That mechanism is not implemented by the WebRTC APIs: you need to build it yourself. (see more https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling);
- ICE technique. WebRTC apps can use the ICE framework to overcome the complexities of real-world networking. To enable this to happen, your application must pass ICE server URLs to RTCPeerConnection. ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card; if that fails (which it will for devices behind NATs) ICE obtains an external address using a STUN server, and if that fails, traffic is routed via a TURN relay server. (see more https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#after-signaling-using-ice-to-cope-with-nats-and-firewalls);
- A STUN server is used to get an external network address;
- TURN servers are used to relay traffic if direct (peer to peer) connection fails.
Minuses of using WebRTC for our goals:
- Basically, it is intended for applications with P2P architecture and video and audio streaming. Not for server and clients communications;
- IE and Safari don't support it protocol out of the box.
- Too complex deployment architecture. You need to set up a signal, STUN, TURN servers and other quite kind of complex infrastructure. It will take the additional cost from you;
- You don’t have out of the box library for .NET, for example (There are some repos in GitHub, but it does not look as very popular and often used). Although, you have ORTC (https://ortc.org/);
- You will need to develop and maintain own connection state manager on the server. If you want to detect online and offline users, and to catch the client's endpoints (IP, port);
- I have experience of using WebRTC in one of my projects. It is used for calling not more than two users. Some feedback about WebRTC:
- We raised for this three separate servers (signal server which hosts NodeJS application SimpleWebRTC https://github.com/andyet/SimpleWebRTC), TURN and STUN servers which ran in Azure via “Free open source implementation of TURN and STUN Server” project Coturn (https://github.com/coturn/coturn);
- On the client we use signalmaster framework (https://github.com/andyet/signalmaster);
- Video communication does not work well with bad internet;
- Customers have them on the IOS and Android. There are reviews that the application consumes the battery very much.
Some conclusion
You should consider using WebRTC only if:
- You have a goal to get rid of the 3rd party products that provide us with video/audio streaming and communication.
- You want to use it for its intended purpose (for peer-to-peer communications). In this case, you need to design the architecture specifically for these features or write a stand-alone unit, like now VUDYO.
If you will use WebRTC for just push notifications from the server to clients, it will be like a shot from a cannon on sparrows.
No comments:
Post a Comment