# Configure the SIP Trunk and SBC Network # Configure the SIP Trunk and SBC Network To route user voice channels to an external AI bot platform, a dedicated, low-latency communication pipe must exist. In this step, we will have to establish a secure Session Border Controller (SBC) peering configuration with Zoom Voice Services, bind public trusted security certificates, and authorize specific firewall subnets to ensure pristine media transmission. ### Configure Session Border Controller (SBC) Core Parameters First, we will have to configure the edge SBC to meet Zoom's strict communication standard protocols. Zoom recommends utilizing an SBC that has completed official interoperability testing. - **Signaling and Media Encryption:** Set transport signaling to enforce **TLS 1.2** minimum and assign **SRTP** for voice media streams when peering over the public internet. - **SIP Protocol Standards:** Enforce strict compliance with **RFC-3261** (SIP Core), **RFC-2833** (Inband DTMF Tone Delivery), and **RFC-5853** (Topology Hiding). - **Session Initialization:** Enforce **SIP Early Offer** on all outbound `INVITE` sequences directed toward Zoom endpoints. - **Audio Voice Codecs:** Prioritize and activate the following supported codecs within your media profile allocation: **Opus, G.722, G.711 (μ-law/a-law), and G.729**. ### Implement TLS Security and Certificates Next, we will have to bind a publicly trusted TLS certificate to the SBC edge. Self-signed certificate configurations are explicitly rejected by Zoom Cloud security layers. - **Certificate Structure:** Ensure the certificate includes the SBC's Fully Qualified Domain Name (FQDN) inside the **Common Name (CN)** or **Subject Alternative Name (SAN)** field. - **Chain Validation:** Configure the SBC to present the complete validation chain, including all **intermediate certificates**, during the TLS handshake sequence. #### Supported Public Certificate Authorities: | | | | | :------------------------ | :---------- | :--------------------- | | AffirmTrust | GeoTrust | Starfield | | Baltimore | GlobalSign | Symantec | | Buypass | GoDaddy | T-Systems | | Comodo/Sectigo | QuoVadis | TeliaSonera | | D-Trust | SECOM Trust | Thawte Inc. | | Digicert | USERTRUST | Entrust / SSL.com | | Verisign | TWCA | Let's Encrypt Root CA | | Google Trust Services LLC | Harica | Starfield Technologies | ### Configure Firewall and Port Allowlists Next, we will have to update network firewall rules to permit bidirectional signaling and Real-time Transport Protocol (RTP) traffic between your infrastructure and Zoom's global data centers. #### Protocol Port Rules: - **SIP Signaling:** Open `TCP / Port 5061` (Secure TLS) - **RTP/SRTP Media:** Open `UDP / Port Range 10000 – 64000` #### Zoom Subnet Allocation Blocks to Allowlist: - `64.211.144.0/24` - `115.110.154.192/26` - `134.224.0.0/16` - `144.195.0.0/16` - `147.124.96.0/19` - `149.137.0.0/17` - `156.45.0.0/17` - `159.124.0.0/16` - `170.114.0.0/16` - `173.231.92.0/24` - `173.231.94.0/24` - `206.247.0.0/16` ### Coordinate the Delivery Lifecycle Phase Finally, we will have to execute the trunk lifecycle process in coordination with the Zoom Independent Software Vendor (ISV) engineering team. 1. **Discovery Phase:** Submit your signaling IP addresses, media IP ranges, regional operational models, and enterprise support contact points to the Zoom ISV team. 2. **Pre-Production Build:** Zoom will configure a test trunk in a staging ("Go") environment. we will have to use this environment to complete baseline sandbox application testing. 3. **Production Verification:** Once staging success is verified, Zoom will build out the final production SIP trunk architecture, allowing the application to be finalized for tenant delivery.