This guide explains how to add the Talkative SIP Trunk connection (Talkative's Twilio Programmable SIP domain, used to reach Talkative Engage / Voice AI) on an AudioCodes Mediant SBC (on-prem or cloud-hosted, e.g. Mediant SW) — as distinct from AudioCodes Live Hub, which has its own guide. It applies regardless of what sits on the other end — Mitel, Webex Calling, or any other SIP-capable platform. Once this connection is in place, you route calls to it from any other IP Group configured on the SBC via IP-to-IP Routing rules.
This guide is intended as guidance only. It assumes the person configuring this is comfortable working within the Mediant SBC platform and able to adapt the steps below to their specific environment, firmware version, and use case — field names, menu locations, and available options can vary by SBC model and software version.
For guidance on configuring a specific originating platform (e.g. Webex Calling via a carrier/BroadWorks trunk), see the relevant platform-specific integration guide. This document only covers the Talkative-facing connection itself.
Overview
The Talkative SIP Trunk connection is the fixed part of any Mediant SBC integration with Talkative Engage — it doesn't change based on what platform you're connecting. What varies between integrations is the platform-facing SIP Interface/Proxy Set/IP Group and the IP-to-IP Routing rule that links the two.
Your platform (any SIP-capable system)
↓
AudioCodes Mediant SBC — platform-facing IP Group (platform-specific)
↓ IP-to-IP Routing rule
AudioCodes Mediant SBC — "VoiceAI" IP Group (this guide)
↓
Talkative Engage / Voice AI (via Twilio Programmable SIP)Prerequisites
- Admin access to the AudioCodes Mediant SBC (Web UI or CLI)
- A Voice AI config already created in Talkative Engage, with your SIP trunk details available on the Voice Routing page (Engage → Settings → Voice Routing)
- Confirmation of whether your account requires encryption (TLS/SRTP) — this is set on the Talkative side and must match on this connection
Talkative uses Twilio to provide SIP trunk connectivity. Your trunk hostname takes the form {account-uuid}.sip.{region}.twilio.com, visible on the Voice Routing page in Engage. The default region is us1; if you use a different edge region, include it in the hostname.
Firewall/IP allowlisting: if your network path to Twilio passes through a firewall, allowlist Twilio's SIP trunking signalling IP ranges — see Twilio's IP Addresses for Elastic SIP Trunking documentation. Prefer resolving the FQDN over hardcoding a single IP, since Twilio does not guarantee a fixed address.
Step 1: SIP Interface
A dedicated SIP Interface isn't strictly required if an existing interface on the SBC already matches the transport/port/TLS requirements below — in our own lab build we reused an existing SIP Interface (SIPInterface_0) that was already handling other TLS trunks on port 5061, rather than creating a new one. Only build a new one if you need different transport, port, or TLS Context settings than what's already configured.
If building new: Setup → Signaling & Media → Core Entities → SIP Interfaces
- Application Type —
SBC
- TLS Port —
5061if your account requires encryption; otherwise UDP5060
- TLS Context — any context with a public-CA-signed certificate (Twilio doesn't require mutual TLS on this leg)
- TLS Mutual Authentication —
Disable(not required for Twilio Programmable SIP)
If reusing an existing interface, check for TLS port conflicts with other trunks on the same Network Interface — AudioCodes will reject activation with a ValidatePorts error if two SIP Interfaces try to share the same TLS port on the same underlying network interface. Either use a distinct port or a dedicated IP Interface if this occurs.

Step 2: Proxy Set
Setup → Signaling & Media → Core Entities → Proxy Sets → +New
- Name —
ProxySet_VoiceAI(or similar)
- SBC IP Interface — the SIP Interface from Step 1
- Proxy Address — your Twilio trunk hostname, e.g.
{account-uuid}.sip.{region}.twilio.com
- Transport Type —
TLSif encrypted, otherwiseUDP
- DNS Resolve Method —
A-Record(Twilio Programmable SIP domains typically resolve via A-record rather than SRV — confirm viadig/nslookupagainst your specific hostname if unsure)
If this Proxy Set sits at NOT RESOLVED on the Proxy Sets Status monitor page with no obvious error, check the DNS Resolve Method setting first — a blank or mismatched resolve method (e.g. expecting SRV when only A-records are published, or vice versa) looks identical to a genuine DNS/connectivity failure but is a config issue, not a network one.

Step 3: IP Group
Setup → Signaling & Media → Core Entities → IP Groups → +New
- Name —
VoiceAI
- Type —
Server
- Proxy Set — the Proxy Set from Step 2
- Media Realm — assign a Media Realm
- Topology Location —
Up(WAN-facing)
- Registration — not required; Talkative's Twilio Programmable SIP connector is typically IP-based, not registration-based (unlike some carrier/BroadWorks trunks). Confirm with your Talkative representative if your account has been configured to require registration.

Step 4: IP-to-IP Routing
Setup → Signaling & Media → SBC → Routing → IP-to-IP Routing → +New
Inbound (platform → Voice AI):
- Source IP Group — your platform-facing IP Group (e.g. a Webex, Mitel, or other carrier IP Group)
- Request Type —
All
- Destination Type —
IP Group
- Destination IP Group —
VoiceAI
Return path (Voice AI → platform, for transfers):
If the Voice AI bot transfers calls back out to the platform (via SIP REFER), a mirrored rule is also needed:
- Source IP Group —
VoiceAI
- Destination IP Group — your platform-facing IP Group

Verifying the exact endpoint address
Once this connection is live and routing calls to it, place a test call and check the Twilio Call Log page in Engage (Settings → Twilio Call Log). The To column shows the exact SIP URI Talkative received — use this to confirm the Request-URI leaving the SBC matches what's expected, and to catch any Contact User / number formatting mismatches early.

Troubleshooting
Proxy Set stuck on NOT RESOLVED
Check DNS Resolve Method on the Proxy Set (Step 2) before assuming the hostname or Twilio's DNS is at fault.
Calls route to VoiceAI but the bot never answers / no INVITE reaches Talkative
Check Monitor → VoIP Status → SBC CDR History to confirm the INVITE is classified into the correct IP Group and actually routed — a missing or misordered IP-to-IP Routing rule will show as a GENERAL_FAILED termination reason with no INVITE ever leaving the SBC on this leg.
Transfers back to the platform fail with 401 Unauthorized on REFER
This is a platform-facing IP Group authentication setting, not a VoiceAI/Talkative connection issue — check the Authentication Mode / Authentication Method List on that IP Group.
TLS handshake fails to Twilio
Confirm the TLS Context assigned in Step 1 has a certificate signed by a public CA — self-signed or internal-CA certs will be rejected by Twilio's infrastructure.