Overview
Running a full end-to-end SIP trunk lab that bridges Webex Calling to the PSTN via Twilio is a great way to understand how a Session Border Controller (SBC) sits in the middle of modern cloud telephony. In this post I’ll walk through my home lab setup where an AudioCodes Mediant SW SBC — deployed on VMware ESXi — interconnects a Webex Calling sandbox and a Twilio free-tier PSTN account.
The SBC acts as the trust and interoperability boundary: it terminates TLS/SRTP from Webex, bridges it to Twilio’s elastic SIP trunking, and handles all the media and signalling differences in between.
Architecture
The diagram below shows the on-premises SBC deployment model used in this lab. The AudioCodes SBC sits inside the enterprise network, connected to the LAN where IP phones and Webex Calling endpoints register. It faces the internet through a firewall (in my case, a home router with port-forwarding and a static public IP) and connects outward to both Cisco Webex Calling and Twilio PSTN.
Figure 1 — On-prem SBC layout. The PSTN cloud on the right is Twilio’s elastic SIP trunking (uclabdev.pstn.twilio.com) rather than a traditional carrier.
In concrete terms for this lab:
- Enterprise Network = home ESXi host, internal subnet 10.0.40.0/24
- SBC LAN IP = 10.0.40.204 (management + internal SIP trunk)
- SBC WAN IP = 10.99.99.204, NAT’d to public IP 12.34.56.78
- SBC public FQDN = sbc1.uclab.dev
- Webex Calling = sandbox organisation, Control Hub managed, SIP connect region EU North
- PSTN = Twilio elastic SIP trunk (free account), domain
uclabdev.pstn.twilio.com
Platform Details
| Component | Details |
|---|---|
| SBC Platform | AudioCodes Mediant SW (virtual) |
| Software Version | 7.40A.005.313 |
| Hypervisor | VMware ESXi (vSphere) |
| CPU | Intel Xeon D-1541 @ 2.10 GHz, 4 cores allocated |
| RAM | 8 GB |
| LAN IP | 10.0.40.204 / 24 |
| WAN IP | 10.99.99.204 / 24 |
| Public NAT IP | 12.34.56.78 |
| SBC FQDN | sbc1.uclab.dev |
| DNS | Cloudflare 1.1.1.1 / Google 8.8.8.8 |
| NTP | 0.de.pool.ntp.org / 1.de.pool.ntp.org |
| Webex | Sandbox organisation (EU North region) |
| PSTN | Twilio free account |
Step 1 — Webex Control Hub: Local Gateway (Trunk) Configuration
Before touching the SBC, the trunk needs to be created in Webex Control Hub. Navigate to Calling → PSTN & Routing → Gateway configurations → Trunk.
The trunk sbc1 is shown as Online (green dot), confirming the SBC has successfully registered.
Key settings visible in the Control Hub trunk panel:
| Setting | Value |
|---|---|
| Trunk name | sbc1 |
| Location | Hamburg-Office |
| Trunk type | Certificate based |
| Device | AudioCodes Session Border Controller |
| FQDN | sbc1.uclab.dev:5062 |
| Max concurrent calls | 250 |
| Webex Calling edge proxy (SRV) | eun01.sipconnect.bcld.webex.com |
| Webex Calling edge proxies (FQDN) | peering1–4.eun.sipconnect.bcld.webex.com:5062 |
| Dual Identity Support | Enabled |
| P-Charge-Info Support | Disabled |
A few important notes here. Certificate-based trunk type means Webex validates the SBC by its TLS certificate CN/SAN — the SBC’s FQDN (sbc1.uclab.dev) must match what is configured in Webex and what is presented in the SBC’s TLS certificate. This is why the Webex TLS context exists as a dedicated context on the SBC. In this lab RequireStrictCert = 0 is used (self-signed/test cert); in production you would use a publicly trusted certificate.
Dual Identity Support being enabled means Webex sends independent From and P-Asserted-Identity headers on outbound INVITEs. This is reflected in the SBC’s Webex IP Profile with SBCAssertIdentity = 1.
The four peering FQDNs are the actual SIP endpoints the SBC connects to. In ProxySet_Webex, eun01.sipconnect.bcld.webex.com is configured as the proxy with DNS SRV resolution, and the SBC resolves the record to reach all four peering nodes for redundancy and load balancing.
Step 2 — Twilio Elastic SIP Trunk Configuration
On the Twilio side, log in to the Twilio Console and navigate to Voice → SIP Trunking. Create an elastic SIP trunk and configure it across three sections: general features, termination, and origination.
Trunk General Settings & Features
| Setting | Value |
|---|---|
| Friendly name | uclabdev-trunk |
| Trunk SID | TK5296679a6d47eed1c22b30a106897050 |
| Secure Trunking | Enabled — TLS on port 5061, SRTP mandatory |
| Call Transfer (SIP REFER) | Enabled |
| Caller ID for Transfer Target | Set caller ID as Transferee |
| Symmetric RTP | Enabled |
| Call Recording | Disabled |
Secure Trunking being enabled is the critical setting that drives the SBC configuration. It mandates TLS on port 5061 and SRTP for all media. This is why the Twilio SIP Interface on the SBC (SI-Twilio) listens on TLS port 5061, and the Twilio IP Profile sets SBCMediaSecurityBehaviour = 1 (SRTP mandatory). If you enable Secure Trunking here but leave SRTP optional on the SBC, Twilio will reject calls with a 488 Not Acceptable Here.
Symmetric RTP tells Twilio to detect where RTP packets actually arrive from and send RTP back to that address, rather than strictly following the SDP c= line. This is essential when the SBC is behind NAT — Twilio follows the actual RTP source IP rather than the private IP that can slip through in SDP.
Twilio Termination (Outbound Calls to PSTN)
Termination handles outbound calls from your infrastructure toward the PSTN.
| Setting | Value |
|---|---|
| Termination SIP URI | uclabdev.pstn.twilio.com |
| Routing | Regional — US1 Active |
| Authentication — IP ACL | uclabdev (the SBC’s public IP 12.34.56.78) |
| Credential Lists | None (IP ACL authentication only) |
The Termination SIP URI uclabdev.pstn.twilio.com is configured in the SBC as both the SIPGroupName of the Twilio IP Group and as the proxy address in ProxyIp (uclabdev.pstn.twilio.com:5061). When the SBC sends an outbound INVITE toward Twilio, the Request-URI host must match this domain exactly.
Authentication is purely IP-based — Twilio whitelists the SBC’s public IP (12.34.56.78) via the uclabdev IP ACL. No SIP digest credentials are needed for termination, which keeps the SBC config straightforward. The Classification rule on the SBC (twilio-termination-uri) also matches inbound INVITEs from the Twilio domain to correctly assign them to the twilio IP Group.
Twilio Origination (Inbound Calls from PSTN)
Origination handles inbound calls arriving from the PSTN to your infrastructure.
| Setting | Value |
|---|---|
| Origination URI | sip:sbc1.uclab.dev:5061;transport=tls |
| Priority | 10 |
| Weight | 10 |
| CNAM Lookup | Off |
The Origination URI points directly at the SBC’s public FQDN on TLS port 5061. When a PSTN call arrives at Twilio, it forwards the INVITE to this URI. On the SBC, the SI-Twilio SIP interface is listening on WAN TLS 5061, and the inbound call is classified to the twilio IP Group and routed onward to Webex via the twilio-to-Webex routing rule.
Step 3 — AudioCodes SBC Configuration
With both cloud sides provisioned, here is how the SBC bridges them.
Network Interfaces
The Mediant SW uses two VMware VMXNET3 adapters:
| Interface | IP Address | Prefix | Gateway | Role |
|---|---|---|---|---|
| LAN | 10.0.40.204 | /24 | 10.0.40.254 | OAMP + internal SIP + media |
| WAN | 10.99.99.204 | /24 | 10.99.99.254 | External SIP + media (NAT’d) |
A NAT translation rule maps all WAN traffic to public IP 12.34.56.78 across all ports (1–65535). This ensures SIP Contact, Via, and SDP connection headers seen by Webex and Twilio always show the routable public address. Without this, both cloud providers would see private RFC1918 addresses and reject in-dialog requests or fail to route media back correctly.
Static routes send traffic for internal subnets (10.0.39.0/24, 10.0.66.0/24) via the LAN gateway, covering secondary PBX and CUCM nodes.
TLS Contexts
Two TLS contexts are defined — default for the internal SIP trunk and Webex (TLS 1.3) for both the Webex Calling and Twilio legs. Both contexts advertise strong TLS 1.3 cipher suites with X25519, P-256, P-384, and X448 key exchange groups. The same TLS context is reused for Twilio since both cloud providers accept TLS 1.3.
Media Realms
| Realm | Interface | RTP Port Range | Sessions | Purpose |
|---|---|---|---|---|
| MR-Webex | WAN | 20000–20399 | 100 | Media to/from Webex Calling |
| MR-SIPTrunk | LAN | 6000–6399 | 100 | Media to/from internal PBX |
| MR-Twilio | WAN | 6000–6399 | 100 | Media to/from Twilio PSTN |
Webex media uses a distinct port range (20000+) to avoid overlap with Twilio’s range on the same WAN interface.
SIP Interfaces
| Interface | Network | Transport | Port | TLS Context | Mutual Auth |
|---|---|---|---|---|---|
| SI-Webex | WAN | TLS | 5062 | Webex | Yes |
| SI-Trunk | LAN | UDP + TCP | 5060 | default | No |
| SI-Twilio | WAN | TLS | 5061 | Webex | No |
IP Profiles
Three IP Profiles define per-leg behaviour. The Twilio profile mirrors the trunk settings configured in the Twilio console — SRTP mandatory, ICE mode enabled, and RTCP-mux on. The Webex profile enables PAI assertion (matching Dual Identity Support in Control Hub) and mandatory SRTP. The SIPTRUNK profile uses SRTP-optional for compatibility with the internal PBX.
Proxy Sets and IP Groups
| IP Group | Proxy Destination | Transport | Registration |
|---|---|---|---|
| Webex | eun01.sipconnect.bcld.webex.com | TLS | Mode 2 (SBC registers to Webex) |
| SIPTRUNK | 10.0.40.248:5060 + 10.0.39.248:5060 | UDP | None |
| twilio | uclabdev.pstn.twilio.com:5061 | TLS | Mode 2 (SBC registers to Twilio) |
Both cloud IP Groups use sbc1.uclab.dev as the Contact User, ensuring the SBC always presents its public FQDN in SIP Contact headers toward Webex and Twilio. The internal trunk uses two proxy IPs with equal priority and weight (10/10) for active-active load balancing.
Routing Table
| Rule | Source | Destination | Notes |
|---|---|---|---|
| Terminate OPTIONS | Any | — | Replies 200 OK locally — prevents keep-alive OPTIONS from being forwarded upstream |
| Webex-to-Twilio | Webex | twilio | Outbound Webex calls to PSTN |
| twilio-to-Webex | twilio | Webex | Inbound PSTN calls from Twilio to Webex |
Message Manipulations (ManSet 2)
Applied on outbound legs toward Webex and Twilio, these rules rewrite SIP headers to consistently present sbc1.uclab.dev as the SBC’s identity. Without them, both cloud providers see a private IP in Contact headers and reject requests. The rules cover Contact URL host, From/To URL host on OPTIONS, and a fallback for Max-Forwards on incoming OPTIONS probes.
Security Configuration
Malicious Signature DB — 12 signatures block well-known SIP scanners (SIPVicious, sipsak, SIPScan, sipcli, Gulp, and others) by matching the User-Agent header prefix at classification time, before any routing decision is made.
SNMP — Disabled. No SNMP attack surface exposed on the network.
Telnet — Disabled. Management is via HTTPS web UI only.
Syslog — Forwarded to internal server at 10.0.40.2 with full activity logging covering CLI access, software updates, alarms, PVC changes, and authentication events.
Twilio IP ACL — Only the SBC’s public IP (12.34.56.78) is whitelisted in Twilio’s termination authentication. No password credentials are required.
Webex Certificate Auth — The Webex TLS context is used with mutual authentication on SI-Webex. The SBC presents its certificate for sbc1.uclab.dev and Webex validates it against the trunk FQDN configured in Control Hub.
Codec Configuration
The audio coder group AudioCodersGroups_0 is shared across all legs:
| Priority | Codec | Payload Type | pTime |
|---|---|---|---|
| 1 | G.711 µ-law (PCMU) | dynamic | 20ms |
| 2 | G.711 a-law (PCMA) | dynamic | 20ms |
| 3 | Opus | PT 111 | 20ms |
G.711 is the common denominator across Webex, Twilio, and typical internal PBXes, so all calls connect without transcoding in this lab.
Tips and Gotchas
Twilio Secure Trunking is a hard requirement — if your SBC Twilio profile has SRTP set to optional, Twilio rejects calls with 488. Set SBCMediaSecurityBehaviour = 1 on the Twilio IP Profile and ensure the Twilio SIP Interface uses TLS port 5061.
Webex certificate-based trunk requires TLS mutual auth — upload the Webex root CA into the Webex TLS context on the SBC. The SBC’s own certificate CN/SAN must exactly match the FQDN entered in Control Hub (sbc1.uclab.dev). A free Let’s Encrypt certificate works well if the FQDN is publicly resolvable via DNS.
Contact header rewriting is mandatory — ManSet 2 must rewrite the Contact host to the SBC’s public FQDN. Without this, Webex and Twilio see a private RFC1918 IP in Contact and subsequent in-dialog requests (re-INVITEs, BYE) fail.
Enable Symmetric RTP on Twilio — this setting in the Twilio trunk console works together with the SBC’s NAT translation. Twilio will follow the actual RTP source rather than the SDP c= address, which is critical when the SBC is behind NAT.
OPTIONS termination rule must be first — place the routing rule with InternalAction = Reply(Response='200') at the very top of the IP-to-IP routing table. If placed lower, OPTIONS keep-alive probes from Webex may accidentally match a call routing rule and get forwarded upstream.
Twilio free account restrictions — outbound calls to real PSTN numbers are limited on free accounts. Verified numbers and Twilio test numbers work fine for lab validation. The SIP domain, trunk configuration, and TLS/SRTP all work exactly the same as on a paid account.
ESXi VMXNET3 zero-copy — the NICs show as vmxnet3-zc (zero-copy mode). This is fine for a lab but on older ESXi builds can occasionally cause unexpected RTP packet loss under sustained load.
Conclusion
With an AudioCodes Mediant SW on ESXi, a Webex Calling sandbox, and a Twilio free account, you get a fully functional cloud PSTN gateway bridging inbound and outbound calls end-to-end. The configuration is intentionally lean: three SIP interfaces, three IP groups, three media realms, a three-rule routing table, and a handful of header manipulations.
The Webex side requires a certificate-based Local Gateway trunk in Control Hub pointing to the SBC FQDN on TLS 5062 with Dual Identity Support enabled. Twilio requires Secure Trunking (TLS 5061 + SRTP), an IP ACL for the SBC’s public IP on the Termination side, and an Origination URI pointing back at the SBC. The SBC bridges the two with separate TLS contexts, media realms, and IP profiles tuned to each cloud provider’s requirements.
The biggest operational gotcha is always the NAT and Contact header chain — get those right and everything else falls into place.
Lab environment: AudioCodes Mediant SW 7.40A.005.313 · VMware ESXi · Webex Calling Sandbox · Twilio Free Tier