Telephony providers

Telephony providers

Telenow speaks to the phone network through seven 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. There is no answer webhook: the dial names an App Bazaar flow, which is why an Exotel connection needs an App ID as well as credentials (setup guide). Transfers ride that same flow (Passthru → Connect). Numbers are ExoPhones; account KYC and prepaid credit are handled in the Exotel console, and both gate outbound calling.
• Tata Tele Smartflo — Smartflo's Voice Streaming connects to Telenow's media endpoint, the same shape as Exotel but over Twilio's Media Streams wire format. There is no answer webhook and no dial plan to author: you register Telenow's wss:// URL as a VOICE Bot in Smartflo's Channels Hub, then point a DID at it (inbound) and select it as the destination of a Click to Call Support API key (outbound). See the Smartflo setup guide. Two things differ from every other carrier here: outbound needs a per-number API key rather than one account credential, and warm transfer is not available — Tata exposes no live-call redirect on a voice-streaming leg, so Telenow refuses a transfer on a Smartflo number rather than failing halfway through one.
• 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, Vonage, or Tata Tele Smartflo and import its numbers. (Smartflo is BYOC-only — there is no platform Smartflo account to fall back on.) 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.

Smartflo tokens expire — and cannot be refreshed. A token generated in the Smartflo portal is valid for a fixed 1, 7, 15, 30, or 90 days, chosen when you create it, and there is no renewal API. When it lapses, number sync and outbound dialling stop and the connection shows a credentials error; re-generate the token in Smartflo and paste it into the same connection (Telenow updates it in place rather than creating a duplicate). Put the expiry date in a calendar when you connect.

Outbound on BYOC — whose credentials? Outbound dials and live-call transfers use your own credentials on Plivo, Twilio, Vobiz, and Exotel connections — the dial path resolves the owning connection's creds for any number imported as BYOC. Exotel additionally needs its App ID, because an Exotel dial names a call flow in your account rather than calling back for instructions; see Exotel App Bazaar setup. Vonage BYOC numbers receive inbound calls and report status against your account, but their outbound legs are still placed through the platform's own carrier account — there's no per-call credential override for Vonage 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, Vonage, and Tata Tele Smartflo do not have an in-app compliance flow. KYC and number restrictions are handled in the provider's own console (Vobiz/Exotel/Smartflo at the account level, Vonage in the Vonage dashboard) — there is nothing to submit through Telenow for these four.

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_SMARTFLO, 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.