Quick answer: There are three paths. 3CX AI Edition has native AI Agents, using OpenAI or xAI Grok with one provider active at a time. FreePBX or Asterisk reach an agent platform through a PJSIP trunk: G.711, RFC 4733 DTMF, direct_media=no, and a REFER back into a fenced context. AudioSocket carries keypad digits only from Asterisk 20.14.0, 21.9.0 or 22.4.0 onward.
If you are asking “how do I connect an AI voice agent to my existing 3CX or FreePBX phone system?”, this page is about the side you already own: the trunk the agent sits behind, the codecs and DTMF mode the PBX offers, NAT and registration, and how the agent hands a caller back to a desk phone or ring group. The carrier side of a bring-your-own trunk is covered in our guide to connecting an AI agent to your own SIP trunk. Pointing a session border controller straight at a model provider is covered in direct SIP with no Twilio in the path. Getting the caller’s number to the agent before it speaks is covered in passing the caller’s number and SIP headers into the agent.
Vendor facts below come from 3CX, LiveKit, Pipecat and Asterisk’s own pages, read on 26 September 2026. The Asterisk configuration was run that day on two sandboxed Asterisk 20.6.0 instances, one playing the PBX and one standing in for the agent platform.
How do I connect an AI voice agent to my existing 3CX or FreePBX phone system?
Pick the path your PBX and your agent can both speak. The PBX decides more of this than the agent does.
- 3CX native AI Agents. The agent lives inside 3CX as an extension. 3CX’s AI Agents configuration guide says 3CX supports OpenAI and xAI Grok (Update 10 and above), “and only one provider can be active at a time”, and that the feature requires 3CX AI Edition. You configure the provider under Admin Console > Integrations > AI > Realtime API. There is no SIP trunk to build.
- The PBX as a SIP peer of an agent platform. FreePBX, Asterisk and 3CX alike: a trunk to the platform’s SIP host, one DID sent to it, and a SIP REFER back when a person should take over. Most of this page is about this path.
- Asterisk media sockets. Asterisk hands raw audio to your own agent process over TCP (AudioSocket) or a WebSocket (chan_websocket). Only for teams writing their own agent pipeline, and version-dependent.
The PBX Handoff Matrix puts them side by side; every cell comes from the vendor’s own page or our sandbox run.
| Path | PBX it fits | How audio travels | Codec | Keypad digits (DTMF) | Handing back to a person | Gate you must clear first |
|---|---|---|---|---|---|---|
| 3CX native AI Agent | 3CX with AI Edition | WebRTC to the provider after SDP exchange; outbound TCP 443 for signalling, UDP 3478 for media | PCMU (3CX technical note) | Not stated in the two 3CX AI Agent guides we read on 26 September 2026 | Route by Topic rules; Human Handoff and Escalation Topics for Customer Service Agents; an “AI unavailable” fallback destination | AI Edition; a provider account (the OpenAI guide requires a paid OpenAI account); 3CX Firewall Checker passing |
| PJSIP trunk to an agent platform (LiveKit as the worked example) | FreePBX, Asterisk, 3CX generic trunk | SIP plus RTP between the PBX and the platform | LiveKit defaults: PCMU, PCMA, G722 | RFC 4733, telephone-event/8000 (LiveKit); the Asterisk default is rfc4733 | SIP REFER from the platform; the PBX places the caller in the trunk’s dialplan context | LiveKit lists SIP REGISTER as not supported, so the PBX must reach the platform without registering |
| AudioSocket | Asterisk, including FreePBX’s Asterisk | TCP; 3-byte header, 16-bit signed linear PCM | slin at 8 kHz (type 0x10) and higher rates | Type 0x03, but only from Asterisk 20.14.0, 21.9.0 and 22.4.0 | Your own code has to redirect the channel | Asterisk version; our 20.6.0 run passed 0 DTMF frames |
| chan_websocket | Asterisk 20.16.0, 21.11.0, 22.6.0, 23.0.0 and later | WebSocket: binary frames for media, text frames for control | Most Asterisk codecs; ulaw or alaw arrive as 160 bytes every 20 ms | DTMF_END events on text frames | Your own code | Asterisk version; Pipecat’s Asterisk Frame Serializer is community-maintained |
The one-line version: 3CX AI Edition is the only path where the PBX vendor owns the whole call; on every other path, the trunk’s context, codecs and DTMF mode are yours to get right.
The setup sequence, in order, for FreePBX and Asterisk
This is the PJSIP trunk path. Steps 1 and 7 are the ones people skip.
- Day one: run
asterisk -Von the PBX and pick one spare DID. The version decides your media options. The spare DID is your pilot; leave the main IVR alone until the pilot reaches the finish state below. - Create the platform side first. On LiveKit, that means an inbound trunk whose
numberslist contains the exact number your PBX will put in the To header, plusauth_usernameandauth_password. Then add a dispatch rule. LiveKit’s own inbound trunk page says that if you leavenumbersempty, you must set a username and password orallowed_addresses, and thatallowed_addresses“must be enabled for your project” by LiveKit support. - Add the trunk on the PBX as a PJSIP endpoint, AOR, auth and identify section (the exact file is in the next section). On FreePBX this is the Trunks module, Add SIP (chan_pjsip) Trunk. Sangoma’s own PJSIP trunk example uses Registration: None for an IP-authenticated provider; do the same for a platform that does not accept registrations.
- Offer G.711 and RFC 4733 only (
allow=ulaw,allow=alaw,dtmf_mode=rfc4733). Add G.722 once narrowband works. - Keep the PBX in the media path with
direct_media=no; behind NAT, also set the three NAT options on the transport and open your RTP range. - Route the pilot DID to the trunk with a one-line inbound route that dials the platform’s number and nothing else.
- Build the fence before the first transfer: a dedicated context for the trunk listing only the extensions and ring groups the agent may send callers to.
- Place four test calls from an outside phone: plain audio, keypad digits, a transfer to an allowed extension, and a transfer to a number that is not allowed.
The finish state. You are done when all five of these hold on the pilot DID. The authenticated INVITE draws a 200 OK. Audio runs both ways for at least 30 seconds without a media timeout; LiveKit ends a call if no RTP arrives within 30 seconds of the media connection being set up. Keypad digits reach the agent as telephone-event packets. A REFER to a listed extension ends in a NOTIFY carrying SIP/2.0 200 OK. A REFER to an unlisted number ends in a NOTIFY carrying a 4xx. Four out of five is not a working integration.
The PJSIP trunk we ran, line by line
This is the configuration we put on the PBX instance. The test copy of pjsip.conf differed only in four placeholder values: the bind address, the password, the platform’s host and the identify match. We diffed the two files to confirm that. In the test extensions.conf, extension 1001 dialled a stub that answered in place of a desk phone, and extra contexts simulated the caller.
; pjsip.conf on the PBX (Asterisk 20; on FreePBX use the equivalents in the trunk form)
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
; Only if the PBX sits behind NAT (the Asterisk NAT example uses these three):
;local_net=192.168.1.0/24
;external_media_address=203.0.113.10
;external_signaling_address=203.0.113.10
[ai-agent]
type=endpoint
transport=transport-udp
context=from-ai-agent
disallow=all
allow=ulaw
allow=alaw
dtmf_mode=rfc4733
direct_media=no
rtp_symmetric=yes
rewrite_contact=yes
aors=ai-agent
outbound_auth=ai-agent-auth
[ai-agent-auth]
type=auth
auth_type=userpass
username=pbx-trunk
password=REPLACE_WITH_TRUNK_PASSWORD
[ai-agent]
type=aor
contact=sip:AGENT_SIP_HOST
[ai-agent-identify]
type=identify
endpoint=ai-agent
match=AGENT_SIGNALLING_IP; extensions.conf on the PBX
[pilot-did]
; the To user must match the number on the agent platform's inbound trunk exactly
exten => 5550100,1,Dial(PJSIP/+15105550100@ai-agent,30)
same => n,Hangup()
[from-ai-agent]
; a REFER from the agent can only reach what is listed here
exten => 1001,1,Dial(PJSIP/1001,20)
same => n,Hangup()The +15105550100 is the example number from LiveKit’s inbound trunk page. Replace it with your own number, in the exact format your platform trunk lists it. The identify section’s main job is to recognise calls the platform starts toward the PBX. For match, Asterisk accepts a comma-delimited list of IP addresses, subnets or hostnames.
| Option | Value we set | Asterisk default (res_pjsip reference) | What it does here | What you see if it is wrong |
|---|---|---|---|---|
direct_media |
no | yes | Keeps RTP flowing through the PBX, which the Asterisk NAT example requires | Asterisk can step out of the media path, leaving RTP aimed at a private address the platform cannot route to |
dtmf_mode |
rfc4733 | rfc4733 | Sends digits out of band as RTP events | With inband, digits are sent as part of the audio stream, so the agent side has to detect tones in audio |
rtp_symmetric |
yes | no | “Send RTP back to the same address/port we received it from” | One-way audio when either side is behind NAT |
rewrite_contact |
yes | no | Replaces the far end’s Contact with the source address and port it actually used | Requests back to a NATed peer can go to the address it advertised rather than the one it sent from |
outbound_auth |
ai-agent-auth | empty | Answers the platform’s digest challenge | 401 Unauthorized, then nothing |
allow_transfer |
left at default | yes | Lets the PBX accept a REFER on this endpoint | Set to no, and SIP REFER transfers from this endpoint are not allowed |
context |
from-ai-agent | default | Where both inbound calls and REFER targets from the platform are looked up | Point it at your internal context and the agent can reach every extension and outbound route |
What our sandbox run proved, and what it did not
We extracted Ubuntu 24.04’s Asterisk package (20.6.0) into a scratch directory and ran two instances on one host. Instance A was the PBX, running the configuration above. Instance B stood in for the agent platform. It challenged every INVITE for a username and password, standing in for a platform trunk configured with auth_username and auth_password. It answered, listened for eight seconds, then sent a REFER. A simulated caller on A played a 440 Hz tone and pressed 4, 2 and #.
| Check | What we did | Result, 26 September 2026 |
|---|---|---|
| Digest authentication | First INVITE from the PBX, no credentials | 401 Unauthorized, then a re-sent INVITE with credentials, then 200 OK |
| Codec offer | Read the SDP in the INVITE | Payload types 0 (PCMU), 8 (PCMA) and 101 (telephone-event/8000); PCMU chosen |
| INVITE size on UDP | Byte count of the authenticated INVITE | 1,281 bytes with those three payload types |
| Keypad digits | Caller pressed 4, 2, #; RTP debug on the stand-in | All three digits reported on the stand-in’s channel; 15 RTP packets of payload type 101 |
| Transfer to a listed extension | Stand-in sent REFER with Refer-To: sip:1001@ the PBX |
202 Accepted, a NOTIFY carrying 100 Trying, a NOTIFY carrying 200 OK; the caller landed on 1001 in from-ai-agent |
| Transfer to an unlisted number | Same REFER, to sip:0290001234@ the PBX |
202 Accepted, then a NOTIFY carrying 404 Not Found; the transfer failed |
| AudioSocket, both the application and the channel driver | Streamed a call to a small Python peer we wrote, while the caller pressed 4, 2, # | 342 audio frames of type 0x10 (109,440 bytes) in the saved capture; 0 DTMF frames with either the application or the channel driver |
The AudioSocket arithmetic is simple. 342 frames at 320 bytes each is 109,440 bytes. At 8,000 samples a second and 2 bytes a sample, that is 16,000 bytes a second, so 6.84 seconds of audio in 20 ms frames. The digits reached the Asterisk channel and went no further.
What this run did not prove: it did not touch LiveKit, 3CX or FreePBX’s GUI, and the stand-in was Asterisk, not any particular platform. There was no NAT and no real desk phone (1001 was a dialplan stub), and the commented NAT lines were not exercised. The file parses, authenticates, negotiates, relays digits and honours REFER on Asterisk 20.6.0; it is a starting point, not a certificate for your network.
The 202 is not a transfer: reading a REFER on your PBX
The 202 Rule: a 202 Accepted only means the PBX agreed to try; the transfer’s result arrives later, in a NOTIFY. In our run, the failed and the successful transfer both began with the same 202 Accepted; only the final NOTIFY (200 OK or 404 Not Found) told them apart. An agent that logs success on the 202 will report transfers to nowhere as successes. The agent-side failures are covered in why an AI voice agent’s transfer to a human fails. LiveKit handles this on its side. Its call forwarding page says the REFER “doesn’t complete until the destination answers”, and it caps the wait with ringing_timeout, which “defaults to 30 seconds”. After that, “the caller stays in the room”.
The context is the fence. In our run, the REFER’s user part (1001) was looked up in the context named on the trunk’s endpoint, from-ai-agent. A number missing from that context was refused. Whatever the trunk’s context can dial, the agent can send a caller to, including outbound routes if the context includes them. List the permitted extensions and ring groups there, and nothing else.
FreePBX users should check which context their trunk form names. Sangoma’s own PJSIP trunk example sets Context to from-pstn, the context where FreePBX matches inbound DIDs. We did not run a REFER through a FreePBX GUI trunk. Place the “unlisted number” test call before you rely on transfers there.
On 3CX’s native agents, the equivalents are settings rather than dialplan. For Customer Service Agents, 3CX documents Human Handoff (“the default destination when the AI Agent cannot resolve the caller’s issue or the caller requests a human”) and Escalation Topics. It also documents a “Check availability before transferring” option, and an “AI unavailable” destination for when the provider cannot be reached.
DTMF and codecs: what the PBX should offer the agent
Offer G.711 in both companding laws and RFC 4733 events. RFC 4733 (IETF, December 2006) obsoletes RFC 2833, so a trunk form saying “RFC 2833” means the same mechanism. LiveKit’s DTMF page says digits travel “over RTP using the telephone-event/8000 payload format”, which is what our PBX offered, on payload type 101.
Three details matter at the PBX:
- G.722 is optional, and a quiet downgrade is normal. LiveKit’s default SIP codecs are PCMU, PCMA and G722. If your PBX offers only G.711, the call connects in narrowband without any error. 3CX’s OpenAI guide lists PCMU as the audio codec for its native agents.
- Packet size on UDP. LiveKit warns that each codec added to the SDP makes the INVITE bigger, and that on UDP large packets can fragment and get lost on some networks. Ours was 1,281 bytes with three payload types; if you plan to add codecs or custom headers, switch the transport to TCP.
- Delayed offer. LiveKit accepts an INVITE with no SDP on inbound calls only on request. Until support enables it, LiveKit answers such an INVITE with “a
400 Bad Request”. Asterisk sent an early offer in our run; check that your PBX or SBC is not set to delay it.
If digits still go missing once the trunk is right, look at the agent’s pipeline. Our breakdown of why an AI voice agent misses DTMF digits covers that half.
NAT and registration: why a FreePBX call answers with no sound
A common first failure is a call that connects and is silent. In LiveKit issue #424, “FreePBX + Livekit Cloud – Call picked up but no sound”, the reporter wrote that “calls are picked up (answered), but there is no RTP media received on either side”. A reply pointed to a private 192.168.x address in the Contact header of the PBX’s INVITE, and a later comment reported one-way audio on outbound calls. The issue was closed as not planned, with no linked pull request, as at 26 September 2026.
LiveKit’s troubleshooting page says one-way audio “is most often a Network Address Translation (NAT) problem”, and that LiveKit Cloud “handles NAT for you”. On LiveKit Cloud, then, the address to fix is the one your PBX writes into its SDP. The Asterisk NAT guide calls out local_net, external_media_address and external_signaling_address on the transport and direct_media on the endpoint, adding media_address, rtp_symmetric, force_rport and rewrite_contact for phones that are themselves behind NAT.
The second failure is an INVITE that rings and is never answered. In LiveKit issue #400, “FreePBX → LiveKits SIP Trunk INVITE Not Being Answered”, the LiveKit log the reporter posted showed a 486 with reason “flood”. A later comment in the thread reads: “It turned out that the dispatch rules were set with the wrong number. After I corrected them, it worked.” The issue was closed as completed, with no linked pull request, as at 26 September 2026. Hence step 2: match the To header to the platform’s number list exactly.
Registration is the structural constraint. LiveKit’s telephony overview lists “SIP Registration (REGISTER)” as “Not Supported”. The feature request, issue #524 “Support REGISTER method”, was open as at 26 September 2026. Pull request #774, “feat: outbound SIP registration (REGISTER)”, was opened on 4 August 2026 and was still open and unmerged as at 26 September 2026. 3CX’s SIP trunk guide describes trunk authentication as “either register based … or IP based”. Against a platform that does not accept registration, a 3CX generic trunk has to use the IP-based mode, so your PBX needs an address the platform can reach, and the platform must accept your INVITEs by credentials, dialled number or source address.
Asterisk without SIP: AudioSocket and the WebSocket channel
The AudioSocket protocol is a three-byte header (“a one-byte type and a two-byte length indicator”) followed by a payload. Type 0x10 is 16-bit, 8 kHz mono signed linear PCM, and type 0x03 is a DTMF digit.
The version is the whole question. The 20.14.0 changelog says: “The AudioSocket protocol now forwards DTMF frames with payload type 0x03.” Checking res_audiosocket.c at each release tag, the DTMF handling first appears at 20.14.0, 21.9.0 and 22.4.0, and is absent at 20.13.0, 21.8.0 and 22.3.0. Ubuntu 24.04 carries Asterisk 20.6.0, the version we ran, which is why our run counted 0 DTMF frames. FreePBX 17’s official installer defaults to Asterisk major version 22 (ASTVERSION=22), so the point release decides: run asterisk -V.
The WebSocket channel driver “will be available starting with Asterisk releases 23.0.0, 22.6.0, 21.11.0 and 20.16.0”. Ulaw or alaw media arrives as “a 160 byte packet every 20ms”, and the driver does framing and timing for most codecs. Pipecat’s documentation lists a community-maintained Asterisk Frame Serializer built on that channel; the page says “Pipecat does not test or officially support it”. The earlier Pipecat feature request for an Asterisk AudioSocket transport, issue #2702, was closed as completed, with no linked pull request shown on the issue page, as at 26 September 2026. A native Pipecat SIPTransport, pull request #5583, was open as at 26 September 2026.
On either media path, a transfer to a person is your job. No REFER is involved: your code has to move the Asterisk channel, for example through ARI. If you want transfers without writing channel control, the SIP trunk path gives you REFER.
What this costs to own, and when to hand it over
The DIY route above is complete. The costs that persist come after the pilot works. You own a static, reachable PBX address, or a registering proxy in front of the platform, because LiveKit does not accept REGISTER. You own an RTP port range in the firewall and the NAT options that match it. You own an Asterisk version that has to be at least 20.14.0, 21.9.0 or 22.4.0 on its branch before AudioSocket carries keypad input. And you need someone who can read a NOTIFY body. On 3CX’s native path, the costs are an AI Edition licence and a provider account. 3CX’s OpenAI guide says you “must have a paid OpenAI account” and that accounts that “pay a minimum of $100 are typically elevated to Tier 3 directly”. You also depend on the models 3CX recommends for your installed version.
| Your situation | Do this | The reason, from the sources above |
|---|---|---|
| 3CX with AI Edition; inbound reception or customer service | 3CX native AI Agents | No trunk; OpenAI or xAI Grok; PCMU; outbound TCP 443 and UDP 3478 |
| 3CX without AI Edition, or you need your own agent logic | Generic SIP trunk to the platform, IP-based | 3CX trunks are register-based or IP-based; LiveKit does not support REGISTER |
| FreePBX or Asterisk with a static public address or an SBC | The PJSIP trunk on this page | Digest authentication, G.711, RFC 4733 and REFER all worked in our run |
| PBX behind NAT on a dynamic address, no SBC | Put a registering proxy or SBC in front, or choose a platform that accepts REGISTER | LiveKit issue #524 open and PR #774 unmerged as at 26 September 2026 |
| Asterisk below 20.14.0, 21.9.0 or 22.4.0 and callers must press keys | Upgrade, or use the SIP trunk path | 0 DTMF frames over AudioSocket on 20.6.0 |
| Asterisk 20.16.0, 21.11.0, 22.6.0 or later, agent built on Pipecat | chan_websocket with the community Asterisk Frame Serializer | Asterisk does the framing and timing; no second SIP stack |
| You do not want to own SIP traces, RTP ranges and transfer results | Hand the agent side to a managed platform, and keep the PBX | The PBX-side work on this page stays yours either way; only the agent side moves |
Whatever platform you evaluate for the agent side, Zian AI included, ask five questions before you sign. Does it accept REGISTER or only INVITE? Which codecs does it offer? Does it send and receive RFC 4733? Which REFER targets will it send? Which addresses must you allowlist? More answers of this kind sit in the Zian AI questions and answers hub. Zian AI runs autonomous phone, SMS, email and WhatsApp agents and is in partnership-application beta. If you would rather talk through your PBX before choosing, Apply For Partnership.
Frequently asked questions
Can I connect 3CX to an AI voice agent without the AI Edition?
Not with the built-in agents. The 3CX AI Agents configuration guide says the feature requires 3CX AI Edition. Without it, treat the agent platform as a SIP trunk. 3CX says that for a provider it does not support, it will not assist with configuration, so confirm first that the platform has worked with 3CX.
Why does my FreePBX call to the AI agent answer but have no audio?
Check the SDP first, then NAT. LiveKit’s SIP troubleshooting page says that when neither side hears audio, RTP is not flowing, and lists what to inspect: a c= address of 0.0.0.0, an m=audio port of 0, no codec in common, and on self-hosted deployments the firewall rules. It says one-way audio is most often a Network Address Translation problem. On a FreePBX trunk, set direct_media=no, and set local_net, external_media_address and external_signaling_address on the transport.
Does LiveKit support SIP registration from my PBX?
No. The LiveKit telephony overview lists SIP Registration (REGISTER) as Not Supported. The feature request, livekit/sip issue 524, was open as at 26 September 2026, and pull request 774 was open and unmerged. Your PBX must reach the platform without registering.
Which DTMF mode should my PBX trunk use for an AI agent?
RFC 4733, which obsoletes RFC 2833. LiveKit’s DTMF page says digits travel over RTP as telephone-event/8000. In Asterisk that is dtmf_mode=rfc4733, the default. In our test, three keypad digits arrived as 15 RTP event packets.
How does the AI agent transfer a caller back to an extension or ring group?
The platform sends a SIP REFER, and the PBX looks up the target in the trunk’s dialplan context. List only the extensions and ring groups the agent may reach there. A 202 Accepted is not success. Read the NOTIFY that follows: 200 OK means the transfer worked, a 4xx means it failed.
Can Asterisk send call audio to my own agent without SIP?
Yes, over AudioSocket or the WebSocket channel. The Asterisk 20.14.0 changelog records that AudioSocket began forwarding DTMF in that release. On 20.6.0 our test passed 342 audio frames and 0 DTMF frames. The WebSocket channel starts at 20.16.0, 21.11.0, 22.6.0 and 23.0.0.
Where every figure on this page comes from
| Figure | Who published it | Link | Date read |
|---|---|---|---|
| OpenAI and xAI Grok (Update 10 and above), one provider active at a time; AI Edition required; Human Handoff, Escalation Topics, AI unavailable, Check availability before transferring | 3CX | 3CX AI Agents Configuration (last updated 10 September 2026) | 26 September 2026 |
| Audio codec PCMU; outbound TCP 443 and UDP 3478; three-stage WebRTC setup; paid account, $100 minimum typically elevated to Tier 3 | 3CX | Configuring OpenAI for 3CX AI Agents (last updated 20 August 2026) | 26 September 2026 |
| Trunk authentication register-based or IP-based; no assistance for unsupported providers | 3CX | 3CX SIP trunk guide | 26 September 2026 |
| Add SIP (chan_pjsip) Trunk; Registration None; Context from-pstn in the example | Sangoma (FreePBX) | Setup Alphalink SIP (PJSIP) Trunk | 26 September 2026 |
| FreePBX 17 installer default ASTVERSION=22 | FreePBX | sng_freepbx_debian_install.sh | 26 September 2026 |
| SIP Registration (REGISTER) not supported; DTMF RFC 2833 / RFC 4733 supported; REFER supported | LiveKit | LiveKit telephony overview | 26 September 2026 |
| Default SIP codecs PCMU, PCMA, G722; delayed offer on request, otherwise 400 Bad Request; UDP fragmentation warning | LiveKit | Codecs negotiation and support | 26 September 2026 |
| telephone-event/8000 | LiveKit | Handling DTMF | 26 September 2026 |
| No RTP within 30 seconds ends the call; one-way audio most often NAT; LiveKit Cloud handles NAT | LiveKit | SIP troubleshooting | 26 September 2026 |
| ringing_timeout defaults to 30 seconds | LiveKit | Call forwarding | 26 September 2026 |
| Empty numbers needs credentials or allowed_addresses; allowed_addresses needs enablement; example number +15105550100 | LiveKit | Inbound trunk | 26 September 2026 |
| Defaults: direct_media yes, dtmf_mode rfc4733, rtp_symmetric no, rewrite_contact no, allow_transfer yes, force_rport yes, context default | Asterisk | res_pjsip configuration reference | 26 September 2026 |
| identify match accepts IP addresses, subnets or hostnames | Asterisk | res_pjsip_endpoint_identifier_ip reference | 26 September 2026 |
| NAT options local_net, external_media_address, external_signaling_address, direct_media; rtp_symmetric, force_rport, rewrite_contact for remote endpoints | Asterisk | Configuring res_pjsip to work through NAT | 26 September 2026 |
| AudioSocket 3-byte header; type 0x10 is 8 kHz slin; type 0x03 is DTMF | Asterisk | AudioSocket | 26 September 2026 |
| AudioSocket DTMF from 20.14.0; present at 21.9.0 and 22.4.0, absent at 20.13.0, 21.8.0 and 22.3.0 | Asterisk | ChangeLog 20.14.0; res/res_audiosocket.c at each release tag |
26 September 2026 |
| chan_websocket from 23.0.0, 22.6.0, 21.11.0, 20.16.0; 160-byte packets every 20 ms for ulaw and alaw | Asterisk | WebSocket channel driver | 26 September 2026 |
| Asterisk 20.6.0 in Ubuntu 24.04 | Canonical (Ubuntu) | packages.ubuntu.com, noble | 26 September 2026 |
| RFC 4733 obsoletes RFC 2833, December 2006 | IETF | RFC 4733 | 26 September 2026 |
| Asterisk Frame Serializer is community-maintained, tested with Pipecat v1.1.0 | Pipecat | Asterisk Frame Serializer | 26 September 2026 |
| Issue #424 closed not planned; #400 closed completed; #524 open; PR #774 opened 4 August 2026, open | LiveKit (GitHub, livekit/sip) | #424, #400, #524, #774 | 26 September 2026 |
| Issue #2702 closed completed, no linked PR; PR #5583 open | Pipecat (GitHub, pipecat-ai/pipecat) | #2702, #5583 | 26 September 2026 |
| 1,281-byte INVITE; 15 telephone-event packets for 3 digits; REFER 202 then NOTIFY 200 or 404; 342 AudioSocket frames, 109,440 bytes, 6.84 seconds, 0 DTMF frames | Zian AI (first-party sandbox test, two Asterisk 20.6.0 instances, one host) | This page, “What our sandbox run proved” | Run 26 September 2026 |