• about reply
NET Reply UK Logo
Menu
  • About us
    About us
    • How we work
    • Our Leadership Team
  • Competences
    Competences
    • Networks
    • Future Networks
    • Security
  • Newsroom
  • Careers
  • Contact Us
    • about Reply
    NET Reply UK Logo
    Focus On

    Blog

    WebRTC Demystified for Devs

    FOCUS ON: Development, DevOps,

    What is WebRTC?

    Web Real Time Communication

    WebRTC provides a feature rich framework for developers that makes it easy to build applications for browsers to communicate in real time. It provides the fundamental building blocks to transmit audio, video and text from client to client.

    When being implemented in a browser these components will be accessed through JavaScript API’s. Making the developers job a lot simpler.

    Other programming languages will also have their own implementations of WebRTC. This means that we can have a C++ or Go client interacting with a user’s web browser, or even two Go clients (or any programming language that has a WebRTC implementation) communicating with each other in real time.

    I love Go and have recently been using Go Pion, which is a pure Go implementation of the WebRTC API.


    Why use WebRTC?

    Peer to Peer connections, cancelling out the middleman reduces latency.

    One advantage is that WebRTC doesn’t require the user to download anything third party, it will just work in the browser without having to install an application.

    Connections are peer-to-peer, traffic doesn’t need to go through a central server. Reducing the middleman here saves time so ultra-low latency can be achieved.

    Some ambitious projects are possible thanks to WebRTC, such as:

    • PiePacker
    • Stadia Google

    Some concepts to understand before building a WebRTC application include:

    NAT

    Today nearly everyone will be sitting behind Network Address Translation. Simply meaning that your machines public IP address is not available to the outside world, instead your routers IP address will be visible and manage the traffic.


    NAT in Action

    Machine 10.0.0.2 wants to make a connection to machine 4.4.4.4:80.
    In order to do this the machine will try to make a connection request.

    Thomas_Picture_1.png 0
    1. Machine 10.0.0.2 makes a request to the end machine.
    2. The end machine is not in the subnet so the request must be given to the router so that this can reach the outside world. The router will not expose the machines' IP address and instead will assign its public IP address.
    3. Information is stored in a NAT table, so that when the end point machine responds it knows where to direct this request back to the machine's IP address.
    4. The router will then try to make the connection to the machine on the outside world.
    5. The end machine receives the request and then directs it back, using the same steps but in reverse order.

    NAT Translation methods

    There are four different types of translation methods, and each routers implementation will slightly vary. It is important to understand different translation methods so that we understand why we are implementing certain functionality into our WebRTC application.


    One to One Nat (Full Cone NAT)

    Packets on the external IP:Port on the router always maps to the internal IP:Port without exceptions.

    Thomas_Picture_2.png 1

    This means that the router does not check where the external packet has come from, it will always accept the incoming packet. For example, if we had these incoming packets, all would be allowed to pass. This is because the external IP and port match the ones in the table. It doesn’t matter where they are going internally.

    Thomas_Picture_3.png 2


    Address Restricted NAT

    Packets to the external IP:Port on the router always map to internal IP:Port as long as the source address from the packet matches the table (regardless of port.)

    Allow if we have communicated with the host before.Thomas_Picture_4.png 3

    This means that it will only allow packets that are going to the specified destination port.
    Thomas_Picture_5.png 4

    Only the first packet here would be accepted because the destination IP matches which is specified.


    Port Restricted NAT

    Restrictions on the IP address and the port.Thomas_Picture_6.png 5

    Once again only the first packet would be allowed through. The destination port and destination IP are matching.Thomas_Picture_7.png 6


    Symmetric NAT

    This is by far the strictest implementation of NAT.
    This is very similar to Port Restricted NAT, but the table must be completely symmetrical.Thomas_Picture_8.png 7

    If a connection is behind symmetric NAT, then a peer-to-peer connection is not possible, and a TURN server must be used in order to bypass this.


    STUN

    Session Traversal Utilities for NAT.
    STUN Servers are used so that clients have the information they need to be able to setup a peer-to-peer connection. It is important to note that STUN will not work for symmetric NAT.

    This includes the client knowing their public IP address and Port, and the type of NAT they are behind.


    STUN In Action

    Thomas_Picture_9.png 8
    1. Create a packet that goes to the stun server, this will go to the router to do some NAT
    2. Router will not allow the packet to be naked and does not expose the machine's IP so, the router will use its public IP.
    3. Router will store this information in a table, so it knows where to return the response to.
    4. Packet makes its way to the stun server.

    Once the packet arrives at the STUN server:Thomas_Picture_10.png 9

    1. The stun server will put the IP address in a packet.
    2. Packet goes back to the router.
    3. Router looks up where the packet needs to go.
    4. Packet goes to the user's machine with the given information.

    STUN – When it works

    Thomas_Picture_11.png 10

    This green arrow would be the shortest path to the peer. This would ensure no latency. There is no middleman involved in WebRTC, as a result this process is much faster and offers much lower latency.

    There isn’t a vast amount functionality, so STUN servers are very cheap to run. They are so cheap to run that Google and other providers have public STUN servers that are free to use.

    Recall that this type of communication is not possible if client is behind symmetric NAT. If this is the case, there is an alternative that can be used.


    TURN

    Traversal Using Relays around NAT.
    In the case of Symmetric NAT, then we use TURN.
    This is a server that relays packets. In the case of TURN then a middleman must be used, TURN is not desirable because it would add latency. However, in some cases this must be used.Thomas_Picture_12.png 11TURN servers are more expensive to maintain so I think it would be unlikely that providers would give them away for free. XIRSYS does provide a free TURN server for a basic developer account which is good for a personal project, it is very simple to setup and doesn’t require a credit/debit card. However, production TURN servers will cost you.


    ICE

    With STUN and TURN both available, how do we know which option to pick?
    This requires Interactive Connectivity Establishment.
    ICE Collects all available candidates such as:

    • Local IP’s
    • STUN Addresses
    • TURN Addresses

    These are all known as ICE candidates.
    All the collected addresses are then sent to the remote peer via SDP.


    SDP

    So, what is SDP?
    The almighty Session Description Protocol, this is arguably the most important part of WebRTC.
    This is a format that describes:

    • Ice Candidates
    • Networking Options
    • Media Options
    • Security Options
    • Other Information

    There is a lot of information that is included in the SDP.
    The goal is to take a user generated SDP and send it to the other party. The other party will also need to generate its own SDP and send it back to the initial user to establish the peer-to-peer connection.

    It is even possible to add your own custom information to the protocol. Check out this interesting article from Discord blog.


    Example SDP StringThomas_Picture_13.png 12


    SDP Signalling

    Signalling is the process of sending the user generated SDP to the other party that we wish to communicate with. I will not cover the details of how to build a signalling server because this blogpost is already becoming lengthy enough.

    Signalling can be done several ways, but the best approach is to use a WebSocket to exchange the two SDP.


    JavaScript Code Walkthrough

    This example can be followed in the browser’s web console, which makes it easy and quick to follow.The goal of this example is to connect two browsers so that we can send messages to each other via WebRTC.
    Peer A will create an offer, which is an SDP. Peer A will set its local description to the offer it has generated.
    Peer B will receive the offer created by Peer A and Peer B will use this offer to set its remote description.
    Peer B will create an answer (which is just another SDP). The answer will become Peer B’s local description.
    It will signal this answer to Peer A, and then Peer A will use set its remote description to Peer B’s answer.

    Peer A Code
    This code can be typed in line by line in the web console.Thomas_Picture_14.png 13

    Once these steps have been completed the console should print a JSON structure which includes key values for type and SDP.

    Peer B Code
    Now that Peer A has created an offer, we need this peer to use the offer. For this example, we will just copy and paste the offer however I wouldn’t recommend this approach in production for obvious reasons.

    The offer that is printed in the console will be longer than the offer I have set in the example code. This is just to make the code readable.Thomas_Picture_15.png 14

    The console should print a JSON object with a key and value for type and answer.

    The connection is not quite established yet. We need to set the remote description in Peer A with the answer that has just been generated.

    Peer AThomas_Picture_16.png 15

    Both consoles should print a message stating a connection has been established.
    You can send messages between the peers using the function.Thomas_Picture_17.png 16


    Contact Details

    If you would like any more information on WebRTC, please get in touch with our Future Networks Consultant !

    RELATED CONTENTS

    16.08.2021 / Cloud Automation

    Blog

    Automated 5G Infrastructure deployment: in practice

    In the previous article, we have discussed the theory of DevOps and Infrastructure as Code. It's now time to dig into the practical concepts of these topics and see actual results from a CI/CD pipeline that runs Terraform and deploys the infrastructure for a Kubernetes cluster that can host a 5G networking solution.

    10.08.2021 / Cloud Automation

    Blog

    Automated 5G Infrastructure deployment : the theory

    In this 2-part blog, we are using open-source technologies such as Terraform, Docker and Kubernetes to automatically deploy an infrastructure to AWS using GitlabCI. This blog will cover the concepts and technologies necessary in order to achieve this goal. More specifically, we will explain DevOps, CI/CD and Infrastructure as Code (IaC).

     
     
     ​
     
    Reply ©​​ 2023​ - Company Information -
     PrivacyCookie Settings ​
    • About Reply​
    • Inves​tors​​​
    • Newsroom
    • Follow us on
    • ​
    ​
    • ​Privacy & Cookies Policy
    • Information (Client)
    • Information (Supplier)
    • Information (Candidate)
    • Modern Slavery Act Tran​sparency Statement (UK & IR)​
    ​​Reply Enterprise Social Network​