Vobiz is an Indian SIP trunk and DID provider. Unlike the app-platform integrations (Twilio, Plivo, Telnyx), there is no API surface to port. Vobiz is a carrier, and the integration is a trunk. You point your Vobiz trunk at ClutchCall. The platform terminates the SIP legs. Every DID routes to the agent that you select. This architecture is in production today for Indian DIDs. Everything downstream of the trunk is ordinary ClutchCall. The engine decodes the carrier leg to the 8 kHz pcm16 audio bus. The DID can point at a native agent or an external agent. A native agent is the managed runtime: prompt and STT/LLM/TTS in the console. An external agent is your own worker process. The worker holds one outbound QUIC/WebTransport session. It registers under an agent handle, and a VENDOR_BRIDGE config routes calls to it.

​
What maps to what

​
Bring the trunk up

1

Create the trunk in the console

In the console (agent.clutchcall.dev), add a SIP trunk. Select the auth mode that your Vobiz service uses:
  • Registration: enter the SIP username/password from Vobiz. The platform registers to their registrar and keeps the binding alive.
  • IP auth: exchange static IPs instead. Allowlist Vobiz’s signaling IPs on the trunk. Give Vobiz the platform’s SIP host as the call target.
See SIP Trunking for trunk fields, codecs, and failover.
2

Route each DID to an agent

Attach your Vobiz DIDs to the trunk. Point each DID at an agent. Both kinds are first-class targets:
  • Native agent: the managed runtime runs the conversation (cascade or speech-to-speech) with your provider keys. You run no servers.
  • External agent: your own process gets the call. The console’s External agents create flow reserves the agent handle. It mints the media app key/secret that your worker authenticates with. It writes the VENDOR_BRIDGE config:
agent-config.json
The worker side is the same seam as every other external-agent integration: pip install "telequick-agents[quic]", plus a handler that reads call.audio() and writes call.send_audio(). Start from the external-agent recipe.
3

Place a test call in each direction

Dial the DID from a mobile phone. The engine answers on the Vobiz leg and dispatches to the routed agent. Then originate outbound through the same trunk with an mpk_ management key (console → Settings → API keys):
4

Wire up lifecycle events

Register a signed webhook for call lifecycle, CDRs, recordings, and transcripts. Use webhooks.create {vertical:'voice', url, eventTypes} with events such as voice.call.answered, voice.cdr.created, and voice.recording.ready. Check the X-Clutchcall-Signature header (t=<epoch>,v1=<hmac_sha256(secret, "t.body")>) with telequick_agents.webhooks.verify_signature before you trust a delivery.

​
Troubleshooting

On registration trunks, check the registration state on the trunk page. Wrong credentials or a Vobiz-side block shows there first. On IP-auth trunks, check that the allowlist covers all of Vobiz’s signaling IPs, not only the IP that you saw traffic from.
This is a classic SIP/NAT symptom on carrier trunks. Check the media (RTP) path in both directions. Check any address rewriting between Vobiz and the platform. SIP & RTP debugging shows both legs of a live call.
The trunk is good, but the worker is not. Check that the worker is registered under the exact handle in vendor_room. Check that it has outbound UDP/443 to engine.clutchcall.dev. Media rides QUIC datagrams. A TCP-only network registers correctly and then stalls audio.

SIP Trunking

Trunk auth modes, codecs, and failover in full.

Number Provisioning

DIDs, routing, and per-number agent assignment.

LiveKit integration

Run an existing LiveKit agent behind your Vobiz DIDs.

Run a LiveKit Agent on the Transport

The end-to-end external-agent recipe for the worker side.