v20.0.9 — call quality, tunnel drops, WebRTC, Teams→3CX presence

solitychit

Joined
Jun 18, 2026
Messages
2
Reaction score
0
Hi all

We debugged a new 3CX PBX that went live few weeks ago, now with v20.0.9 cloud deployment (~24 ext, SIP trunk, Windows app + web client). Server looks fine; several behaviours feel like product/integration issues, not just config.

Quick context: PBX was created via 3CX’s Azure onboarding (not a manual build). Small cloud VM (2 vCPU / 4 GB), SIP trunk (G722/PCMA), one site on the web client, another on the Windows app behind a FortiGate (LAN <span>10.x</span>, 3CX tunnel on TCP 5090). M365/Teams is set up in 3CX and granted all needed permissions.

Setup
3CX v20.0.9 on a small cloud VM (2 vCPU / 4 GB)
SIP trunk (G722/PCMA), codecs as per 3CX defaults
Web client at one site; Windows app behind a FortiGate at another (10.x LAN, tunnel egress via ISP NAT)
M365 / Teams integration with Entra app + certificate

Call quality vs Teams​

On the same machines and networks, Teams consistently sounds better than 3CX. That part we can partly explain (cloud media path, Opus vs G722, etc.), but some of the behaviour still surprises us.

What we see:
  • Web → PSTN: constant background hiss, even when both sides are muted (so likely codec/transcode comfort noise, not the mic).
  • Internal ext-to-ext (web at one site → Windows app at another): often fine, but sometimes jitter or one-way audio — including between two offices on the same PBX.
What the logs show (3CXMediaServer*.log):
  • Most calls: Connection(transcoding mode) — WebRTC Opus ↔ trunk G722
  • Web client SDP: telephone-event/8000 and 48000
  • Windows app: ONLY telephone-event/8000
  • When things go well internally: Connection(proxy mode) via tunnel
We adjusted codec prefs toward G722 where we could; web clients still use Opus, so transcoding remains. We also enabled trunk re-INVITE via exported provider XML (no UI toggle in v20) — limited benefit for web paths.When a call goes wrong, we often see this chain:
  1. Tunnel log (3CXTunnel*.log): TcpProc: read failure → tunnel terminating
  2. Media log: proxy mode → transcoding mode about a second after answer
  3. User experience: jitter / caller not heard
We also see this on many tunnel call setups: RTP receiver was not added … has no assigned socket
(sometimes brief destination unreachable, then restored)

On the FortiGate: global SIP helper is off, traffic is generally allowed, no deep inspection. We’re now focusing on TCP 5090 stability and session timeouts — tunnel drops seem to line up with the bad calls.

Question: Is this pattern familiar? Any FortiGate or tunnel tuning that helped on v20?

Web client & registration
A few things we’re unsure about:
  • UI shows registered (user is green for himself), but CDR says not_registered
  • Logs: [MyPhone.CallOwner] WebRTC: Client for session … is not found
  • Browser/PWA only: extension often looks offline — calls don’t seem to work unless the Windows app is also running
  • If both app and browser are active, both ring; answering on one device often drops the call
  • Two browser tabs on one PC breaks things (we know that’s discouraged, but it’s fragile)
Question: Is browser-only meant to be production-ready on v20, or is the Windows app effectively required?

Teams → 3CX presence (never worked for us)​

This one’s confusing. 3CX → Teams presence works. Teams → 3CX has never worked for us — not a recent regression. We’ve tried full re-authorization, new Entra app registration, both presence options enabled in 3CX, API permissions look correct.

Log/API picture:
  • 0 hits on <span>/m365/</span><span>presence</span>
  • 0 Graph subscriptions on <span>communications/</span><span>presences</span>
  • Creating a presence subscription with the PBX app cert → 403 ExtensionError
  • Microsoft docs suggest presence change notifications need delegated <span>Presence.Read.All</span> — we added it to the app reg; no improvement (3CX still seems to use cert/app-only for subscription setup)
  • Microsoft365PresenceService only shows NoInstruction
  • Separate side note: a daily ~05:00 sync sometimes hits HTTP 429 (background throttle) — doesn’t look like the root cause
Question: Anyone on v20 3CX presence actually working? What does your Graph subscription list show?

What we’ve mostly ruled out​

  • VM overloaded at the times we tested
  • Trunk not reachable (RTP flows in logs)
  • Global SIP ALG on our FortiGate

We’re not trying to bash 3CX — we deploy it for customers and want it to work well. But we’re seeing similar complaints elsewhere and would value hearing whether this is “expected on cloud + WebRTC” or if others found fixes we’re missing.

Happy to share more redacted log excerpts if useful.

Thanks in advance for any pointers.
 
@solitychit I would recommend opening a ticket to our support portal so we can check this with logs and wireshark in order
to see what is happening.
As a general rule though, the Web Client / PWA will use https port for the connection and will make stun requests to the PBX in order to define the media ports they will use. Ensure also that Notifications are enabled otherwise the user will not show as Registered.
The v20 windows client will use tunnel for the connection and the audio. The v20 client has " Echo Cancellation " option on the settings where you may enable this.
If you put PCMA / PCMU on the codecs for the WAN connections, do you have the same issues ?

For the presence from Teams to 3cx, ensure that your Firewall does not have any Geolocation enabled ( do this for a test ).
And also ensure that the Authorization for the 365 has been done by the Global Admin.
The users have First Name, Last Name, Display Name, they have Principal name correct and they are set as Members on the User Type in Azure side.
 
@NikosT_3CX

Thanks for the pointers — these are helpful.

Regarding not registered state:
will check back to see if this was the only issue. What could cause calls to just drop if both softphone and web app are open at same time tough? I assume it could have to do with mic/speaker being accessed from the headset - is this related to Jabra f.e? These users sometimes have just both open at same time but then have calls that drop as soon as they try to pick them up.

Echo cancellation
Will check echo cancellation with users and wait for their feedback. Also running more verbose logging and some user call quality logging to get more data.

Call quality
I had PCMA/PCMU as top prio in beginning, changed that to G722 top prio as many users where reporting that call quality is just awful. They also noted that sometimes they just switch to Teams call when calling internally and it just so much clearer and better, even now with G722.
However - will add PCMA/PCMU top prio again and now also run the logs - didn't do that in the beginning. I'm now already deep digging here to hopefully get a good experience for the customer - in the end, I was the one suggesting moving to 3CX due to license costs.

Teams presence
Presence sync: no geolocation. Fortigate is generally seemingly setup very loose, no real inspections or blocked ports.
Firewall checker on 3CX is all green.
Microsoft 365 integration is configured and running. Click here to see settings
Status OK. Real Time Notifications from 3CX to Microsoft 365 are working and in sync.
On setup, App had teams presence rights selected. Done everything with Entra Global Admin.
Then on separate M365 integration page (Click here to see settings) bottom, both teams checks for sync are checked. Authorised as well, here with Global admin as well. Already deauthorized, removed full m365 integration, deleted App in Azure and redid the whole config. Still no presence sync from Teams->3CX. App reg in Azure looks right to me, API permissions are in, certificate fingerprint is correct on appreg <-> 3cx.

Users generally are normal M365 users with all names set, mostly licensed. Maybe 1-2 mailboxes only accounts. Not working for any user at all for Teams -> 3CX direction.


I will check back with customer on a window where we can replicate this with wireshark on. Sadly this go-live already had multiple test calls etc, costing time, which makes it harder also for me to bother the customer. Will need some time for this.
All of this just is strange to me that a completely fresh 3CX instance, deployed with 3CX template, on Azure, here in switzerland makes so much issues and needs so much debugging whereas their old phone system (teams) never had call quality issues without any optimisations. The whole setup just used templates (provider iWay for the trunk) and is a really simple instance. I'm unsure if I should update other customers to latest U9 and risk those thinks breaking there as well?

will now:
Further run verbose logging, have some users collect call quality data
ext-to-ext tests with web-web,web-app,app-app
WAN codecs PCMA/PCMU only.
If I cannot find any other instance than will have to tell customer to buy support ticket.

Any other pointers?
 

Latest Posts

Forum statistics

Threads
111,811
Messages
589,121
Members
164,620
Latest member
c.poggiarelli