I am back with another webRTC tutorial post . Today i am going to talk about the advanced area of webRTC technology . That is webRTC’s environment and it’s protocols . This is one of the important section of the webRTC technology . If your going to develop a webRTC project or apps you must know about it’s architecture as well as it’s protocols .
Anyway if your new to this technology series please go through
WebRTC introduction : Introduction to the browser technology
getusermedia API : browser getusermedia API
RTCPeerconnection API : browser RTCPeerconnection API
Lets move to the discussion
WebRTC technology allows you to send video and audio data through browser client with out need any media server . Although we should understand about some another server that helps to support webRTC to achieve it’s feature . These are the some of them which helps to setup webRTC technology .
Signaling server
Lets assume we have two clients and they want to talk each other , send video data etc . Where should i start ? how i know about the other client ? I don’t have any idea about the other user . To achieve this webRTC uses signalling server ie. Signaling server helps to identify and collect sharing information about the other user . It will act as a bridge between the users and also responsible for the handshaking process . You can get more idea from this post signaling process and it’s importance in communication .
STUN Server
So with the help of a signaling server we can contact other user . Just imagine in real situation with each client has it’s own IP address and network parameters . The peer connection will travel through your router and finally goes to internet . Isn’t ? So how your router know about the external address of the clients ?
When it goes to the internet , peers can be hide hidden behind NAT and do not have any information about the external address . STUN server helps to achieve the solution of the NAT problem . STUN server will detect the peers public network address and it establish peer-to-peer connection behind a NAT.
The client will send a request to a STUN server on the Internet who will reply with the client’s public address and whether or not the client is accessible behind the router’s NAT. I will discuss about NAT in coming WebRTC protocols section of this post .
TURN server
Next there is another problem will arise between the peer-to-peer connection . That is firewall . Firewall can be placed anywhere in the network . It will cut down the direct communication between the webRTC traffic . If there is no peer-to-peer connection is not available using STUN server , TURN server will setup a public address to the clients and it will transmit the webRTC traffic .
WebRTC Protocols
Next let us look the protocols on top of which the webRTC API built . These are main protocols used in webRTC technology
- ICE ( Interactive connectivity Establishment )
- STUN ( Session traversal utilities for NAT )
- NAT ( Network Address Translation )
- TURN ( Traversal using Relays around NAT )
- SDP ( Session Description protocols )
We already discussed about STUN , TURN . Now lets move to other protocols
ICE ( Interactive connectivity Establishment )
This is a framework which help you to make your browser communicate with peer connection . If your writing a webRTC application with out having any other supporting protocols then it can not contact the peer user . It’s doesn’t have any public address . So to achieve this goal , ICE helps to setup all other components of the WebRTC with following protocols .It includes NAT,STUN and TURN .
NAT ( Network Address Translation )
We already said about STUN in above section of this post . Briefly , STUN is a protocol to discover your public address and client will send request to STUN server and it will reply with public address whether or not the client is accessible behind the router’s NAT .
NAT is used to give your device a public address . We know every router has it’s own public address and every connected device in that router has it’s own private address . So the request is from your device private address to the router public address though a unique port . Now that way you don’t need a unique public address for each device but that can be accessible over internet too .
In some time routers , we can not create a connection though STUN server . In this situation we can create connection with the help of TURN server .
SDP ( Session Description protocols )
SDP is a standard which have common multimedia standard to understand the different content of connection such as resolution, codec, encryption , format etc . Both peers can be understand the data .
Conclusion
I think you have understood about the core part of webRTC though this post . This webRTC protocol knowledge is must needed to develop a standard webRTC application . In coming post you can see the next advanced tutorials of webRTC .
If this post is useful and informative, don’t forget to share our post or recommend this post to your friends
Recommended Posts
Leave a Reply