What actually works today
SIP peering — shipped
Point Asterisk/FreeSWITCH at your workspace’s SIP endpoint (or the reverse).
Calls flow both directions over standard SIP + G.711 RTP. This is a
supported, live capability.
Phased cutover — the method
Bridge the two systems, move numbers and outbound routes incrementally, and
decommission the old boxes once traffic has drained. No flag day.
The migration in one picture
Peer the two systems
Add TeleQuick as a SIP trunk on your Asterisk/FreeSWITCH box (or add your
box as a trunk in the workspace). Prove a test call flows each way. Nothing
in production changes yet.
Run side by side
Send a small slice of traffic — one DID, one queue, or your internal test
extensions — into the workspace while everything else stays on the old
system. Watch call quality, answer ratio, and MOS in the reports.
Move trunks and numbers
Re-point carrier trunks and DIDs onto the workspace one route at a time.
Each move is independently reversible.
Rebuild flows natively
Recreate the dialplans, IVR menus, and queues you actually still want as
workspace IVR/ACD programs and AI agents — this is where the value is, and
it is manual, deliberate work, not an import.
Step 1 — Peer Asterisk / FreeSWITCH as a SIP trunk
There are two directions you can peer, and most migrations use both at different phases.- Old PBX → workspace (recommended first)
- Workspace → old PBX
Configure TeleQuick as an outbound SIP trunk on your existing box, so
Asterisk/FreeSWITCH can hand selected calls to the workspace. This lets you
front an AI agent or a new IVR flow with your existing number plan still in
charge of routing.On the workspace side, create a trunk whose peer is your PBX’s signalling
address, with Realm = Internal (it is your own equipment, not a
per-minute carrier). Follow SIP Trunking
for the full field walkthrough. On the Asterisk/FreeSWITCH side, define a
normal SIP/PJSIP trunk pointing at your workspace’s SIP endpoint:Offer G.711 (PCMU/PCMA) on the trunk — it is the universal phone codec
and needs no transcoding on either side.
Throughout this page, Asterisk and FreeSWITCH refer to the external
systems you are migrating away from. TeleQuick is not built on either — its
gateway is an independent implementation. The dialplans,
extensions.conf
logic, and FreeSWITCH XML you have today are configuration for those external
products and do not carry over; you rebuild the equivalent behaviour natively.Step 2 — Run both systems side by side
The point of peering first is that you can validate TeleQuick with real traffic while your old deployment stays authoritative. Good first slices to move:- Internal test extensions — dial from a softphone through the peer trunk into a workspace test agent.
- One low-volume DID — a support line or an after-hours number where a regression is survivable.
- Overflow only — let the workspace take calls the legacy queue rejects.
Step 3 — Move trunks and numbers
Once a route behaves well in parallel, make the workspace authoritative for it.Re-point the carrier trunk
Update your carrier/SBC to send that DID’s INVITEs to
<workspace-id>.sip.telequick.dev instead of your old PBX. Or, if you
prefer not to touch the carrier yet, keep the carrier pointed at the old box
and let it forward the DID over the peer trunk from Step 1 — both work; the
direct re-point removes a hop.Register the number in the workspace
Add the DID to your workspace inventory and bind it to a trunk, an AI agent,
or an IVR/ACD flow. See Number Provisioning.
Route the inbound call
Decide what answers: an AI agent, a play-and-hangup announcement, or a full
IVR/skill queue. See Inbound Calls
and PBX & ACD.
Step 4 — Rebuild call flows natively
This is the part that is deliberately not an import. Your Asterisk dialplan or FreeSWITCH XML encodes years of accreted behaviour; a migration is the moment to keep what matters and drop what does not. Map the concepts by hand:| On Asterisk / FreeSWITCH | Native equivalent in TeleQuick |
|---|---|
| SIP/PJSIP trunk profile | A workspace trunk (SIP Trunking) |
extensions.conf / XML dialplan | Inbound routing rules + IVR/ACD programs (PBX & ACD) |
Queues / agents (queues.conf) | Skill queues + agent endpoints (PBX & ACD) |
IVR menus (Read/Background) | IVR steps with prompt playback and digit collection |
| Registered SIP phones | Agent endpoints — browser softphones or real SIP deskphones (PBX & ACD) |
| AGI / dialplan apps / bots | An AI agent — bring your own ASR/LLM/TTS or speech-to-speech (Runtime) |
Why teams do this
TeleQuick’s gateway is a modular, shard-per-core engine with an in-process RTP media plane, so it carries far more concurrent audio per CPU than a traditional channel-driver PBX. In one media-plane benchmark on identical hardware, the workspace engine sustained roughly 3.7× more calls per unit of CPU than Asterisk 20.6 (chan_pjsip) — see Benchmarks
for the exact scenario, hardware, and caveats before you quote it.
That figure is a media-plane measurement under a specific G.711 playback
scenario, not a promise about your workload. Both systems in that test were
capped on call-setup, not media. Validate against your own traffic during
the side-by-side phase before you plan capacity around it.
Next steps
Migration overview
The general phased-cutover playbook this page specializes.
Migration checklist
A step-by-step cutover checklist to work through.
SIP trunking
Wire the peer trunk field by field.
PBX & ACD
Rebuild queues, IVR, and agent routing natively.