Unverified Commit 6405c743 authored by popi's avatar popi

typos

parent b4e72dc1
Pipeline #39 failed with stages
......@@ -4,17 +4,17 @@
### Forewords
This little development was made for WebRTC end-nodes to be able to communicate through a **symmetrical NAT** activated LAN router.
This project can been seen as the last step to cover as widely as possible successful establishment of video-communication between two end nodes/ Web browsers running [JSXC](https://www.jsxc.org/) on a [SOGo v3](https://sogo.nu/) Website (using WebRTC).
This little development was made for WebRTC end-nodes to be able to communicate through a **symmetrical NAT** LAN router.
This project can be seen as the last step to cover as widely as possible successful establishment of video-communication between two end nodes/ Web browsers running [JSXC](https://www.jsxc.org/) on a [SOGo v3](https://sogo.nu/) Website (using WebRTC).
WebRTC (Web Real-Time Communication) is a collection of communications protocols and application programming interfaces that enable real-time communication over peer-to-peer connections. -- **Wikipedia**
Being peer-to-peer and only browser-dependant (meaning no other software required) makes it incredibly attractive.
The **ICE protocol** was create as a way to enable listing several methods to successfully try to establish connectivity between two end nodes.
The **ICE protocol** was created as a way to enable listing several methods to successfully try to establish connectivity between two end nodes.
In most of the situation a STUN server will be used first for nodes behind NAT to be able to gather enough info before starting peer-to-peer connection.
The peer-to-peer communication is **not always possible** if you are within a LAN using **symmetrical NAT**. A router with symmetrical NAT activated maintains its NAT table in such a way that ports used to connect outside are not the same number the client node opened asked for, the router randomly opens a different port and keep the mapping in its NAT table, making it impossible for the remote node to enable a direct peer-to-peer connection).
The peer-to-peer communication is **not always possible** if you are inside a LAN using **symmetrical NAT**. A router with symmetrical NAT activated maintains its NAT table in such a way that ports used to connect outside are different from the one used to connect back to the client. The router randomly opens a different port and keep the mapping in its NAT table, making it impossible for the remote node to enable a direct peer-to-peer connection).
This is where [coturn's TURN/STUN server](https://github.com/coturn/coturn) comes to the rescue.
A **TURN** server is what it says : Traversal Using Relays around NAT. It is the only way to manage WebRTC connection through the NAT. The TURN server is in charge of relaying each and every packets between the two nodes (goodbye peer-to-peer and hello overhead on TURN server, but IT WORKS).
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment