Network and WebRTC Configuration

Overview

Network configuration controls signaling server connections, matchmaker registration, ICE/TURN server setup for NAT traversal, and keepalive settings.

Client Configuration

Browser client connection endpoints.

string

required

WebSocket URL for the signaling server.Default: wss://signaling-server-production-acd4.up.railway.appMust use wss:// for secure WebSocket in production.Examples:

Development: ws://localhost:3002
Production: wss://signaling.example.com

Always use wss:// (secure WebSocket) in production to avoid security warnings and blocked connections.

string

required

HTTP(S) URL for the matchmaker service.Default: https://matchmaker-production-5b36.up.railway.appMatchmaker assigns clients to available hosts.Examples:

Development: http://localhost:3000
Production: https://matchmaker.example.com

Host Signaling

string

required

WebSocket URL for host-to-signaling-server connection.Default: wss://signaling-server-production-acd4.up.railway.appShould match client.serverUrlBase to ensure hosts and clients connect to the same signaling server.

Matchmaker Configuration

The matchmaker service manages host registration and client-to-host assignment.

string

required

HTTP(S) URL for matchmaker endpoint.Default: https://matchmaker-production-5b36.up.railway.appHost registers itself with this service and maintains keepalive.

string

required

Shared secret for host authentication.Default: HELLO-MFSUsed to authenticate host registration requests.

Change this to a secure random value in production! The default is for development only.

Generate a secure secret:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

integer

default:"20000"

Host keepalive interval in milliseconds.Default: 20000 (20 seconds)Host sends periodic heartbeats to matchmaker to indicate availability.Recommended:

10000-20000 - Standard (default)
5000-10000 - Fast failover (higher network traffic)
30000-60000 - Low traffic (slower failover)

Set to 2-3x your expected network latency for stable connections.

ICE and TURN Configuration

ICE (Interactive Connectivity Establishment) and TURN (Traversal Using Relays around NAT) enable WebRTC connections through firewalls and NAT.

Default Behavior

The CloudGaming host uses default ICE servers configured in the Pion WebRTC library. For most local networks and direct connections, this is sufficient.

Custom ICE/TURN Servers

For production deployments or restrictive networks, configure custom TURN servers in your WebRTC connection code. Client-side ICE configuration (JavaScript):

const iceServers = [
  { urls: 'stun:stun.l.google.com:19302' },
  {
    urls: 'turn:turn.example.com:3478',
    username: 'user',
    credential: 'pass'
  }
];

const pc = new RTCPeerConnection({
  iceServers: iceServers
});

Host-side configuration requires modifying the Go code in gortc_main/ to add custom ICE servers to the Pion WebRTC configuration.

Public STUN Servers

Free STUN servers for NAT traversal (no relay):

stun:stun.l.google.com:19302 (Google)
stun:stun1.l.google.com:19302
stun:stun.cloudflare.com:3478 (Cloudflare)

TURN Server Setup

For reliable connections through restrictive NATs, deploy your own TURN server: Using Coturn:

# Install
sudo apt-get install coturn

# Configure /etc/turnserver.conf
listening-port=3478
fingerprint
lt-cred-mech
user=myuser:mypassword
realm=turn.example.com

# Start
sudo systemctl start coturn

Deploy TURN servers geographically close to your users for best performance.

Redis Configuration (Signaling Server)

The signaling server uses Redis for pub/sub and multi-node scaling. Configure Redis connection in the signaling server deployment. Environment variables for signaling server:

REDIS_HOST=localhost
REDIS_PORT=6379
REDIS_PASSWORD=your_secure_password

Always use Redis authentication (requirepass) in production deployments.

Network Architecture

Connection Flow

Client → Matchmaker: Request available host
Matchmaker → Client: Return host ID
Client → Signaling: Connect via WebSocket
Client ↔ Host: Exchange SDP/ICE through signaling
Client ↔ Host: Establish direct WebRTC P2P connection
Client ↔ Host: Stream video/audio, receive input

Components

┌─────────┐          ┌────────────┐          ┌──────┐
│ Client  │ ◄─────── │ Signaling  │ ◄─────── │ Host │
│(Browser)│   WSS    │   Server   │   WSS    │ (C++) │
└─────────┘          └────────────┘          └──────┘
     │                     │                     │
     │                     ▼                     │
     │               ┌──────────┐                │
     └─────────────► │  Redis   │ ◄──────────────┘
          HTTP       │ Pub/Sub  │       HTTP
                     └──────────┘
     │                                           │
     │               ┌────────────┐              │
     └─────────────► │ Matchmaker │ ◄────────────┘
          HTTP       │  Service   │      HTTP
                     └────────────┘
     │                                           │
     └───────────────────────────────────────────┘
                    WebRTC P2P
              (video, audio, input)

Firewall and Port Configuration

Required Ports

Service	Protocol	Port	Direction
Signaling Server	WSS	3002 (or custom)	Inbound
Matchmaker	HTTPS	3000 (or custom)	Inbound
STUN	UDP	3478	Bidirectional
TURN	UDP/TCP	3478	Bidirectional
WebRTC Media	UDP	10000-65535	Bidirectional

Firewall Rules (Host)

Allow outbound connections:

WSS to signaling server
HTTPS to matchmaker
UDP for WebRTC media

# Example iptables (Linux host)
iptables -A OUTPUT -p tcp --dport 3002 -j ACCEPT  # Signaling
iptables -A OUTPUT -p tcp --dport 3000 -j ACCEPT  # Matchmaker
iptables -A OUTPUT -p udp --dport 3478 -j ACCEPT  # STUN/TURN
iptables -A OUTPUT -p udp -m udp --dport 10000:65535 -j ACCEPT  # WebRTC

WebRTC requires bidirectional UDP traffic. Highly restrictive firewalls may block P2P connections, requiring TURN relay.

Production Deployment Checklist

Use secure protocols (wss://, https://) for all endpoints

Change hostSecret to a cryptographically secure random value

Deploy Redis with authentication enabled

Configure TURN servers for NAT traversal

Set up SSL/TLS certificates for signaling and matchmaker

Configure firewall rules to allow required ports

Set appropriate heartbeatIntervalMs for your network

Test connections from restrictive networks (corporate, mobile)

Example Configurations

Local Development

{
  "client": {
    "serverUrlBase": "ws://localhost:3002",
    "matchmakerUrl": "http://localhost:3000"
  },
  "host": {
    "signalingUrl": "ws://localhost:3002",
    "matchmaker": {
      "url": "http://localhost:3000",
      "hostSecret": "dev-secret-123",
      "heartbeatIntervalMs": 25000
    }
  }
}

Production Deployment

{
  "client": {
    "serverUrlBase": "wss://signaling.cloudgaming.example.com",
    "matchmakerUrl": "https://matchmaker.cloudgaming.example.com"
  },
  "host": {
    "signalingUrl": "wss://signaling.cloudgaming.example.com",
    "matchmaker": {
      "url": "https://matchmaker.cloudgaming.example.com",
      "hostSecret": "YOUR_SECURE_SECRET_HERE",
      "heartbeatIntervalMs": 20000
    }
  }
}

High-Availability Setup

{
  "client": {
    "serverUrlBase": "wss://signaling-lb.example.com",
    "matchmakerUrl": "https://matchmaker-lb.example.com"
  },
  "host": {
    "signalingUrl": "wss://signaling-lb.example.com",
    "matchmaker": {
      "url": "https://matchmaker-lb.example.com",
      "hostSecret": "YOUR_SECURE_SECRET_HERE",
      "heartbeatIntervalMs": 15000
    }
  }
}

Additional infrastructure:

Multiple signaling server instances behind load balancer
Redis cluster for high availability
Multiple matchmaker instances
Geographically distributed TURN servers

For high-availability deployments, use health checks on the load balancer and reduce heartbeatIntervalMs to 10-15 seconds for faster failover.

Troubleshooting

Cannot Connect to Signaling Server

Check:

Signaling server is running and accessible
WebSocket URL uses correct protocol (ws:// vs wss://)
Firewall allows outbound connections on signaling port
SSL certificate is valid (for wss://)

Host Not Appearing in Matchmaker

Check:

Matchmaker service is running
hostSecret matches on host and matchmaker
Host can reach matchmaker URL
Heartbeats are being sent (check logs)
Matchmaker Redis connection is working

WebRTC Connection Fails (ICE Failed)

Check:

STUN/TURN servers are reachable
UDP traffic is not blocked by firewall
NAT type is compatible (symmetric NAT requires TURN)
ICE candidate gathering completes successfully
Consider deploying TURN server for relay

High Latency

Check:

Network RTT between client and host
TURN relay is not being used (adds latency)
Signaling server geographic location
Client/host network quality

Intermittent Disconnections

Check:

heartbeatIntervalMs is appropriate for network latency
Redis pub/sub is stable
Load balancer timeout settings
Network stability (packet loss, jitter)

Getting Started

Deployment

Components

Configuration

Operations

Network and WebRTC Configuration

Overview

Client Configuration

Host Signaling

Matchmaker Configuration

ICE and TURN Configuration

Default Behavior

Custom ICE/TURN Servers

Public STUN Servers

TURN Server Setup

Redis Configuration (Signaling Server)

Network Architecture

Connection Flow

Components

Firewall and Port Configuration

Required Ports

Firewall Rules (Host)

Production Deployment Checklist

Example Configurations

Local Development

Production Deployment

High-Availability Setup

Troubleshooting

Cannot Connect to Signaling Server

Host Not Appearing in Matchmaker

WebRTC Connection Fails (ICE Failed)

High Latency

Intermittent Disconnections

​Overview

​Client Configuration

​Host Signaling

​Matchmaker Configuration

​ICE and TURN Configuration

​Default Behavior

​Custom ICE/TURN Servers

​Public STUN Servers

​TURN Server Setup

​Redis Configuration (Signaling Server)

​Network Architecture

​Connection Flow

​Components

​Firewall and Port Configuration

​Required Ports

​Firewall Rules (Host)

​Production Deployment Checklist

​Example Configurations

​Local Development

​Production Deployment

​High-Availability Setup

​Troubleshooting

​Cannot Connect to Signaling Server

​Host Not Appearing in Matchmaker

​WebRTC Connection Fails (ICE Failed)

​High Latency

​Intermittent Disconnections

Overview

Client Configuration

Host Signaling

Matchmaker Configuration

ICE and TURN Configuration

Default Behavior

Custom ICE/TURN Servers

Public STUN Servers

TURN Server Setup

Redis Configuration (Signaling Server)

Network Architecture

Connection Flow

Components

Firewall and Port Configuration

Required Ports

Firewall Rules (Host)

Production Deployment Checklist

Example Configurations

Local Development

Production Deployment

High-Availability Setup

Troubleshooting

Cannot Connect to Signaling Server

Host Not Appearing in Matchmaker

WebRTC Connection Fails (ICE Failed)

High Latency

Intermittent Disconnections