Connecting voice agents to telephony with SIP trunks

A voice agent that lives only in the browser is a demo. The minute you want users to actually reach it from a phone, you need a SIP trunk: a virtual line that connects your agent to the public phone network. The good news is the technology is mature. The less-good news is that the codec edge cases and the regulatory layer (caller ID attestation, country-specific rules) take real work to get right. This post walks through what a SIP trunk is, why we picked Bring Your Own Number (BYON) as the only deployment pattern we support, and how SipPulse AI ships native SIP integration so the same agent answers browser calls and phone calls without forking the implementation.

What a SIP trunk is and why your voice agent needs one

A SIP trunk is a virtual phone line. It uses the SIP protocol over the internet to deliver voice calls to and from the public switched telephone network (PSTN). Without it, a voice agent cannot make or receive a real phone call: a customer dialing your number gets nothing, and an outbound call from your agent cannot reach a person.

The SIP trunk does three things:

• Inbound routing: a customer dialing your number lands at a SIP endpoint your agent is listening on
• Outbound origination: your agent initiates a call, the SIP trunk hands it to a carrier, the carrier routes it to the destination number
• Codec and signaling bridging: a translation layer between the carrier world (PCMU, PCMA, SIP, RTP) and the voice agent world (Opus, WebRTC)

For a voice agent built on WebRTC, the SIP trunk is the bridge between the WebRTC world and the carrier world. The bridge has to handle codec conversion, DTMF for legacy IVR pass-through, and call signaling that satisfies both sides.

We are BYON only, and that is on purpose

SipPulse AI is BYON: Bring Your Own Number. We do not sell, rent, port or originate phone numbers. The customer keeps their existing number with their existing carrier, and configures SIP forwarding from that carrier into SipPulse AI.

The reasons:

• We are an AI platform, not a telco. Number provisioning is a separate business with separate regulatory licenses, billing infrastructure and country-by-country compliance. Doing it well requires being a carrier, and being a carrier is not what makes a voice agent good.
• Your number stays where it is. No porting risk, no downtime, no risk of losing a number that has been on your marketing material for years. The carrier of record does not change, your billing does not change, and the rest of your telecom stack keeps working.
• You stay in control. If you change voice AI vendors tomorrow, you redirect SIP forwarding back to your old destination. The number is yours.

For customers who do not yet have a number or carrier, the path is to first sign up with a SIP trunk provider in the country where the number lives, then BYON to SipPulse AI. We can recommend providers that fit specific country and regulatory needs.

STIR/SHAKEN and outbound caller ID

If your voice agent makes outbound calls, caller ID matters. Carriers and call-screening apps now check whether outbound numbers have valid attestation under the STIR/SHAKEN framework. Calls without attestation get flagged as spam or potential fraud and either go to voicemail or get blocked entirely.

STIR/SHAKEN attests three levels:

• A-level (full attestation): the carrier verifies both the calling number and the customer using it. This is the cleanest path through spam filters
• B-level (partial): the carrier verifies the customer but not the specific number
• C-level (gateway): the carrier just acknowledges the call passed through their network

In the US, the FCC mandate has driven near-universal carrier support, so A-level attestation is the standard target for outbound voice AI campaigns. In Brazil the picture is different: STIR/SHAKEN is just starting to roll out, and many local operators do not yet support attestation. Customers who need attested outbound on Brazilian numbers should contact us so we can suggest a SIP trunk provider that supports the framework. The technology is in motion and adoption is expanding, but it is not yet universal in the local market.

Codecs, DTMF and the messy reality

The SIP world runs on PCMU (G.711 µ-law in North America) and PCMA (G.711 a-law in Europe and Brazil), plus G.729 on bandwidth-constrained legacy paths. The WebRTC world runs on Opus. The voice agent's media pipeline has to bridge them transparently, ideally with hardware acceleration so the conversion does not add latency.

DTMF is the other detail that surprises teams. When a customer presses a digit on their phone, the SIP trunk delivers a DTMF event (RFC 2833 in-band, or SIP INFO out-of-band) that the agent has to listen for and route. This is critical for any voice agent that integrates with legacy IVR systems, IVR-based authentication, or "press 1 to confirm" prompts.

A SIP trunk integration that handles codecs, DTMF, transcoding, jitter buffering and call recording natively is invisible when it works. When it does not, every call starts with garbled audio.

Where SipPulse AI fits

SipPulse AI ships native SIP trunk integration into the platform. The same voice agent that answers a browser call answers a phone call, with codec bridging and DTMF handling done in the underlying media pipeline. Bring your own SIP trunk and we wire it into your agent in a configuration step, not a quarter-long integration project.

For Brazilian deployments, the trunk handles PCMA, G.729 and the local STFC numbering rules. NIVA, our block-based builder, lets you wire DTMF prompts, IVR flows and voice agent blocks together visually, which is exactly the workflow you want when migrating an existing IVR to a voice AI experience without losing the keypad shortcuts customers already know.

You can hear the result at our demo page, and inspect the per-call latency on our example telemetry viewer. For teams ready to BYON your numbers and deploy on production traffic, contact our team to walk through the SIP forwarding setup.

Read also

• Building voice agents on WebRTC: the production stack
• Voice AI vs IVR: ROI breakdown for contact centers
• Voice AI compliance: LGPD, GDPR and PCI for call data

Conclusion

A voice agent without a SIP trunk is a chatbot. The trunk is what makes it a phone product. SipPulse AI is BYON only by design: you keep your number with your carrier, we connect via SIP. The engineering details (codecs, DTMF, STIR/SHAKEN where available) are where production-readiness actually shows. Try our demo or contact our team to deploy SipPulse AI on your numbers.