Signal Server Deployment

WebRTC infrastructure: placement strategies, ICE configuration, and URL adaptation for LAN, WAN, and cloud environments.

A well-planned signaling server deployment is essential for WebRTC connections to succeed across different network topologies. The signaling server coordinates media negotiation and session control, and its placement—along with the configuration of ICE servers (STUN/TURN)—directly impacts whether browsers and PortableRTC devices can establish a stable connection. This article covers deployment strategies for Local Area Network (LAN) and Wide Area Network (WAN) environments, provides practical TURN server setup examples, and explains how to construct the correct client‑side URLs.

1. LAN Environment

When both the browser PC and the PortableRTC device reside on the same local network, the deployment approach depends on whether they can communicate directly.

1.1 Devices Can Reach Each Other

If the two endpoints can communicate via private IP addresses (e.g., ping or port connectivity is open), the signaling server can be kept very simple:

  • Deployment method: Co‑locate the signaling server with the PortableRTC device, or use a version of PortableRTC that embeds the signaling server functionality.
  • ICE configuration: No STUN or TURN addresses are required because both parties are in the same broadcast domain.
  • Accessing the WebRTC stream: Use the URL printed directly in the PortableRTC console.
http://192.168.3.168:8000/webrtc?streamid=myapp/test.mp4

1.2 Devices Cannot Reach Each Other

Even on the same LAN, firewalls or VLANs may block direct communication. In this case, a separate signaling server is needed as an intermediary:

  • Deployment method: Deploy the signaling server on a machine that both the browser PC and the PortableRTC device can access (e.g., a third server on the same LAN).
  • ICE configuration: STUN or TURN addresses are required to assist with connection establishment or to relay media.
  • Accessing the WebRTC stream: Replace the IP and port in the original console URL with the signaling server’s <http_server_ip> and <http_port>.

Replacement rule
Original URL from PortableRTC console:

http://192.168.3.168:8000/webrtc?streamid=myapp/test.mp4

If the signaling server is at 192.168.1.100:8000, the new URL becomes:

http://192.168.1.100:8000/webrtc?streamid=myapp/test.mp4

For HTTPS, use the signaling server’s <https_server_ip> and <https_port> accordingly.

2. WAN Environment

When the browser and the PortableRTC device are in different private networks (e.g., one at home, one in the cloud), they must communicate over the public internet. The signaling server must be placed on a publicly reachable address.

2.1 Basic Deployment Requirements

  • Signaling server location: Deploy on a server with a public IP, or ensure NAT mappings allow both parties to reach it.
  • ICE configuration: Configure both STUN and TURN. STUN attempts to establish a direct P2P path; TURN acts as a fallback relay when P2P fails (e.g., with symmetric NAT).
  • Accessing the WebRTC stream: Replace the original PortableRTC URL with the signaling server’s public address.

Replacement example
Original URL:

http://192.168.3.168:8000/webrtc?streamid=myapp/test.mp4

Signaling server public IP and port: 115.180.x.x:8000
New URL:

http://115.180.x.x:8000/webrtc?streamid=myapp/test.mp4

For HTTPS, use the HTTPS address.

2.2 Cloud Server Considerations

Cloud instances (e.g., Alibaba Cloud, AWS) typically have only a private IP visible inside the instance. To make the signaling server reachable:

  • Configure the signaling server with a <wan_ip> setting that matches the cloud server’s elastic public IP.
  • This ensures SDP candidates contain the correct public address.
  • When constructing the client URL, use the same public IP.

3. TURN Server Configuration

The coturn project is widely used for TURN/STUN functionality. Below are two ways to start it.

3.1 Command Line

turnserver -a -u test:123456 -r domainname
  • -a: Enable long‑term credential mechanism.
  • -u: User account in username:password format.
  • -r: Realm name (required with long‑term credentials).

3.2 Configuration File

Edit turnserver.conf with these minimum settings:

lt-cred-mech
user=test:123456
realm=domainname

Then start:

turnserver -c turnserver.conf

4. Example ICE Configuration for the Signaling Server

In the signaling server’s configuration, add the TURN/STUN addresses under <ice_servers>:

<ice_servers>
    <url>stun:192.168.1.100:3478</url>
    <url>turn:test:123456@192.168.1.100:3478</url>
</ice_servers>
  • STUN address: stun:192.168.1.100:3478
  • TURN address: turn:test:123456@192.168.1.100:3478

If the TURN server is on the public internet, replace the IP with its public address and ensure firewall rules allow traffic on port 3478 (TCP/UDP).

Summary

Network environment Signaling server location ICE configuration URL replacement requirement
LAN (mutual reachability) Co‑located with PortableRTC Not needed Use original console URL
LAN (isolated) Separate server, reachable by both parties STUN/TURN required Replace with signaling server address
WAN (different private networks) Public IP server STUN+TURN recommended Replace with signaling server public IP
Cloud server Public IP (configure <wan_ip>) STUN+TURN recommended Replace with cloud server public IP

Conclusion

Deploying the signaling server correctly—and pairing it with the right ICE configuration—is fundamental to WebRTC connectivity. In LAN environments, the choice between a co‑located or separate signaling server depends on whether endpoints can communicate directly. In WAN and cloud scenarios, a publicly reachable signaling server with both STUN and TURN ensures maximum compatibility across different NAT types. By following the guidelines above and using the provided TURN setup examples, you can build a robust signaling layer that works reliably across diverse network topologies.