How to Connect a Voice AI Agent to Your Existing Phone Numbers

Yes, you can connect a Voice AI agent to a business number that customers already call without immediately replacing that number. The current phone provider must support either call forwarding or an external SIP destination. With Plivo there are three ways in: forward the calls to a Plivo number, point your carrier’s SIP signaling at a Plivo SIP endpoint, or port the number onto Plivo outright.

The right choice depends on four separate pieces:

1. Public number: The number customers dial
2. Call route: Forwarding, direct SIP, or porting
3. AI voice agent: The conversation logic and tools
4. Business systems: CRM lookups, record creation, transfers, and logging

Keeping those responsibilities separate lets you add an agent without assuming that the entire phone system must change. Microsoft’s telephony documentation describes a similar model: an organization can retain its number, keep existing auto attendants or queues, and route selected paths to a voice agent. Microsoft explains telephony routing for voice agents.

Choose how calls will reach the agent

Your current carrier, PBX, phone system, number type, and country determine which routes are available.

Two places your agent can run

Settle this before you pick a route, because it changes what you hand your carrier.

• Completely on Plivo. You built the flow in AI Agent Studio, or described it to Vibe Agent, and Plivo runs it.
• On your own infrastructure, with Plivo telephony. You run Pipecat, LiveKit Agents or your own stack, and Plivo carries the calls to it.

All three routes work for either. What differs is the destination you configure at the Plivo end:

Three questions for your current provider

Which routes are open to you is a question about your carrier, not about Plivo. Ask them:

1. Can you forward calls from this number to an outside number, and can that be conditional, unanswered calls only or outside business hours? A carrier that only does unconditional forwarding takes the gentlest pilot off the table.
2. Can you deliver calls for this number to an outside SIP destination instead of forwarding them? A yes here is what makes direct SIP possible at all.
3. How would you authenticate to that destination, a fixed source IP we can allowlist, or credentials? Carriers that change IP ranges without notice need credentials rather than an allowlist.

A provider that cannot do the first two leaves porting as the only route, which turns the project from a configuration change into a migration.

Call forwarding

Your existing provider forwards calls to a voice-enabled Plivo number. What that number points at depends on where the agent runs: a flow you built on Plivo, picked in the Call Agent field under Settings then Phone Numbers, or an application that streams the call audio out to your own service.

This is usually the quickest route and does not require SIP knowledge. It can work well for a pilot, overflow calls, or an after-hours route. However, Plivo documents three call legs: the caller reaches the existing provider, that provider makes a forwarded outbound call, and Plivo receives the forwarded call. Those additional legs can affect cost, latency, and the number of places where a call can fail. Plivo’s external-number routing guide describes the setup and trade-offs.

Direct SIP

With direct SIP your carrier stops dialling a second phone number and sends the call signaling straight to Plivo instead. SIP is the protocol that sets up, changes and ends sessions such as calls carried over IP, specified in IETF RFC 3261.

There are two places you can point a carrier at, and the right one depends on where your agent runs.

If you built the agent on Plivo, give it a SIP endpoint of its own. In the console, under Voice then Endpoints, create one and fill in:

• Alias name, a label for your own reference, such as inbound-voice-agent. Letters, numbers, hyphens and underscores are allowed.
• Username, which becomes the endpoint’s SIP address. Alphanumeric only, up to 25 characters, and it has to start with a letter, so voiceagent works. Plivo appends a 12-digit number to keep it unique, giving an address like:

sip:voiceagent204815162342@phone.plivo.com

• Password, at least five characters. Together with the username, this is what your carrier authenticates with.
• Application Type, set to AI Agents, then choose your flow in the AI Agent field.

Hand your carrier that address and those credentials. Calls then arrive on the agent directly, with no Plivo phone number in the middle.

If you are bringing your own runtime, point the carrier at an application instead. Every Plivo application carries its own SIP URI:

sip:{app_id}@app.plivo.com

Plivo reads which application to use from the username part of the SIP URI, not from the To header. Carriers that put the dialled phone number there instead are the single most common reason inbound calls arrive without authentication, so check that first if yours do. Authenticate with an IP access control list where your carrier’s signaling comes from fixed addresses, or with credentials-based auth where those addresses move.

Either way the published number never moves. Your carrier keeps answering for it and simply hands the call onward.

Number porting

Porting moves the number from your current provider to the provider that will manage its telephony and routing. It is not required to deploy an AI voice agent.

In the United States, the FCC says customers changing providers within the same geographic area can generally keep their number. Simple ports generally must be processed within one business day, although more complex changes can take longer. The FCC’s porting guide advises customers not to terminate existing service before initiating new service.

Plivo documents porting for US and Canadian local and toll-free numbers, with a process that can take up to four weeks. Leave your previous carrier billing and running right through cutover; Plivo is explicit about not cancelling early. Plivo’s number-porting documentation lists the required documents, process stages, and common rejection reasons.

As a practical rule:

• Forwarding is the right first move when you want calls hitting an agent this week, whether that is a pilot, spillover, or the hours after your team logs off.
• Direct SIP earns its setup cost once you are past the pilot and want the shortest call path your carrier will give you.
• Porting is a consolidation decision rather than a deployment one: choose it when administering the number in one place and the routing in another has become the annoyance.

What the inbound leg costs

For an agent answering calls on a US local number, Plivo charges $0.0300/min for the agent and $0.0055/min for the telephony, so $0.0355/min for an inbound call.

Forwarding adds a charge Plivo does not bill. Your existing carrier is placing an outbound call to the Plivo number for the full length of every conversation, priced by your contract with them. That second charge, not the Plivo rate, is usually what makes forwarding the costlier route at volume, and it is the clearest financial argument for moving to direct SIP once a pilot has proved itself.

Prepare the phone system, agent, and CRM

Before changing a live route, gather:

• Admin access to whichever carrier, PBX or phone system you are about to change
• Proof your organisation owns the number, which the carrier will ask for
• An agent you have already tested, and somewhere for its calls to land
• A person to transfer to, plus a defined path for when that transfer fails
• For direct SIP, either the source addresses to allowlist or the endpoint credentials
• CRM access scoped to only what the agent needs to do
• A test phone, and a named owner who reads the call and CRM logs afterwards

Build and test the agent before routing customer traffic. Product teams can describe the intended experience in plain English with Vibe Agent, which builds, tests, edits and deploys the agent end to end; AI Agent Studio is the drag-and-drop canvas for doing the same work by hand. If you are bringing your own runtime, SIP Trunking gives it a path to the public network, and Audio Streaming pipes the live call audio to your own service over a WebSocket.

For CRM actions, begin with narrowly defined tasks such as contact lookup, lead creation, appointment creation, and call logging. Plivo App Action Nodes can interact with services such as Salesforce, HubSpot, Zendesk, and Google Sheets, using variables collected during the conversation. See the App Actions documentation.

Know your way back before you change anything

The three routes unwind very differently, and that matters more than the difference in setting them up:

That asymmetry is the real argument for piloting on forwarding. A forwarded route is a setting you can switch off while a caller is still on hold. A ported number is a migration, and undoing it is another migration. Keep the old call flow written down and untouched until you have stopped thinking about rolling back.

Connect the existing number in eight steps

1. Map the current call flow

Record the current destination, business hours, queues, voicemail behavior, transfer numbers, and after-hours rules. This gives you a baseline for testing and a fallback if the agent is unavailable.

2. Limit the first use case

Choose one focused task, such as after-hours intake, appointment scheduling, order lookup, or lead qualification. A narrow first deployment makes it easier to define what the agent may do and when it must transfer the call.

3. Define and test the agent

Specify the greeting, approved knowledge, required caller information, escalation triggers, and prohibited actions. Test common requests, interruptions, ambiguous information, and requests that should go to a person.

4. Select the connection route

Choose forwarding, direct SIP, or porting based on your provider’s capabilities and your operational goal. Do not assume that an external SIP destination or porting is available for every number or country.

5. Configure the number route

Forwarding: in your carrier’s console, set the forward-to target on your published number to the Plivo number you provisioned, and check that number points at the right agent flow or application.

Direct SIP: if the agent runs on Plivo, create the SIP endpoint, attach the agent to it, and give your carrier its address and credentials. If you run your own agent, give the carrier the application SIP URI instead, then apply an IP access control list or credentials, and confirm the provider sends the correct SIP URI.

Porting: submit the required authorization and account documents, prepare the Plivo side before the porting date, and keep the current service active until completion.

6. Configure human handoff

Define when the agent transfers a call, where it transfers the call, how long it waits, and what happens if nobody answers. Capture a callback number before transfer when the business has a real process for returning calls.

7. Add controlled CRM actions

Start with read access and limited record creation. Validate required fields, test with sample contacts, and review how names, phone numbers, addresses, and conversation variables map into the CRM.

8. Test internally, then phase in traffic

Open the smallest possible door first: calls nobody picked up, or the hours after close. Then confirm the published number still rings, the schedule boundary fires at the right minute, a transfer lands on a human, the CRM record carries the right fields, and a deliberately broken agent call still reaches your fallback.

Before a customer hears the agent, dial it yourself and check one named expectation each time.

Worked example: an after-hours main line

A hypothetical, for illustration.

A small field-service company leaves its published number exactly where it is, with the carrier it has always used. After 6 p.m., any call nobody answers is forwarded to a Plivo number sitting in front of an AI voice agent.

The agent takes three things on the call, who is calling, the number to reach them on, and the address the work is at, then searches the CRM. A known customer gets the request filed against their existing record. A stranger becomes a lead the morning team picks up.

When the call meets the business’s own definition of urgent, the agent reads the callback number back, then hands the call to whoever is on call. If nobody picks up, it promises a call back, but only where a real process exists to honour that promise.

Once the route has run quietly for a few weeks, direct SIP is worth a look if the carrier will send signaling to an external destination. It drops a leg out of the path, which is a structural win rather than a guaranteed number on anyone’s dashboard.

Production safeguards and common failures

Running this in production means owning six things at once: a number with a route to the public network, a decision about how calls get to the agent, encryption on the media, scoped credentials into your business systems, a way for a person to take over, and something watching for calls that failed.

Direct SIP and an application audio bridge are different designs. In OpenAI’s direct-SIP architecture, the provider exchanges call audio with OpenAI while the application handles webhooks, session decisions, and business logic. Plivo’s external-number route sends the SIP INVITE to a Plivo application, whose Answer URL can connect the call to an AI agent through a WebSocket stream. In OpenAI’s server audio-bridge design, the application relays audio between the telephony provider and the AI service and manages both connections. OpenAI’s telephony guidance and Plivo’s external-number routing guide describe these routes separately.

For direct SIP, use encrypted signaling and media where supported. The OpenAI guidance uses TLS for SIP signaling and SRTP for audio, and recommends webhook signature verification and deduplication so repeated events do not trigger duplicate actions.

Common problems include:

• Calls never reach the agent: Check forwarding settings, number assignment, SIP URI formatting, and authentication.
• SIP calls are rejected: Review the IP allowlist or SIP credentials, especially after the provider changes its infrastructure.
• The agent answers but nothing happens downstream: look at credential scope, how variables map to CRM fields, how long your API calls are allowed to take, and the transfer rules.
• CRM records are inaccurate: Reduce the agent’s write access, validate fields with test contacts, and send ambiguous cases to staff.
• A transfer rings out: give it somewhere else to land, and capture a number to call back on before the caller hangs up.
• Nobody owns the whole path: write down, per layer, which vendor holds the number, the routing, the caller-ID signing, and the pager when calls start failing.

Compliance and emergency calling

Do not present an AI voice agent as an emergency service. The FCC notes that interconnected VoIP 911 calls can have limitations involving location, callback information, power, and internet connectivity. Review the applicable emergency-calling requirements and your provider’s configuration before routing any emergency-related traffic. Read the FCC’s VoIP and 911 guidance.

If the agent will ever place calls in the US rather than only answer them, the FCC’s February 2024 ruling matters: it put AI-synthesised voices inside the TCPA’s existing rules on artificial and prerecorded calls, which means you need the recipient’s express consent before dialling. See the FCC’s declaratory ruling.

Caller-ID authentication is its own obligation. The FCC requires STIR/SHAKEN across a provider’s IP network, plus a filing in the Robocall Mitigation Database, which is worth confirming your provider has before your traffic rides on them. Review the FCC’s robocall guidance.

You can start building with Plivo or contact the Plivo team to discuss a number-routing design.