Northwind Logistics: Media Path Remediation Before PBX Retirement
Northwind Logistics is replacing a 20-year-old PBX for 4,200 employees across 38 sites in Canada, the US, and Mexico within nine months. HQ (1,400 users) has a 1 Gbps internet circuit; the other 37 sites are on MPLS hub-and-spoke with no local internet egress, and all web traffic is forced through a HQ proxy. Wi-Fi at 14 warehouses is consumer-grade. A 200-user Teams pilot produced a mean MOS of 2.8, jitter above 60 ms on branch-to-branch calls, and helpdesk tickets complaining of 'robotic' audio. Call Quality Dashboard shows 22% of branch call legs classified as Poor. The CIO has approved budget for local internet egress at only 8 sites and has stated the PBX retirement date cannot move because the carrier contract ends then.
1. In what order should local internet egress, QoS marking/trust, and proxy bypass be implemented, and how do you justify that sequence to the CIO?
Read the worked answer
Diagnose first, then sequence by dependency.
- The 22% Poor classification is a media path problem, not a Teams configuration problem. Branch-to-branch calls currently hairpin through HQ and the proxy, which is where the 60 ms jitter comes from. No amount of edge configuration fixes a hairpinned media path.
- 1. Local egress (8 sites). This is the only change that removes the hairpin. Everything else is an optimization layered on top of a path that is still wrong.
- 2. Proxy bypass / Optimize-category traffic. Required tenant-wide and independent of egress: forcing the real-time media endpoints through an inspecting proxy adds latency and can silently re-mark or strip DSCP. Do this immediately because it is free and applies to all 38 sites.
- 3. QoS marking and end-to-end trust. DSCP is only useful if every hop preserves it: client marking, switch trust boundaries, MPLS carrier contract honoring the markings, and firewall/proxy not remarking. Implementing QoS before the proxy is bypassed produces a false 'QoS done' signal.
- 4. Voice enablement per site, in waves, after two weeks of Call Quality Dashboard evidence that the wave-1 sites improved.
Justification to the CIO: enabling PSTN at a site with a broken media path converts PBX complaints into Teams complaints and destroys adoption. The nine-month date is protected by parallelizing tenant-wide work (proxy, dial plans, licensing) with the physical circuit work, and by treating PSTN cutover as the last step, not the first.
2. Only 8 of the 37 non-egress sites can get a circuit. How do you choose them, and what do the other 29 sites get?
Read the worked answer
Rank by business risk, not by user count alone.
Scoring criteria, weighted and agreed with the business:
- Call volume and revenue impact (contact-heavy sites beat quiet offices).
- Concentration of executive/customer-facing meetings.
- Current Poor-leg percentage from Call Quality Dashboard (fixes measurable pain fastest).
- Cost per circuit and carrier lead time (a site that cannot be installed in 90 days is not a candidate for wave 1).
Publish the scoring model - the political risk of picking 8 sites is larger than the technical risk.
The remaining 29 sites:
- Split the migration: move chat, channels, and file collaboration for everyone now; move voice only to egress-enabled sites. This is a 'collaboration first, voice by site' design and avoids a single global cutover date.
- Harden what you control without a circuit: wired connections for desks, certified headsets, disabling video on branch-to-branch calls via a restrictive meeting policy, and keeping analog/PBX lines at warehouses where the work is handheld and physical.
- Apply a network roaming policy only to genuinely roaming shared devices (carts, mobile kits) so they do not inherit a stale network profile; do not use it as a substitute for fixing a fixed-site WAN.
- Give the 29 sites a documented exception with an owner and a re-review date, plus a standing business case for the next tranche of circuits. Silent exceptions become permanent outages.
3. The PBX contract cannot be extended. What do you recommend enabling at the 29 remaining sites, and what risk must be accepted in writing?
Read the worked answer
Do not force PSTN cutover at sites whose media path you have not fixed.
Decision framework:
- Voice-enabled: the 8 egress sites plus HQ. These can be cut over from the PBX with acceptable quality and measurable CQD evidence.
- Collaboration-only: the 29 sites get Teams chat, channels, meetings, and file collaboration; PSTN stays on the existing PBX or analog trunks past the contract end date.
- Bridge option: for the highest-risk few of the 29, negotiate a short month-to-month analog/PBX extension or a local SIP gateway with a survivable branch appliance. It buys time and keeps dial tone local, but does not improve meeting quality - be explicit about that distinction with the CIO.
Risks to accept in writing:
- Two telephony platforms run in parallel past the original date, so directory/extension consistency must be maintained until final cutover.
- Users at the 29 sites will perceive Teams voice as 'worse' if they are moved anyway - the adoption damage usually costs more than the contract extension.
- Egress sites may still show residual poor quality if QoS trust is not configured on the carrier handoff; track weekly until the Poor-leg rate is under 5%.
Document the accepted risk with a named business owner, not with IT. 'We ran out of time' is not a risk statement; 'sites A–Z have degraded meeting audio until Q3' is.