Call Disconnects Immediately¶

Symptom: call answers but disconnects within 0–2 seconds. Caller hears nothing or a brief partial audio. No clear error, no "all circuits busy."

This is the most common subtle problem on UnifiedBX. Don't guess — the diagnostic flow below resolves it in one call.

Most Likely Causes¶

Ranked by how often each is the answer:

Stale / ghost registration — a softphone (mobile or desktop) is registered alongside the desk phone, answers first, and immediately tears the call down because the app is in a broken state, audio device is gone, or push notifications aren't working.
Audio device failure on call start (softphone-side) — softphone tries to open the mic/speaker, fails, and self-terminates. Most common with Linphone, UnifiedBX softphone, Bria after Bluetooth/headset disconnect.
direct_media enabled on a NAT'd extension — Asterisk fires a reinvite on answer to set up direct RTP. Unreachable across NAT, app sends BYE.
VPN / RTP path mismatch — softphone advertises an SDP IP the PBX can't route to (virtual adapter, VPN-internal address). Signaling works, media fails, app gives up after ~200ms–1s.
Auto-answer + HID button binding misfiring — headset button event is interpreted as both answer AND hangup.
Codec mismatch on reinvite — endpoint and trunk negotiate a codec that one side can't actually do post-answer.

Diagnose (the canonical flow)¶

Step 1 — list everything registered to the extension¶

asterisk -rx "pjsip show contacts" | grep <ext>

Output looks like:

Contact:  8532/sip:8532@172.31.97.175:5060        86a146f37d Avail   27.792
Contact:  8532/sip:8532@192.168.248.5:51568;ob    afbadc8b82 Avail   11.457

If you see more than one contact, you have multiple devices registered. The ;ob flag = registered via outbound (NAT/mobile pattern) — these are the usual culprits.

Step 2 — pull each contact's user-agent¶

asterisk -rx "database show registrar" | grep -A1 "<ext>;"

This shows the full registration record including user_agent. You'll see something like:

"user_agent":"Aastra 6867i/5.1.0.6044"      # desk phone
"user_agent":"UnifiedBX/3.21.3"              # desktop softphone
"user_agent":"UnifiedBX-16.0.45(18.9)"       # mobile softphone

Now you know what each contact actually is.

Step 3 — capture SIP during a reproduction call¶

sngrep -d any host <client-ip>

Have the call placed. Open the dialog (arrow + Enter). The call flow shows every SIP message with timing.

Look for:

Who sends the BYE first — caller side or callee side? From: header in the BYE = the device that hung up.
Time between 200 OK and BYE — if the BYE is < 1 second after answer, it's the client self-terminating, not an RTP timeout (those fire at 30s).
SDP in the 200 OK — c=IN IP4 <addr> and m=audio <port>. Is <addr> an IP the PBX can actually route to? 192.168.248.x from a VPN client may not be.
User-Agent in the BYE — confirms which client tore down the call.

Step 4 — split test¶

Often faster than packet capture: have the user log out of one client at a time and reproduce. Whichever logout fixes it = that's the broken one.

Fix¶

Match the cause:

Cause: stale / ghost registration¶

Have the user fully log out of every UnifiedBX/Sangoma Connect/softphone instance.

Force-unregister the bad contact from the PBX:

asterisk -rx "pjsip send notify check-sync endpoint <ext>"
# Or, more aggressive — delete the registration:
asterisk -rx "database del /registrar/contact/<ext>;@<hash>"

Have the user log back in on the device they actually use.
For Sangoma Connect specifically, uninstall + reinstall + re-scan QR — push tokens get stale and break call delivery.

Cause: audio device failure (softphone-side)¶

Have the user open the softphone audio settings.
Set Audio Input and Audio Output to specific devices (not "Default") — disconnected/sleeping default devices cause this exact failure.
Unplug headsets, retry. If fixed: a HID-integration glitch with the headset.

Cause: direct_media + NAT¶

User Attributes → Extensions → → Advanced → Direct Media = No.
Submit → Apply Config.
This should be No for every NAT'd / mobile / VPN extension. Direct media only works on flat LANs.

Cause: VPN / RTP path mismatch¶

In the softphone advanced settings, enable Allow IP Rewrite (pairs with rewrite_contact: true on the endpoint).
Verify routing — from the PBX, ping the softphone's advertised SDP IP:
```
ping <sdp-ip>
```
Failure = VPN routing for that subnet is broken; fix on the VPN side, not the softphone.
If the softphone has multiple network adapters (Docker, Hyper-V, VPN, real NIC), pin Public Address to Manual and enter the adapter IP the PBX can route to.

Cause: auto-answer + HID¶

Softphone settings → Auto Answer → No / Disabled.
Disable headset HID integration if not needed.

Cause: codec mismatch on reinvite¶

Endpoint allows only what the trunk supports (typically ulaw, alaw).
Trunk Attributes → Trunks → → PJSIP → Codecs — restrict to a single safe codec for testing.

When to Escalate¶

You've ruled out registration, direct_media, audio device, and VPN/RTP path, AND
Multiple unrelated extensions show the same behavior, AND
Recent changes include a FreePBX/Asterisk update.

In that case it's likely an Asterisk regression. Check the changelog of any recent core or pjsip module update. Roll back via fwconsole ma upgrade core <prev-version> from a recent backup.