How browsers find a direct route
WebRTC—short for Web Real-Time Communication—lets a browser exchange live audio, video, and other data with another browser. The trick is that the two devices usually begin behind routers or firewalls, which hide their direct network addresses. Before media can flow, they have to discover a route they can both use.
A website’s signaling service helps the browsers exchange setup details, such as network addresses and connection options. Signaling coordinates the introduction; it does not have to carry the conversation itself. The browsers then test possible routes, often using STUN, a protocol that helps a device learn the public address its router presents to the internet.
When a relay is needed
A direct route is not always possible. Some routers and corporate networks block the traffic or address combinations WebRTC needs. In that case, the browsers can send their media through a TURN relay: a server that receives packets from one device and forwards them to the other.
That fallback keeps a call working across difficult networks, but it adds a server to the path and can increase bandwidth costs and delay. WebRTC therefore does not guarantee a server-free call; it tries a direct connection when network conditions allow and relies on a relay when they do not.
Why the route matters
With a direct connection, media does not need to detour through a central media server, which can shorten the journey between participants. WebRTC also encrypts media in transit. The practical result is a call whose route can adapt to the network: direct when feasible, relayed when necessary.
