Requirements for a new telephony provider

If your carrier isn’t among the supported providers, Ringg can add it when it meets the capabilities below. Missing any one of them means the provider can’t be fully integrated; if it supports standard instead, a SIP trunk is the faster route.

1. Outbound call API

The provider must expose an API to start an outbound call. Ringg calls it with:

Parameter	Format	Example
To, the customer’s number	E.164	`+919876543210`
From, the caller ID /	E.164	`+919876540111`
WebSocket URL, which the provider connects to for two-way audio once the callee answers	WSS	`wss://api.ringg.ai/stream/newprovider/{call_id}`
Callback / hangup URL, which the provider POSTs to when the call ends, with status, duration and recording URL	HTTPS	`https://api.ringg.ai/callback/newprovider/{call_id}/hangup`

How a call runs:

Ringg calls the provider’s outbound API with your credentials, passing the WebSocket URL in the request.
The provider places the call. When the callee answers, it connects to that WebSocket URL at once and streams audio both ways. No answer-URL round trip is needed: unlike inbound calls, the WebSocket URL is in the request itself.
When the call ends, the provider hits the callback URL with the call’s status and metadata.
Ringg runs post-call processing: transcript, recording, webhooks and analytics.

POST https://api.newprovider.com/v1/calls
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "from": "+919876540111",
  "to": "+919876543210",
  "websocket_url": "wss://api.ringg.ai/stream/newprovider/{call_id}",
  "hangup_url": "https://api.ringg.ai/callback/newprovider/{call_id}/hangup"
}

{
  "call_id": "provider-unique-call-id",
  "status": "queued"
}

2. Get call by ID API

The provider must expose an API to fetch a call by its ID. Ringg uses it to verify call status during and after the call, fetch duration and billing metadata, and retrieve the recording URL when the provider records.

GET https://api.newprovider.com/v1/calls/{call_id}
Authorization: Bearer <api_key>

{
  "call_id": "provider-unique-call-id",
  "status": "completed",
  "duration": 120,
  "from": "+919876540111",
  "to": "+919876543210",
  "recording_url": "https://recordings.newprovider.com/rec_123.mp3",
  "start_time": "2026-03-12T10:00:00Z",
  "end_time": "2026-03-12T10:02:00Z"
}

How existing providers do it:

Provider	Endpoint	Auth
Plivo	`GET /v1/Account/{auth_id}/Call/{call_uuid}/`	Basic Auth (auth_id:auth_token)
Twilio	`GET /2010-04-01/Accounts/{sid}/Calls/{call_sid}.json`	Basic Auth (sid:auth_token)
Exotel	`GET /v2_beta/Accounts/{sid}/Calls/{call_sid}.json`	Basic Auth (api_key:api_token)
Tata Tele	`GET /v1/live_calls`	Bearer token
Vobiz	`GET /api/v1/Account/{auth_id}/Call/{call_uuid}/`	Custom headers (`X-Auth-ID`, `X-Auth-Token`)

3. Inbound calls

For inbound calls the flow is reversed: the provider calls Ringg when a call arrives.

A caller dials a DID. The provider receives the call.
The provider sends a webhook to Ringg’s inbound endpoint with call_sid, from_number and to_number (the DID), and keeps the caller in a ringing state. The caller must not hear silence or be disconnected while Ringg sets up.
Ringg looks up to_number, finds the workspace and agent attached to that DID, builds the call config and returns the WebSocket URL in the webhook response.
The provider connects to that URL at once and streams audio both ways.

The response format depends on the provider:

<Response>
  <Stream keepalive="true" audio="true" contentType="audio/x-mulaw">
    wss://api.ringg.ai/stream/newprovider/{call_id}
  </Stream>
</Response>

<Response>
  <Connect>
    <Stream url="wss://api.ringg.ai/stream/newprovider/{call_id}" />
  </Connect>
</Response>

{
  "websocket_url": "wss://api.ringg.ai/stream/newprovider/{call_id}"
}

4. WebSocket streaming

The provider must stream audio over WebSocket in both directions. This is how the agent hears and speaks to the caller.

Requirement	Detail
Protocol	WSS (WebSocket Secure)
Audio format	PCM 16-bit, mu-law or a-law (provider-dependent)
Sample rate	8 kHz or 16 kHz
Direction	The provider sends caller audio and receives agent audio
Latency	Low; under 200 ms round trip is the target

Over that socket the provider must send three kinds of message:

Audio: binary frames of caller audio.
DTMF events: one per keypad digit the caller presses, for example { "event": "dtmf", "digit": "5", "call_id": "provider-call-id" }.
Call control: start, stop and hangup signals for the call lifecycle. Tata Tele’s format is the reference: a connection-established message, binary audio frames, digit events, call state changes (connected, disconnected) and metadata messages (call ID, caller info).

DTMF is mandatory. Ringg agents use the wait_for_dtmf tool to collect keypad input (“Press 1 to confirm, press 2 to cancel”). Without DTMF events, those agent flows cannot work.

5. Call transfer

The provider must support a blind transfer: handing an active call to another number without waiting for the target to answer. During a call the agent decides to transfer from the conversation and its transfer rules, calls the call_transfer tool with a target number, and Ringg sends the transfer command to the provider by REST API or WebSocket control message. The provider connects the caller to the target, and Ringg logs the transfer for analytics.

POST https://api.newprovider.com/v1/calls/{call_id}/transfer
Authorization: Bearer <api_key>

{
  "target_number": "+919876543210",
  "transfer_type": "blind"
}

{
  "action": "transfer",
  "target_number": "+919876543210",
  "call_id": "provider-call-id"
}

Checklist

Before requesting an integration, confirm the provider supports all six:

Capability	Required
Outbound call API that accepts a WebSocket URL	Yes
Get call by ID API	Yes
Inbound call webhook with ringing hold	Yes
Bidirectional WebSocket audio	Yes
DTMF events over the WebSocket	Yes
Blind call transfer	Yes

Build agents

Inventory

Deploy

Monitor

Manage account

Ringg Labs

New provider requirements

1. Outbound call API

2. Get call by ID API

3. Inbound calls

4. WebSocket streaming

5. Call transfer

Checklist

Next steps

Request an integration

Use a SIP trunk instead

​1. Outbound call API

​2. Get call by ID API

​3. Inbound calls

​4. WebSocket streaming

​5. Call transfer

​Checklist

​Next steps

Request an integration

Use a SIP trunk instead

1. Outbound call API

2. Get call by ID API

3. Inbound calls

4. WebSocket streaming

5. Call transfer

Checklist

Next steps