If your website has a public “Call” or “Talk to Bot” button, you usually do not want to create one SIP extension per website visitor. That model does not scale well, creates unnecessary account management overhead, and makes anonymous browser calling much harder than it needs to be.

This is the practical architecture for the public website voice button pattern. Each layer has a clear responsibility, which makes debugging easier and scaling cleaner.

WebRTC does not always connect directly. Browser users can sit behind symmetric NAT, strict firewalls, carrier NAT, office NAT, hotel Wi-Fi, or mobile networks. That is exactly where ICE, STUN, and TURN become critical.

In this deployment model, coturn runs on the Ubuntu application machine and provides TURN relay fallback. Google STUN or another STUN source may help with address discovery, but TURN is what saves difficult real-world networks.

Related reading: ICE vs STUN vs TURN — Complete WebRTC Networking Guide and Why WebRTC Calls Fail Behind NAT (And How TURN Fixes It).

The practical environment this article is based on has the following confirmed direction:

Janus is the WebRTC gateway between your website visitor and your PBX-side bot stack. In this design it is not the final bot brain and not the final PBX. It is the media and signaling bridge that makes anonymous browser access practical.

Related reading: Janus WebRTC Gateway Installation on Ubuntu (Production Guide).

This is the most important PBX-side design decision: Janus should be treated like a plain inbound PJSIP endpoint identified by IP, not as a traditional provider trunk that depends on outbound route logic.

This matters because the FreePBX trunk UI can become misleading in this kind of integration. It encourages provider-style thinking, but your Janus path is really:

Janus SIP INVITE
  -> identify by IP
  -> endpoint janus
  -> context from-janus
  -> extension 70000
  -> Stasis(sixhats-webrtc)

There are two file-level control points that matter most:

🧱 Example: pjsip_custom_post.conf

[janus]
type=endpoint
context=from-janus
disallow=all
allow=ulaw,alaw
direct_media=no
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
transport=0.0.0.0-udp
aors=janus

[janus]
type=aor
max_contacts=10

[janus]
type=identify
endpoint=janus
match=192.168.0.3

📘 Why each line matters

🧾 Example: extensions_custom.conf

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

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

Stasis(...) is the handoff point where normal Asterisk dialplan execution gives control to your ARI application. That is exactly how the PBX-side SIP call enters your custom bot logic.

same => n,Stasis(sixhats-webrtc)

In this example, the ARI app name is sixhats-webrtc. Once the channel enters Stasis, your VoiceBridge / ARI application can inspect, bridge, stream, snoop, or control media according to your design.

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

This design supports concurrency because the browser visitors are handled as Janus-side WebRTC sessions, not as permanent PBX user extensions.

Related scaling article: Scaling a Public “Talk to Bot” Button to Thousands of Concurrent Users.

After saving config and reloading FreePBX / Asterisk, use the CLI to verify each layer.

# Reload configuration
fwconsole reload

# Enter CLI
asterisk -rvvvvv

# Verify endpoint and identify rule
pjsip show endpoint janus
pjsip show identifies

# Verify custom dialplan
dialplan show from-janus

✅ Expected output direction

Endpoint:  janus
  Context: from-janus
  Transport: 0.0.0.0-udp

Identify: janus/janus
  Match: 192.168.0.3/32

[from-janus]
70000 => 1. NoOp(Janus call into ARI for website WebRTC demo)
         2. Answer()
         3. Stasis(sixhats-webrtc)
         4. Hangup()

Turn on SIP logging and place a real browser call through Janus. You want to see the call hit the Janus-matched endpoint and enter the custom context.

asterisk -rvvvvv
pjsip set logger on

Expected SIP direction:

<--- Received SIP request (INVITE) from 192.168.0.3:5060 --->
INVITE sip:70000@192.168.0.4 SIP/2.0
...
From: ...
To: <sip:70000@192.168.0.4>

Expected dialplan execution:

Executing [70000@from-janus:1] NoOp("PJSIP/janus-00000012", "Janus call into ARI for website WebRTC demo") in new stack
Executing [70000@from-janus:2] Answer("PJSIP/janus-00000012", "") in new stack
Executing [70000@from-janus:3] Stasis("PJSIP/janus-00000012", "sixhats-webrtc") in new stack

This confuses many teams. The Janus endpoint can appear Unavailable in FreePBX-style status views even when the Janus-to-Stasis call path is functioning correctly.

So for this integration, the real test is not: “Do I see a green status bubble in the trunk page?”

The real test is:

• ✅ Does Asterisk identify Janus by source IP?
• ✅ Does the call enter from-janus?
• ✅ Does extension 70000 execute?
• ✅ Does Stasis(sixhats-webrtc) run?

It is important to separate call-entry success from media-path success. These are related, but they are not the same troubleshooting layer.

📋 Copy-paste command block

# Reload FreePBX / Asterisk safely
fwconsole reload

# Enter Asterisk CLI
asterisk -rvvvvv

# Verify Janus endpoint objects
pjsip show endpoint janus
pjsip show identifies

# Verify custom dialplan
dialplan show from-janus

# Enable SIP logging for live test
pjsip set logger on