Telephony providers

Telephony providers

Telenow speaks to the phone network through six interchangeable carrier integrations. Every platform feature — inbound and outbound AI calls, the dialer, member ringing, warm transfer, recording, campaigns, billing — works the same way regardless of which carrier a number lives on.

You don't pick a provider per call — you pick it when you buy a number (or attach a DID to a SIP trunk). The number's provider then carries everything on that line.

How each one connects

• Plivo, Twilio, Vobiz — classic webhook + media-stream model. Telenow answers the carrier's webhook and bridges bidirectional audio over the carrier's media WebSocket. Vobiz is API-compatible with Plivo, so capabilities match Plivo one-for-one.
• Exotel — Exotel's Voicebot applet connects to Telenow's media endpoint. Transfers ride the Exotel flow (Passthru → Connect), and the Connect leg is recorded by Exotel when recording is enabled on the flow. Numbers are ExoPhones; account KYC is completed in the Exotel console.
• Vonage — Voice API with NCCO call control. Telenow answers with an NCCO that connects the call to its media WebSocket; transfers swap the NCCO live, and the transferred portion is recorded carrier-side and pulled into the call's recording set automatically.
• SIP trunk — native SIP/RTP straight from your carrier or PBX to Telenow, no CPaaS in between. See SIP trunking.

Bring your own carrier (BYOC)

Connect your own account for Plivo, Twilio, Vobiz, Exotel, or Vonage and import its numbers. Calls on those numbers then run over your carrier account and rates while Telenow handles the agent pipeline, media, and recording.

Connect a carrier under Developers → Carriers → Connect carrier. Pick the provider, give it an optional label, and paste its credentials — Telenow imports each owned number automatically on connect (re-pull any time with Sync now). Each provider needs its own fields:

Credentials are encrypted at rest and never returned by the API.

Outbound on BYOC — whose credentials? Outbound dials and live-call transfers use your own credentials on Plivo, Twilio, and Vobiz connections (the dial path resolves the owning connection's creds for any number imported as BYOC). Exotel and Vonage BYOC numbers receive inbound calls and report status against your account, but their outbound legs are placed through the platform's own carrier account — there's no per-call credential override for those two providers yet.

Vonage BYOC + warm transfer — link the number to the platform application. Vonage's Voice API (the REST call that swaps the NCCO to transfer a live call) is authenticated with an application JWT, signed with the application's RSA private key. A BYOC Vonage connection stores your API key, API secret, and Application ID, but not a private key — so Telenow signs all Vonage voice control with the platform Vonage application. For warm transfer (and any mid-call control) to work on a BYOC Vonage number, that number must be linked to the platform Vonage application in your Vonage dashboard. If it's left on your own Vonage application, the agent can still talk to the caller (media flows over the WebSocket), but a transfer is rejected by Vonage (401) because the call is owned by a different application — Telenow surfaces this as a clear "needs to be linked to the platform Vonage application" error rather than a silent failure. Exotel transfers are unaffected: they're dialed by your own App Bazaar flow under your Exotel account, so no platform/BYOC credential question arises.

Compliance

Regulatory paperwork is carrier-specific:

• Plivo and Twilio have full in-app compliance flows (document requirements, submission, and status tracking — Twilio uses Regulatory Bundles). You submit and link these from inside Telenow. See Compliance and Phone numbers.
• Vobiz, Exotel, and Vonage do not have an in-app compliance flow. KYC and number restrictions are handled in the provider's own console (Vobiz/Exotel at the account level, Vonage in the Vonage dashboard) — there is nothing to submit through Telenow for these three.

Platform vs BYOC, and per-provider kill switches

Each CPaaS provider can run on the platform's own carrier account (the deployment's env credentials) or on a BYOC account (your org's credentials, stored encrypted under Developers → Carriers). The two are independent.

An operator can turn off the platform account for any provider with an environment variable — PLATFORM_TELEPHONY_PLIVO, PLATFORM_TELEPHONY_TWILIO, PLATFORM_TELEPHONY_VOBIZ, PLATFORM_TELEPHONY_EXOTEL, PLATFORM_TELEPHONY_VONAGE. Set the value to any of false, 0, off, no, or disabled (case-insensitive) to disable; any other value (or leaving it unset) keeps the provider enabled. The set is resolved once at process start, so a change needs a restart. When a provider's platform account is disabled:

• Outbound dials, warm transfers, and number search/purchase that would use the platform account are refused with a clear message.
• BYOC is unaffected — orgs that connected their own carrier keep full inbound and outbound, because BYOC resolves the org's own credentials.
• Inbound to existing platform numbers still answers — disabling the platform account stops it being used for new outbound/purchases, not from answering calls already routed to it.

Default for every provider is enabled. SIP trunks have their own switch — SIP_ENABLED — since a trunk is always the customer's own carrier, never a platform account.

Channels

An agent can be limited to web or telephony channels in the builder. A web-only agent will not answer inbound PSTN calls on any provider — callers hear the no-agent message instead — and its numbers are best reallocated.