VoIP.info Troubleshooting

TPx UCx SmartVoice forwarding, capacity, continuity or call fails

Find the first divergence across order, handoff, access, channel allocation, DID feature, DTO, SD-WAN continuity, SIP, media, emergency and support evidence.

Reviewed 2026-10-29Current first-party TPx UCx SmartVoice SIP Trunking, brochure, SmartVoice guide, DID-feature, Direct Trunk Overflow, 911, support and systems-status records were reviewed October 29, 2026. The accepted order, customer, site, handoff, transport, PBX, enabled DID features, purchased channels or call paths, UCx or Webex add-ons, forwarding, continuity design, registered emergency location and provider implementation record govern. Public product, SLA, compatibility, capacity, failover and support language does not establish one loaded PBX, live service path, successful call, outage impact or restoration. No TPx account, order, portal, credential, trunk, gateway, PBX, network, SD-WAN path, packet, DID, call, media stream, forwarding event, continuity event, emergency outcome, price, availability, compatibility, ticket or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one site, one trunk and one affected call window

Record UTC and local time, customer, site, order and activation reference, exact UCx SmartVoice service, SIP or legacy handoff, access path, managed SD-WAN state, gateway, PBX version, direction, calling and called values, expected route, first response, alert, answer, audio and hangup. Redact credentials and unnecessary subscriber data.

Preserve the last-known-good time and recent order, circuit, SD-WAN, channel, DID feature, DTO, forwarding, number, PBX, firewall or emergency-location change. Diagnose the first unexpected boundary before changing multiple systems.

Compare the implementation record with loaded edge state

Use the account implementation record and authorized support path for the exact handoff, gateway, addressing, routing, authentication or identification and enabled service features. Compare those records with the PBX or SBC objects actually loaded and the network path actually selected.

The public pages do not publish one universal registrar, proxy, username, password, source-address rule, port, transport, certificate, codec or firewall range. Do not copy values from another customer or infer registration from a successful portal login.

Test capacity with evidence, not manufactured load

Record ordered channels or call paths, active dialogs, local channel usage, new-attempt time, bandwidth context and the first provider or PBX response. A brochure statement about high capacity or flexible scaling is not a measured ceiling, burst entitlement or call-start rate.

Do not generate production load. Preserve whether the rejected attempt reached TPx, the customer edge or the PBX, and distinguish a busy destination, local resource limit, route rejection, timeout and provider finding.

Trace forwarding and DTO as different controls

For inbound failure, preserve DID assignment, provider attempt, PBX receipt and normal destination. Then identify whether Call Forward Not Reachable, Trunk Group Call Forwarding, Standard DTO or Enhanced DTO was purchased and configured. Capture scope, destination, trigger, notification, alternate attempt, alert and answer.

Feature access, an RTAP configuration or an email alert is not proof that a particular call followed the alternate route. Per-DID and whole-trunk behavior must not be collapsed.

Follow access, SIP, SDP and media through continuity

For each authorized observation point, record the selected access or SD-WAN path, route and firewall state, SIP requests and responses, SDP offer and answer, packet directions, decoding and listener result. If a path changes, correlate the SD-WAN event, gateway reachability, PBX state and each new SIP attempt.

Active/active language does not prove established-call survival or application restoration. A responding gateway, accepted dialog, packets and usable two-way audio remain separate evidence.

Retest one correction and escalate a bounded case

Apply one authorized correction, repeat the affected ordinary call and an unaffected control, and retain order, edge, route, signaling, forwarding, answer, both media directions and hangup evidence. Keep public status, support case, escalation, provider finding, action and verified restoration separate.

For emergency readiness, confirm the exact number, registered location, caller ID, callback, PBX route, power and access dependencies through TPx-approved non-live validation. No TPx service, call, forwarding event, continuity path, emergency outcome or support finding was tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.