Skip to main content

Integration Guide: Exotel vSIP to SIP-Native Voicebot

This guide provides a comprehensive overview for SIP-native voicebot partners on how to integrate their SIP infrastructure with Exotel's Virtual SIP Trunking (vSIP) setup. It covers supported transport types (TCP, TLS, FQDN), setup best practices, media expectations, SIP header guidelines, and testing checklists.

Alpha Release

This guide covers the Alpha release of vSIP-to-Voicebot integration.

Overview​

Exotel's vSIP integration enables bot providers to connect their SIP-based voicebot platforms directly with Exotel's PSTN and IP network. It allows:

  • Receiving inbound calls from Exophone directly into the bot
  • SIP signaling over TCP or TLS
  • RTP or SRTP media handoff
  • Routing using either static IP or FQDN (DNS-based)

This supports scalable, secure, cloud-native bot deployments without requiring traditional contact center infrastructure.

Supported Use Cases​

ScenarioDescription
Exophone to SIP BotCaller dials an Exophone; Exotel routes to voicebot via SIP
Secure AI Bot DeploymentTLS + SRTP-based encrypted SIP flows
FQDN Load-Balanced Bot GatewayDNS-based bot infra handling SIP load across instances
Bot with DTMF LogicVoicebot uses keypad input (RFC2833) for interaction
NLP-based VoicebotUses STT/TTS stack for open-ended dialogue over RTP
API Outbound Call to SIP BotExotel dials user and connects to SIP bot as second leg

Supported Transport and Routing Options​

ModePortTransportEncryptionDNS/FQDNBest For
TCP5070SIP/TCPNoOptionalLegacy/static IP setups
TLS443SIP/TLSYesOptionalSecure environments (recommended)
FQDN (TCP)AnySIP/TCPOptionalRequiredCloud-native, scalable setups
FQDN (TLS)AnySIP/TLSYesRequiredEncrypted cloud deployments
tip

For detailed setup instructions per transport type, see:

Architecture Flow​

Inbound Call -> Exophone (Exotel) -> vSIP Trunk (TCP/TLS/FQDN) -> SIP Bot Server -> RTP Media Exchange -> Bot Response

Pre-Integration Checklist​

RequirementDescription
SIP ServerMust respond to SIP INVITEs with 200 OK + SDP
Transport ChoiceTCP or TLS required
NAT TraversalUse nat=force_rport, externip, or symmetric RTP config
Codec SupportG.711 PCMA (preferred) and PCMU
RTP Media PortsAllow UDP 10000-20000
SIP PortsTCP 5070, TLS 443
LoggingEnable SIP and RTP logs (sngrep, Wireshark)

SIP INVITE Format (Exotel to Bot)​

INVITE sip:+911234567890@yourbot.fqdn.com:443;transport=tls SIP/2.0
From: "+918888888888" <sip:+918888888888@exotelt.pstn.exotel.com>
To: <sip:+911234567890@yourbot.fqdn.com>
Contact: <sip:+918888888888@182.76.143.61:5060;transport=tls>

SDP Media Format Example​

v=0
o=root 1683048786 1683048786 IN IP4 182.76.143.61
c=IN IP4 182.76.143.61
t=0 0
m=audio 37456 RTP/AVP 8 0 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=ptime:20

Ensure your bot:

  • Accepts PCMA/PCMU codecs
  • Handles RTP and optionally DTMF (RFC 2833)
  • Responds with 200 OK containing valid SDP

Sample TLS Configuration (Asterisk)​

[general]
externip = YOUR.PUBLIC.IP
localnet = 192.168.0.0/16

[exotelvsip]
type = friend
context = incoming
host = pstn.in2.exotel.com
port = 443
transport = tls
disallow = all
allow = alaw
allow = ulaw
encryption = yes
canreinvite = no
nat = force_rport
insecure = port

Network & Firewall Settings​

TypeProtocolDirectionPorts
SIP SignalingTCPBi-directional5070
SIP SignalingTLSBi-directional443
RTP MediaUDPBi-directional10000-20000
warning

Ensure Exotel edge PoP IPs are whitelisted (Mumbai, KA, Singapore). See the Overview for the full IP list.

Bot Behavior Checklist​

  • Accept INVITE, send 200 OK with SDP
  • Accept and decode RTP (PCMA or PCMU)
  • Handle DTMF (RFC 2833) if applicable
  • Return bot-generated TTS response over RTP
  • Respond to BYE or issue BYE on hang-up

Testing Checklist​

ComponentWhat to Verify
INVITE ReceptionBot receives Exotel INVITE
SDP ParsingCorrect codec/media negotiation
RTP InboundAudio from caller reaches bot
RTP OutboundBot sends TTS response
DTMF ProcessingKeypress inputs via RFC2833 parsed correctly
BYE HandlingCall cleanly terminated from both ends

Debugging Tools​

  • sip set debug on (Asterisk) or trace (FreeSWITCH)
  • Wireshark: SIP ladder + RTP stream validation
  • sngrep: Dialogs, SDP, and DTMF traces

Best Practices​

  • Use FQDN for DNS-based routing in cloud infra
  • TLS + SRTP for encrypted sessions
  • Short DNS TTL (30-60s) for fast failover
  • Validate PAI header integrity (Leg1 CLI)
  • Prefer PCMA codec (G.711 A-law)
RTP Media Guidelines
  • Limit media ports to 10000-20000 (10K ports)
  • Each session uses 2 ports
  • Media infra supports 3000 concurrent calls
  • 50% buffer ensures capacity for retries/failovers
ClientDescriptionUsage Scenario
AsteriskFull SIP server; used internally by ExotelProduction-grade bot orchestration
PJSIPLightweight SIP + media stack with bindings for C++, PythonDirect integration with AI pipeline
baresipMinimal SIP CLI client for automationQuick testing / CI / Dev workflows

Ensure support for:

  • G.711 A-law (PCMA)
  • DTMF via RFC 2833
  • TLS + SRTP (optional but recommended)
  • SIP FQDN handling if hosted in cloud

Outbound Call Integration via Exotel Flow​

When outbound calling is required from Exotel to a SIP bot:

Supported Pattern​

  1. Use Exotel's Make-a-Call API to dial the customer
  2. Use a Connect Applet in the assigned Flow to bridge the call to a SIP bot (as Leg B)

API Call (Make-a-Call)​

POST /v1/Accounts/<AccountSid>/Calls/connect.json

{
  "From": "+919999999999",
  "To": "+918888888888",
  "CallerId": "+912261234567",
  "Url": "https://my.exotel.com/flow-control/flow/<flow-id>"
}

In Flow​

  • Use Connect Applet
  • Configure "Dial Whom":
sip:+918888888888@sip.botplatform.com:5070;transport=tcp

Call Flow​

  1. Exotel dials Leg A (customer)
  2. On answer, Leg B is initiated to SIP bot
  3. SIP INVITE goes from Exotel to the bot
warning

This is the only supported outbound architecture. Direct SIP to Exotel for outbound is not supported in this mode.