A practical guide / Fonix.AI
SIP trunk integration: design and pilot guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
SIP voice AI integration has two paths to verify
A SIP voice AI integration must establish both call signalling and two-way audio. A successful registration or an answered call does not prove that the caller can hear the agent, that the agent receives speech or that a transfer can complete.
For Fonix.AI, scope the carrier, session border controller, PBX and voice-service boundary explicitly. This guide is a topology and acceptance checklist; the supported transport, codecs and authentication method must be confirmed for the actual deployment.
Draw signalling and media separately
Mark which system originates the call, where the number routes and which endpoints exchange media. Record public/private addressing, NAT boundaries, permitted ports, codec negotiation and encryption requirements. Use the provider's tested configuration rather than opening unrestricted network access to make a demonstration work.
SIP RFC 3261 defines session signalling. It does not by itself describe the complete audio path. Document the negotiated media endpoints and inspect both directions when diagnosing a silent or one-way call.
Worked example: answered call, one-way audio
In a fictional test, the PBX receives a successful answer but the caller hears silence. The media description advertises an address unreachable across the network boundary. The first investigation is the negotiated media path, not a prompt change or a claim that the speech model failed.
| Symptom | Inspect first | Evidence |
|---|---|---|
| Registration rejected | Auth and provider policy | Sanitised response/transaction |
| Call not routed | Number and dialplan mapping | Route and response codes |
| One-way audio | Negotiated addresses and media | Directional packet evidence |
| Transfer fails | Carrier/PBX transfer support | Linked leg outcomes |
Correlate a call across every boundary
Preserve provider call references, PBX identifiers and the agent session mapping. Capture times with a common clock. Keep diagnostic traces restricted and sanitised: signalling can contain numbers, addresses and authentication material.
Test inbound, outbound, caller hangup and agent hangup independently. For failover, distinguish routing new calls from preserving active media sessions. A backup trunk does not automatically move a live conversation onto another carrier.
A signalling-and-media proof sheet
Draw the intended carrier, PBX, network boundary and agent route with fictionalised identifiers. Agree supported codecs, encryption requirements and diagnostic access. Run controlled calls from both endpoints rather than relying on registration alone.
| Pilot case | Required behaviour |
|---|---|
| The phone answers but one party hears silence | Inspect negotiated media addresses and directional reachability before changing prompts. |
| The caller hangs up while the agent is speaking | Verify teardown across provider, PBX and agent resources. |
| An alternate trunk is selected for a new call | Test the entire backup media path, not only its registration state. |
Report bidirectional intelligible-audio success per attempted test call, alongside setup failures and teardown leaks. Keep transfer and business-action results separate. A successful SIP response is one layer of evidence, not an end-to-end service result.
Will a backup trunk preserve an active conversation?
Do not assume that. New-call routing and active-session continuity are different capabilities. Demonstrate the intended failure mode on the real topology and document whether active calls drop, recover or need an approved callback.
Prove the topology with real endpoints
Run calls through the intended carrier and PBX, including hold, interruption and transfer. Check intelligible audio from both ends and inspect teardown. Record failure categories separately; a combined “call failed” count hides the component that needs work.
Review your SIP voice topology with a sanitised diagram and supported-codec list. See SIP failover for outage drills and Asterisk integration for dialplan ownership. Protocol reference checked 15 October 2026.
For provider-specific scoping questions, see the Exotel call-path review and Plivo stream-and-action review. Verify the account's actual supported topology; neither guide claims universal native integration.