How to Setup Your AI Bot to PSTN Using Stasis in Asterisk and MYLINEHUB VoiceBridge

If you want your AI bot to answer real phone calls from PSTN, SIP trunk, FreePBX, or WebRTC, the key handoff point is usually the Stasis application in Asterisk.

In simple terms, your telecom path receives the live call, Asterisk routes it through dialplan, and then Stasis() hands that live channel to your application so something like MYLINEHUB VoiceBridge can take over the bot flow in real time.

That is the bridge between ordinary telephony and application-controlled AI calling.

🧭 End-to-end idea: AI bot to PSTN call flow

Before going deep into Stasis itself, it helps to see the full architecture in one visual.

What Is Stasis in Asterisk ARI? How Dialplan Hands Control to Your App

In normal Asterisk call flows, the dialplan decides what happens next. It answers calls, plays prompts, jumps between extensions, dials phones, runs queues, and hangs up when logic is done.

But what if you do not want fixed dialplan-only behavior? What if you want your own application to control the call in real time?

That is exactly where Stasis comes in.

Stasis is the handoff point where Asterisk stops normal dialplan-driven handling and gives control of the channel to your ARI application.

In simple words: Stasis is the doorway from dialplan world into application-controlled telecom. 🚪

🎯 One-line definition

Stasis is an Asterisk application used in the dialplan to send a live channel into an ARI app, so external software can control the call.

That external software can be a bot, a call automation engine, a monitoring app, a custom IVR controller, or something like MYLINEHUB VoiceBridge.

🧭 First understand the difference: dialplan control vs app control

📘 What is ARI first?

Before understanding Stasis deeply, you need one clean foundation: ARI = Asterisk REST Interface.

ARI is the modern API-based control layer in Asterisk. It lets an external application do things like:

• receive channel events
• create bridges
• move channels into bridges
• start and stop recordings
• inspect channel state
• create media flows around a call
• build custom telecom apps outside static dialplan logic

But ARI needs a clean entry point. That entry point is Stasis() in the dialplan.

🛠️ The simplest possible Stasis example

In dialplan, you may write something like:

[incoming-bot]
exten => 7000,1,NoOp(Call entering ARI app)
 same => n,Answer()
 same => n,Stasis(voicebridge)
 same => n,Hangup()

What this means:

1. A call reaches extension 7000
2. Asterisk answers the call
3. The channel is sent into the Stasis app named voicebridge
4. Your ARI-connected application now receives events and starts controlling the call

🔄 What actually happens when a call hits Stasis

📥 What event does the app receive?

When a channel enters your Stasis application, ARI sends an event like: StasisStart.

Your application now knows:

• a new channel has entered
• which channel it is
• what endpoint or caller is involved
• which Stasis app was targeted
• what logic should start next

Conceptually it is like this:

Event: StasisStart
Channel: 1712345678.45
App: voicebridge
Caller: +919999999999
State: Up

=> Your application reacts here
=> It may create a bridge
=> It may attach media
=> It may send audio to AI
=> It may route the call elsewhere

🧠 Why Stasis matters so much

Stasis is not just another dialplan function. It changes the control model of the call.

Without Stasis:

• dialplan stays in charge
• call logic is mostly static
• advanced real-time bot control is hard
• full duplex voice orchestration becomes difficult

With Stasis:

• your application becomes the decision-maker
• you can build custom bridge logic
• you can integrate RTP paths to AI systems
• you can create browser-to-bot, PSTN-to-bot, SIP-to-bot flows
• you can go beyond old IVR behavior into real-time app-controlled calling

🏗️ Where Stasis sits in the telecom stack

🔌 Is Stasis media itself?

No. This is one of the most important things to understand.

Stasis is not the RTP stream.
Stasis is not the audio codec.
Stasis is not the AI engine.

Stasis is the control handoff. It tells Asterisk: “This channel now belongs to my application logic.”

After that, your ARI app can decide whether to:

• bridge the call to another endpoint
• create a mixing bridge
• attach ExternalMedia
• record the call
• inject prompts
• route to AI and back

🤖 So how does this connect to a bot?

This is where the topic becomes powerful.

A bot does not magically “live inside the phone call.” In real systems, the call must be:

• received by Asterisk
• routed in dialplan
• handed to a custom app via Stasis
• connected to external media logic
• linked to STT / AI / TTS / RTP handling

So if you want a live AI bot on PSTN, SIP, or browser-originated voice, Stasis is usually the moment where bot orchestration begins.

🚀 How MYLINEHUB VoiceBridge uses Stasis

This is exactly why Stasis is such a central idea in MYLINEHUB VoiceBridge.

That is why Stasis is not just a theory topic for MYLINEHUB. It is one of the practical foundations that allows VoiceBridge to connect telecom traffic to real application intelligence.

📞 PSTN to bot: where Stasis fits

Let us take a real business telephony example.

A customer dials your business number:

1. Call enters through SIP trunk / PRI / gateway into Asterisk
2. Dialplan maps that incoming call to a destination
3. Instead of only playing IVR logic, dialplan runs Stasis(voicebridge)
4. VoiceBridge receives the channel through ARI
5. VoiceBridge decides how to bridge media to AI
6. AI processes user speech
7. Audio comes back to caller

Without the Stasis handoff, your app never gets real-time call control in the same clean way.

🌐 Browser button to bot: where Stasis still matters

The same idea also applies when the user does not call from PSTN, but from a website voice button.

For example, a browser may first connect through a WebRTC infrastructure layer such as Janus. Janus may then route SIP/WebRTC traffic into Asterisk. Once Asterisk receives that session as a channel, the dialplan can again hand the channel into: Stasis(voicebridge).

So even when the journey begins with a browser button, Stasis still becomes the key point where:

• raw telecom signaling reaches Asterisk
• dialplan identifies the bot route
• control is passed to the app
• VoiceBridge begins the actual AI call orchestration

🧪 Why Stasis is better than trying to force everything into AGI

Many people first try to imagine AI voice bots through old AGI-style thinking. But AGI is not built for true real-time duplex media control in the same way.

High-level difference:

This is why a serious product like VoiceBridge is exciting: it uses the modern control model needed for real telecom + AI integration instead of stopping at old script-style automation.

🧱 What Stasis does not do by itself

It is important not to over-credit Stasis. Stasis is powerful, but by itself it does not automatically give you:

• duplex AI audio
• packet timing discipline
• RTP direction correctness
• NAT safety
• barge-in behavior
• latency optimization
• production observability

Those things come from the architecture you build after the Stasis handoff. That is exactly where a mature implementation like VoiceBridge becomes valuable.

🔍 Conceptual event flow inside a Stasis-powered bot call

🛠️ How to create the Stasis route in FreePBX for your AI bot

If your entry path is Janus → FreePBX → Asterisk ARI → VoiceBridge, the practical FreePBX job is to accept the SIP call from Janus, place it into the correct context, and route extension 70000 into Stasis(sixhats).

🗺️ FreePBX flow overview: where the Stasis app is created

1️⃣ Create the PJSIP trunk in FreePBX

In FreePBX, go to:

Connectivity
→ Trunks
→ Add Trunk
→ Add PJSIP Trunk

This trunk is the landing point for SIP traffic coming from Janus into FreePBX before the call is sent into the custom dialplan context.

2️⃣ General tab values in FreePBX

3️⃣ Dialed Number Manipulation Rules

Leave everything empty. This trunk is not being used to dial out to a carrier, so digit manipulation rules are not needed.

4️⃣ PJSIP Settings → General

5️⃣ PJSIP Settings → Advanced

The most important line is Match (Permit) = 192.168.0.3/32. That is what tells Asterisk which source IP is allowed to be matched as the Janus endpoint.

6️⃣ Codecs tab

Enable only:

ulaw
alaw

Disable everything else, especially:

opus
g722
g729
gsm
all video codecs

This keeps the media path aligned with the VoiceBridge side when VoiceBridge is expecting ulaw or alaw. Janus can handle the browser codec side and convert toward the SIP side.

7️⃣ Save and apply config

After saving the trunk in FreePBX, click:

Submit
Apply Config

Equivalent CLI reload:

fwconsole reload

8️⃣ Create the custom Stasis dialplan in FreePBX / Asterisk

Now create the actual handoff into the ARI bot application. SSH into the FreePBX server and edit the custom dialplan file:

ssh root@192.168.0.4
nano /etc/asterisk/extensions_custom.conf

Add this block at the bottom:

[from-janus]
exten => 70000,1,NoOp(Janus call into ARI for sixhats webrtc demo)
same => n,Answer()
same => n,Stasis(sixhats)
same => n,Hangup()

exten => _X.,1,Hangup(403)

9️⃣ What each dialplan line does

🔁 Reload after editing the custom dialplan

fwconsole reload

✅ Verify that FreePBX is really routing to your Stasis app

Open the Asterisk CLI:

asterisk -rvvv

Check that the endpoint exists:

pjsip show endpoints

Expected:

Endpoint: janus

Check the IP identify match:

pjsip show identifies

Expected:

Identify: janus/janus
Match: 192.168.0.3/32

Check the dialplan:

dialplan show from-janus

Expected:

[from-janus]
70000 => 1. NoOp(...)
         2. Answer()
         3. Stasis(sixhats)
         4. Hangup()

🧪 SIP debugging: prove the call is reaching ARI

Inside the CLI run:

pjsip set logger on

When Janus sends the call, you should see something like:

INVITE sip:70000@192.168.0.4

Executing [70000@from-janus:1] NoOp(...)
Executing [70000@from-janus:2] Answer()
Executing [70000@from-janus:3] Stasis(sixhats)

Once you see the Executing ... Stasis(sixhats) line, you know the call has successfully reached the ARI entry point.

🎛️ Visual summary: where the AI bot is “created” in FreePBX

📞 Final working call flow for this FreePBX setup

Browser
│
│ WebRTC
▼
Janus (192.168.0.3)
│
│ SIP INVITE
▼
FreePBX trunk "janus"
│
Context: from-janus
│
Extension: 70000
│
Stasis(sixhats)
│
VoiceBridge ARI

That is the exact path that turns a browser or telecom-originated voice session into an app-controlled AI bot call.

📎 Typical beginner confusion points

1) “If I use Stasis, does dialplan end?”
Practically, control shifts to your app. Dialplan is no longer the main logic engine for that live channel in the same simple way.

2) “Does Stasis mean audio goes to my app automatically?”
No. Stasis gives control. Media path handling must still be designed properly using the right ARI/media architecture.

3) “Can I build an AI bot without Stasis?”
You can build limited things in many ways, but serious real-time application-controlled bot flows become much cleaner with Stasis + ARI.

4) “Is Stasis only for PSTN?”
No. It works wherever Asterisk is receiving the channel — SIP trunk, internal SIP, WebRTC-to-SIP path, Janus-routed path, etc.

5) “Is Stasis the same as VoiceBridge?”
No. Stasis is the handoff mechanism. VoiceBridge is the larger application architecture that uses that handoff intelligently.

💡 Why VoiceBridge is impressive in this context

The exciting part is not merely that VoiceBridge “uses ARI”. The exciting part is what it makes possible after the Stasis handoff.

Once the call enters the VoiceBridge app path, the system can move beyond static IVR and become:

• application-driven
• RTP-aware
• AI-connected
• duplex-focused
• database-configurable
• scalable across real telecom scenarios

That is why Stasis matters: it is the clean gate that allows the VoiceBridge architecture to take over in a controlled, production-oriented way.

🔗 What to read next

To understand this topic properly, these articles should be read next in order:

1. Canonical VoiceBridge overview
https://mylinehub.com/articles/open-source-full-duplex-asterisk-ai-voice-bot-bridge-voicebridge

2. Deep dive into the full media pipeline
https://mylinehub.com/articles/voicebridge-architecture-deep-dive-asterisk-rtp-ai-rtp-asterisk

3. How production full duplex is actually achieved
https://mylinehub.com/articles/how-voicebridge-achieves-true-full-duplex-audio-in-production

4. Why AGI is not enough for this class of voice bot
https://mylinehub.com/articles/why-agi-cannot-provide-real-time-duplex-voice-technical-limits

5. ExternalMedia one-way audio root causes
https://mylinehub.com/articles/asterisk-voicebridge-externalmedia-one-way-audio-root-causes-fixes

6. Sending audio back correctly using ARI ExternalMedia
https://mylinehub.com/articles/send-audio-back-to-caller-using-ari-externalmedia-working-rtp-guide

7. Snoop vs ExternalMedia vs AudioSocket comparison
https://mylinehub.com/articles/snoop-channel-vs-externalmedia-vs-audiosocket-true-full-duplex-comparison

8. DB-driven runtime configuration in VoiceBridge
https://mylinehub.com/articles/voicebridge-db-driven-runtime-configuration-explained

9. Browser button architecture reaching Asterisk from WebRTC side
https://mylinehub.com/articles/webrtc-website-voice-button-ai-bot-architecture

10. If you want the wider technology overview
https://mylinehub.com/articles/mylinehub-architecture-and-technology-stack

✅ Final takeaway

If you remember only one thing, remember this:

Stasis is the exact moment where Asterisk stops only following dialplan and lets your application take live control of the call.

That is why it matters so much for bots, ARI apps, media orchestration, and advanced telecom control.

And that is also why it matters so much for MYLINEHUB VoiceBridge: it is one of the cleanest foundations for moving from ordinary telephony into real application-controlled AI calling.

In other words: no Stasis handoff, no clean app-owned VoiceBridge-style flow. 🎯