Solved [V20 SaaS hosted] Yealink W90B - default template Expires too short on REGISTER + SUBSCRIBE MWI, how to persistently override?

[vincentp]

Hello everyone,

Reaching out to the community because I'm hitting a periodic SIP burst issue on a customer in production, and I'm looking for the clean way to fix it persistently.

Context
- 3CX V20 SaaS hosted tenant, PRO Enterprise edition
- Production hardware: 1 Yealink T87W (configured as SBC) + 1 Yealink W90DM + 3 W90B base stations + 20 W56H handsets, multi-cell DECT IP, 21 active slots on the W90DM
- SIP trunk via Sewan (France), fully functional

Symptom
Intermittent audio drops during ongoing calls: SIP signaling remains active but the RTP flow gets cut. Classic signature of SBC saturation during periodic SIP bursts.

Diagnosis via PCAP on W90DM and T87W
I captured on the W90DM and identified two sources of periodic bursts that overload the SBC for 1-2 seconds:

1. Default template "yealink.W90B.fxs.xml" contains:
template.1.sip_server.1.expires = 120
--> Generates a burst of 21 REGISTER + 407 + 200 OK every 2 minutes

2. Same template contains for each account:
account.X.subscribe_mwi_expires = 900
--> Generates a burst of 21 SUBSCRIBE MWI + 407 + 200 OK every 15 minutes

In the PCAPs, I clearly see bursts of 22 to 331 SIP packets at those intervals, exactly correlating with audio drops reported by end users.

Empirical validation
I manually raised via the W90DM web UI:
- template.1.sip_server.1.expires = 3600 (Account > Register > Server Expires)
- account.X.subscribe_mwi_expires = 3600 on 10 slots (Account > select slot > Advanced > MWI Subscribe Period)

Result observed: out of 200 calls after these local overrides, 1 single drop (vs several per hour before). Diagnosis confirmed.

But these local overrides get wiped by every 3CX-initiated re-provisioning.

Question to the community
What is the clean and persistent way to override these two parameters in the W90B template for this SaaS hosted tenant, knowing I don't have SSH access to the 3CX server?

I explored on the OData API side:
- "FxsTemplate.Content" : exposed read/write, PATCH seems possible but would affect all future W90B on the tenant
- "Fxs.Variables" : field exposed, empty by default, undocumented behavior for this kind of override

A few options I'm considering:
1. Custom FxsTemplate via shell on the 3CX server: not feasible on SaaS hosted
2. PATCH FxsTemplate.Content via API: technically possible but seems non-standard
3. Variables on the Fxs: to validate if it works as an actual override
4. 3CX support ticket: option I'm considering

Has anyone in the community already faced this requirement? Is there an official path for that kind of override on a SaaS hosted tenant?

If a 3CX staff member happens to read this, I'd be happy to get an official guidance. And I can provide the PCAPs showing the bursts if useful.

Thanks in advance for your feedback.

Best regards,

Vincent PARAZOLS
ARPASYS - Authorized 3CX Partner

 

[JohnS_3CX]

Hi Vincent,

Router phones are not specced for this much traffic, even with suggested modifications above.

In this case the correct solution is to install a dedicated SBC, no need to mess around with custom settings etc.

You can go with a local VM, Raspberry Pi, or PC as your dedicated SBC:
https://www.3cx.com/docs/3cx-tunnel-session-border-controller/

 

[vincentp]

Hi JohnS_3CX,

Thanks a lot for the quick guidance. We followed your recommendation and installed a dedicated SBC this morning, here is a short update with the results so far in case it helps the community.

Hardware used: Mini PC HP Pro with Debian + 3CX SBC package (standard install via the provisioning link from our 3CX admin console).

Migration: I changed the SBC reference of the W90DM in the 3CX admin (Phones > W90DM > Provisioning > selected the new SBC instead of the Yealink T87W router phone). All 21 W90DM slots re-registered through the new SBC within 60 seconds. No re-pairing needed on the W56H handsets.

Architecture kept: I left the T87W (reception desk, ext 200) in router phone SBC mode for its own account only. This way we keep a redundancy: if the dedicated SBC ever goes down, the front desk phone keeps the reception line operational. Zero additional cost for this redundancy.

Results observed
- Dedicated SBC: CPU 0.1 to 3 percent peak, RAM 4.6 percent, latency 24 ms, 21 phones registered
- T87W (now serving 1 phone only): CPU dropped from 12 percent to around 5 percent
- General feel: drop in audio cut complaints from end users, but not zero yet

Follow-up question
We still observe occasional audio cuts (about 1 per hour on a busy morning instead of several per hour before). Our PCAP analysis from yesterday showed two periodic SIP burst sources:

template.1.sip_server.1.expires = 120 # REGISTER burst every 2 min (21 slots)
account.X.subscribe_mwi_expires = 900 # SUBSCRIBE MWI burst every 15 min (21 slots)

I had locally raised both values to 3600 on the W90DM web UI before the SBC migration, and we saw a significant improvement at that point. But those local UI overrides are wiped at every re-provisioning from 3CX.

Now that we have a dedicated SBC with plenty of headroom, are these short Expires values still considered a problem? Or does a dedicated SBC effectively absorb these bursts without impact, making the template defaults acceptable?

If they remain problematic, would 3CX recommend a tenant-level override of these two values in the W90B template, or is the dedicated SBC capacity supposed to make them irrelevant?

Thanks again for your help, this thread has been very useful and I will keep it updated if we find anything else.

Best regards,

Vincent PARAZOLS
ARPASYS - Authorized 3CX Partner

 

[JohnS_3CX]

What is your firmware version on the DM and all the bases?

Yealink patched an issue similar to the one you've reported.

Upgrade your Yealink DM, bases and handsets first: https://www.yealink.com/en/solution-detail/resource-for-3cx

 

[vincentp]

Hi JohnS_3CX

Thanks for the firmware pointer. Our current versions are:

- Yealink W90DM: 130.87.0.10
- Yealink W90B base stations: same branch 87 (same as DM)
- Yealink W56H handsets: 61.87.0.5

According to Yealink support page, the latest W90DM firmware available is 130.87.0.18, so we are several builds behind. Quite likely the fix you mention is included in the more recent builds.

Plan
We will trigger the firmware upgrade tonight (cabinet closed after 17:00, no user impact). We will use Auto Provision pointing to the Yealink CDN to get the latest matching firmware for the DM, the 3 W90B base stations, and the 20 W56H handsets in one shot.

Will report back tomorrow with the results and the resolved version numbers. If the audio cut issue still occurs after the upgrade, we will share PCAP captures of the new occurrences and reopen the discussion.

Thanks again for the quick guidance and the dedicated SBC recommendation, both have moved the needle significantly already.

Best regards,

Vincent PARAZOLS
ARPASYS - Authorized 3CX Partner

 

[JohnS_3CX]

It appears you are using the version that is actually known to have the issue.

Please upgrade using this link here: https://www.yealink.com/en/solution-detail/resource-for-3cx

It will bring you up to 130.87.0.30

 

[vincentp]

Hello,

Good news: the issue is resolved, and you can close this ticket.

Following the recommendation from your staff on the community forum, we upgraded the W90DM and the three W90B base stations from firmware 130.87.0.10 (the version identified as having the known issue) to 130.87.0.30, using the firmware from the official Yealink resource page for 3CX (yealink.com/en/solution-detail/resource-for-3cx). The upgrade was performed on site on June 11: the DECT Manager distributed the firmware to all base stations automatically, and all 21 handsets plus the T87W re-registered without any intervention.

The result is immediate: the customer reported zero audio drops since the upgrade, compared to roughly one per hour previously. We deliberately kept the template values unchanged (REGISTER expires 120, MWI subscribe 900) so the firmware was the only variable, which confirms the root cause was the firmware itself and not the template values. Our request for a persistent template override is therefore no longer needed.

One suggestion if we may: it would help partners a lot if the known-bad firmware versions (like 130.87.0.10 on the W90 series) were flagged in the 3CX documentation or in the provisioning templates, as the units ship from the factory with that version.

Thanks a lot for your help on this case, the forum pointer was exactly what we needed.

Best regards,

Vincent Parazols — ARPASYS STORE (3CX Advanced Partner)