Elements video streaming is based on Web Real-Time Communication (WebRTC) technology. WebRTC makes peer-to-peer (P2P) communication possible without having a server in the middle. However, different network configurations (such as NAT [Network Address Translation] and firewall) can make P2P communication impossible. Common reasons why a direct connection could fail are firewalls that restrict UDP traffic on specified ports:

  • Port 3478 - Protocol: STUN, TURN UDP
  • Port 443 - Protocol: TURN TLS
  • Ports range 10000 - 60000 - Protocol: UDP/SRTP/SRTC

Network Address Translation

Non BEHAVE-compliant NATs (where it is not possible to traverse the NAT using standardized methods) can also be a reason why P2P communication is not possible.

BEHAVE-compliant NATs meet requirements defined in RFC 4787 and RFC 5382. BEHAVE is a set of guidelines for NAT devices to improve their behavior in the context of WebRTC and other P2P applications.

Here's how BEHAVE compliance benefits WebRTC:

  • Endpoint-independent Filtering: BEHAVE-compliant NATs should ideally use endpoint-independent filtering. This means they filter traffic based on the protocol and port combination, rather than a combination of IP address and port. This is crucial for WebRTC because it allows peers behind different NATs to communicate more easily, even if they have dynamically assigned private IP addresses.
  • Address and Port Preservation: BEHAVE-compliant NATs should try their best to preserve the source port used in the initial connection request from a client behind the NAT. This ensures the response can be routed back correctly, improving the chances of a successful connection.
  • Mapping Consistency: Ideally, a BEHAVE-compliant NAT should map outgoing requests from a specific application (like WebRTC) to a consistent set of external IP addresses and ports. This consistency helps peers behind different NATs discover each other more efficiently.

Benefits of BEHAVE compliance:

  • Improved P2P connectivity: By following these guidelines, NATs can create a more P2P-friendly environment, allowing WebRTC applications to establish direct connections between browsers more often. This translates to potentially lower latency and better quality for real-time communication.
  • Reduced reliance on relay servers: With more successful P2P connections, the need for relay servers (TURN servers) is minimized. This helps avoid the additional latency that relay servers can introduce.
  • Enhanced WebRTC functionality: BEHAVE compliance fosters a smoother WebRTC experience by enabling features that rely on direct P2P connections, such as data channel communication for file sharing or collaborative editing.

Not all NATs are BEHAVE-compliant. Unfortunately, many NAT devices, especially older ones, may not fully adhere to BEHAVE guidelines. This can lead to difficulties in establishing P2P connections for WebRTC and other P2P applications.

In conclusion, BEHAVE compliance is a set of recommendations for NAT devices to improve their handling of WebRTC and P2P traffic. By following these guidelines, NATs can contribute to a more efficient and reliable WebRTC experience.

Differentiate NAT Types Based on their Behaviors

Different NAT types can impact WebRTC connectivity in varying degrees, affecting the ability to establish a direct peer-to-peer connection. Here's a breakdown:

  • Public NAT:
    • Behavior: The most WebRTC-friendly type. It maps private addresses behind the NAT to a single public IP address consistently. WebRTC can easily use this public IP to connect directly with the other peer.
    • Impact on WebRTC: Offers the smoothest experience. Direct peer-to-peer connections are most likely to be established, leading to lower latency.
  • Private NAT:
    • Behavior: More restrictive than Public NAT. It maps private addresses to different public IP addresses depending on the destination. While connections might still be possible, it can make ICE candidate gathering less efficient as multiple attempts with different public IPs might be needed.
    • Impact on WebRTC: May require more attempts to find a compatible connection due to dynamic IP mapping. While still possible to achieve P2P connection, it might take slightly longer.
  • Symmetric NAT:
    • Behavior: The most challenging for WebRTC. It not only maps private addresses dynamically but also restricts incoming connections to ports that were previously used for outgoing connections. This makes it difficult for the other peer to initiate a connection back, potentially requiring a relay server (TURN server) to facilitate communication.
    • Impact on WebRTC: Significantly increases the difficulty of establishing a direct connection. WebRTC will likely rely on a TURN server to relay data, which introduce additional latency.

Reflection NAT and Hairpin NAT are specific types of NATs that can introduce additional challenges for WebRTC connectivity, even compared to other restrictive NAT types like Symmetric NAT. Here's a breakdown of their impact:

  • Reflection NAT:
    • Behavior: Unlike standard NATs that translate private IP addresses to a public IP, Reflection NAT translates private addresses to a private IP address of another device on the network (typically a router). This private IP is then reflected back out to the public internet with a different public IP address.
    • Impact on WebRTC: WebRTC relies on sending data directly between peers using their public IP addresses. With Reflection NAT, the public IP address seen by the internet is different from the reflected address used internally. This mismatch confuses ICE candidate gathering, making it difficult for peers to discover each other's true location and potentially requiring a TURN server even for connections within the same local network.
  • Hairpin NAT:
    • Behavior: Hairpin NAT is a type of NAT configuration where a device behind the NAT attempts to connect to another device that also resides behind the same NAT. The NAT translates the outgoing connection to a public IP and then routes it back internally to the destination device's private IP.
    • Impact on WebRTC: Hairpin NAT can cause issues similar to Reflection NAT. The WebRTC connection attempt from one device behind the NAT goes out to the public internet, gets translated by the NAT, and then comes back in through the same NAT. This loop can confuse ICE candidates and hinder peer discovery. A TURN server might be necessary even for local connections.

Additional Considerations:

  • Both Reflection NAT and Hairpin NAT can significantly increase the complexity of WebRTC peer connections.

  • These NAT configurations are not very common in typical home user setups, but they are often encountered in some enterprise or mobile carrier networks.

In conclusion, the type of NAT you have behind your network can affect the ease and efficiency of WebRTC connections. Public NAT offers the best scenario, while Symmetric NAT might require a TURN server for reliable communication, potentially impacting performance. While not as common as Symmetric NAT, Reflection NAT and Hairpin NAT can pose unique challenges for WebRTC due to their internal address manipulation. Understanding these NAT types can help diagnose connectivity issues and explore potential solutions for smoother WebRTC experiences.

Network Interface Configuration

WebRTC prioritizes establishing direct P2P connections for efficiency. The network interface used does not directly affect this process as long as it has internet access. While the number of network interfaces itself usually has minimal impact on WebRTC connectivity, it can indirectly influence the likelihood of achieving a peer-to-peer (P2P) connection compared to a relay connection in some situations. Potential impact includes:

  • Interface Prioritization: If you have multiple network interfaces with different firewalls or security settings, the interface chosen by the WebRTC application could affect its ability to establish a direct P2P connection. A more restrictive interface might hinder P2P by blocking necessary ports or protocols.
  • Routing and Firewalls: In complex network configurations with multiple interfaces, routers, and firewalls, the routing rules might prioritize specific interfaces for certain types of traffic. This could potentially affect how WebRTC traffic is routed, impacting the feasibility of a P2P connection if the chosen path does not allow direct communication.
  • Virtual Interfaces: Virtual network interfaces created by VPNs or other tools can introduce an additional layer. WebRTC might need to be directed to the virtual interface representing the desired internet connection with appropriate firewall rules to facilitate P2P communication.

Relay vs. P2P Impact:

  • Limited Interfaces (P2P Benefit): If you have only one network interface with a permissive firewall, it is more likely to establish a successful P2P connection as there is no ambiguity about the internet path.
  • Multiple Interfaces with Restrictions (Relay Risk): With multiple interfaces, especially if some have stricter firewalls or routing rules, WebRTC might struggle to find a suitable path for a P2P connection. In such cases, it might resort to a relay server (TURN server) to facilitate communication, even if a direct P2P connection might be possible on another interface.

Overall:

Multiple network interfaces can indirectly impact P2P vs. relay connectivity by influencing the available paths and firewall restrictions. However, the impact is usually secondary. The primary factors affecting P2P success are still NAT type, firewalls on the overall network, and the capabilities of the other peer.

Recommendations:

  • Ensure the WebRTC application is using the network interface with the most permissive firewall settings and direct internet access.
  • If you suspect routing or firewall issues, consult your network administrator for configuration assistance.




© Honeywell International Inc. All Rights Reserved.