OpenFax’s production disruption was driven by a Telnyx-side routing condition on the private Direct Connect environment. OpenFax could change its own side of signaling, but could not control Telnyx’s return path because the VXC did not appear anywhere in the online account.
OpenFax’s concern is not limited to one outage interval. If private-path signaling was intermittently misconfigured for a prolonged period, that could have affected overall carrier performance, prior surcharge billing, and incomplete fax delivery. It also raises the possibility that historical calls may have run into OpenFax’s call-limit timer when signaling did not terminate correctly, adding meaningful cost to monthly invoices while media may not have been received from all carriers.
This version puts the outage first, keeps billing in the background, and explains the issue as a service-control problem with a simple progression from normal state to constrained recovery to restored operations.
OpenFax operated through a redundant Equinix Direct Connect design, with an active/standby arrangement. Telnyx propagated the private NAT over BGP, and production media was expected to travel over the VXC path.
Before the total outage, OpenFax was already seeing many calls with random signaling misses. During the outage, media was not received at all. That combination raised the possibility that the private-IP NAT signaling path had been inconsistent for a longer period before the full production break.
With no customer-side portal control over the private path, no visible VXC object in the online account, and no timely response to test disabling the VXC over roughly two days despite repeated email and phone escalation, OpenFax had to restore operations by standing up infrastructure in another region over public internet. That recovered service before the original private path was resolved.
The key issue was not whether OpenFax could change its own edge. It was that OpenFax had no control over the Telnyx-side return path while the VXC was absent from the online account.
The VXC did not appear in the online account, so OpenFax could not simply disable or reroute the private connectivity from a normal customer control surface.
Eleven months of flat 4.44–4.49 MOS followed by an instant collapse to ~1.0 is an objective, independently verifiable measure that audio stopped flowing at a precise hour — and that it recovered the moment OpenFax cut over away from the Telnyx private path.
A simple view of what OpenFax could act on versus what remained blocked by missing portal visibility and Telnyx-side routing control.
The left side tracks the OpenFax production story. The right side lists contemporaneous public entries from status.telnyx.com/history during the June 29 to July 4 window. These public entries provide timing context, but do not by themselves prove causation.
Average MOS had been rock-steady at 4.44–4.49 every month since August 2025. From roughly 11:00 UTC on June 29 it drops to ~1.0–1.5 — audio effectively unusable — the earliest bad reading in the CDR data.
Private-path behavior fails in a way OpenFax cannot fully correct from its own side. The VXC remains absent from the online account.
10:29 ICT — identifies 100.79.0.23 as the VXC NAT address Telnyx's re-INVITE was being sent to. 12:04 ICT — advertises its public IP instead; signaling timeout fixed, but a media (RTP) gap is exposed. 13:57 ICT — with rtpengine deployed as a media relay, the final signature is isolated: T.30 sends DCS correctly but the far end never returns CFR, with zero packet loss on OpenFax's own media path — ruling out OpenFax infrastructure.
Under the Direct Connect deployment, OpenFax moves signaling to public. That narrows the problem, but media is still not being received because return-path control remains outside customer reach.
OpenFax restores services over a public-internet deployment in a different region, while the original private-link condition remains unresolved. Average MOS snaps back to the 4.44–4.49 baseline at ≈13:00 UTC — instantly, and exactly at the cutover. Abandoned-call rates stay elevated (30–35%) for roughly four more hours as backlog/retry traffic clears, normalizing by July 2.
As of Monday, July 6, 2026, the VXC connection and associated configuration controls under https://portal.telnyx.com/#/networking remain unavailable in the OpenFax account, demonstrating the persistence of the control-plane failure.
Public history shows multiple maintenance-completed items, including voice-service and programmable-voice entries on June 29.
The status page shows a maintenance-completed signaling entry on July 1, alongside programmable-voice maintenance for the same day.
Public history lists multiple maintenance-completed entries on July 2, including voice services update – all regions and SIP trunking signaling region updates.
A July 4 public portal-related entry appears in the same broader status window. It is included here strictly as timing context, not as a claim of direct linkage to the OpenFax outage.
The detailed material remains available, but it is moved below the main storyline so the page reads like an executive landing site first and a technical record second.
MEDIA_TIMEOUT / RECOVERY_ON_TIMER_EXPIRE hangup causes were also flat (0.03–0.16%, no trend).These entries are shown as contemporaneous public anchors only. They are not presented as a standalone causal determination.
The outage remains the main narrative, but OpenFax also asks that prior carrier performance, incomplete fax delivery, and earlier surcharge billing be reviewed in the context of the Telnyx-prescribed VXC configuration.