Architecture of the 3CX Tunnel Protocol and Session Border Controller (SBC)
Overview
This guide covers the architectural design and operational mechanics of the 3CX Tunnel Protocol and 3CX SBC (Session Border Controller). Readers will learn how the 3CX SBC solves remote NAT traversal, multiplexes SIP signaling and RTP audio into a single encrypted stream over port 5090, and optimizes WAN usage through local RTP hairpinning. Practical deployment configurations and firewall requirements for multi-site enterprise topology are also detailed.

Key takeaways
- The 3CX SBC consolidates all SIP signaling and RTP media into a single TCP/UDP stream on port 5090.
- Completely eliminates SIP ALG, symmetric NAT, and STUN server dependencies at remote branch sites.
- Saves WAN bandwidth by keeping local extension-to-extension RTP audio hairpinned on the branch LAN.
- Encrypts remote voice traffic using standard TLS and AES encryption protocols.
- Simplifies firewall configurations by requiring zero inbound port forwarding rules at the remote site.
Prerequisites
- Understanding of core VoIP protocols including SIP, SDP, and RTP
- Familiarity with NAT types (Full Cone, Symmetric, Restricted) and firewall behaviors
- Administrative access to a 3CX Dedicated or Hosted Instance
- Basic Linux administration skills for SBC deployment on Debian or Raspberry Pi
Guide
- section #1
Architectural Overview of 3CX SBC and Tunneling
The Remote Branch NAT Problem
Deploying standard SIP endpoints across untrusted WAN networks routinely encounters severe NAT traversal issues. Router security mechanisms such as Symmetric NAT dynamically assign public source ports, while broken SIP ALG implementations rewrite SIP headers incorrectly, causing registration failures, silent calls, and one-way audio.
The 3CX Tunnel Architecture
To bypass perimeter network restrictions without configuring complex site-to-site VPNs, 3CX designed the 3CX SBC. Placed inside the remote branch LAN, the SBC aggregates traffic from all local IP phones and proxies it through a proprietary 3CX Tunnel Protocol back to the primary 3CX PBX instance.
Core Benefits of SBC Architecture
- Zero Inbound Configuration: Eliminates inbound port forwarding on the remote branch firewall.
- Unified Endpoint Proxy: Centralizes provisioning, PnP discovery, and firmware delivery for local phones.
- Streamlined Security: Eliminates public-facing SIP ports at remote locations, protecting phones from automated SIP brute-force bots.
- section #2
Packet Multiplexing and Port Consolidation
Multiplexing Signaling and Media
Traditional SIP requires port 5060/5061 for signaling and a broad dynamic range (typically UDP 9000-10999) for RTP streams. The 3CX Tunnel Protocol encapsulates both control and media messages into a unified packet structure sent over a single destination port.
Transport Protocol Mechanics
- Control Channel (TCP 5090): Handles persistent TCP connectivity, SIP signaling transport, tunnel authentication, and fallback media relay.
- Media Channel (UDP 5090): Delivers low-latency, real-time RTP payload audio multiplexed across a single stream.
Frame Overhead and Packet Aggregation
By wrapping multiple SIP control frames and audio frames into unified packet payloads, the SBC reduces firewall state-table entry bloat. This prevents state table exhaustion on smaller router hardware handling hundreds of concurrent calls.
- section #3
Tunnel Security, Authentication, and Encryption
Session Authentication Handshake
When the 3CX SBC daemon initializes, it connects to the 3CX PBX via TCP 5090 and performs a challenge-response handshake. The connection is validated using an SBC Password and an SBC ID configured within the 3CX Management Console.
Payload Encryption Layer
All data encapsulated inside the 3CX Tunnel is secured using industrial-grade cryptographic standards:
- TLS 1.2 / TLS 1.3: Secures control channel signaling and credential exchanges.
- AES-256 Encryption: Encrypts the multiplexed RTP streams across public WAN connections.
Hardening Endpoint Identity
By serving as a local SIP proxy, the SBC prevents endpoints from exposing internal IP structures and device MAC addresses directly across the public internet. External attackers scanning the branch network find no open SIP ports.
- section #4
Local RTP Hairpinning and Media Optimization
WAN Bandwidth Conservation
In standard remote SIP scenarios, intra-office calls between two desks in the same room route media up to the cloud PBX and back down, consuming double the WAN bandwidth. The 3CX SBC features intelligent RTP Hairpinning (Local Direct Media).
Local Switching Process
- Extension A calls Extension B behind the same 3CX SBC.
- SIP Signaling travels through the tunnel to the 3CX PBX to negotiate session parameters.
- Upon call setup, the 3CX PBX instructs the SBC to loop media directly on the local LAN.
- RTP Audio Streams flow directly between phone IPs (or via local SBC proxy), using 0 Kbps WAN audio bandwidth.
Codec Negotiation and Fallback
- Matching Codecs: Direct RTP stream establishes seamlessly on local LAN (e.g., G.722 / Opus).
- Mismatch / Remote Recording: If the PBX must record the call or transcode media, the SBC seamlessly relays RTP back through the 5090 UDP tunnel to the PBX.
- section #5
Configuring 3CX SBC Deployment Settings
Configuration Parameters
The 3CX SBC service reads its operational parameters from an XML/INI configuration file or direct provisioning URL provided during installation. On Linux/Debian deployments, settings reside in
/etc/3cxsbc.conf.Configuration Example
The sample configuration below outlines essential parameters required to link a branch SBC to a central 3CX instance.
Network Binding Parameters
- PBXWSURL: The HTTPS URL of the 3CX PBX Web API.
- TunnelPort: Remote target tunnel port on the 3CX PBX (default: 5090).
- LocalIP: The internal IP address of the local network interface binding the SBC.
ini[General] Name=BranchOffice-SBC PBXWSURL=https://pbx.company.com:5001 TunnelPort=5090 TunnelPassword=eXampleSecureTunnelKey2024! LocalIP=192.168.20.5 LocalPort=5060 LocalRTPPortMin=9000 LocalRTPPortMax=9099 LogFile=/var/log/3cxsbc/3cxsbc.log LogLevel=3 - section #6
Firewall and Provisioning Workflow
Central PBX Firewall Rules
To support remote 3CX SBC connections, the central firewall hosting the 3CX Phone System must allow incoming traffic on specific ports:
- TCP 5090: 3CX Tunnel Control Channel
- UDP 5090: 3CX Tunnel Media Channel
- HTTPS (443 / 5001): Provisioning and Web API communications
Branch Office Endpoint Provisioning
IP phones at the branch office use the SBC as their outbound proxy. Provisioning options include:
- PnP Multicast: The SBC captures local SIP SUBSCRIBE/NOTIFY multicast messages and forwards device requests to the central PBX.
- DHCP Option 66: Points local phones directly to the SBC local IP (
http://192.168.20.5:5060/provisioning/xxxxxx).
bash# Firewall verification on central 3CX Linux server (UFW example) sudo ufw allow 5090/tcp comment '3CX Tunnel Control' sudo ufw allow 5090/udp comment '3CX Tunnel Media' sudo ufw allow 5001/tcp comment '3CX Management & Provisioning'
Further reading
- 3CX SBC Architecture and Deployment Guide
- Configuring 3CX SBC for Linux and Raspberry Pi
- Understanding Port Requirements for 3CX Phone System
- RFC 3550: RTP: A Transport Protocol for Real-Time Applications
