VoIP.infoThe independent guide to business communications.
VoIP.info Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Reviewed 2026-10-19Foundational

Define the failure you intend to survive

A provider outage, local internet failure, PBX failure and a single unreachable destination need different responses. A second trunk on the same PBX and internet circuit does not remove those shared dependencies.

Redundancy needs separate failure paths
A PBX uses a primary provider path and an alternate provider path. Shared PBX, power and internet dependencies remain unless the design also separates them.

New-call recovery and active-call survival are different tests. Inbound number failover needs a provider-side routing plan.

Design outbound behavior

Specify which failures should trigger an alternate route. An authorization denial or invalid destination may require correction rather than another attempt. Limit retries and verify number formatting, caller identity and permissions on each trunk. Prevent loops between alternate paths.

Design inbound behavior separately

Inbound failover depends on control of the called number and the provider's routing options. Ask where calls go when the primary PBX cannot be reached and whether that behavior uses a timeout or a health signal. A second outbound account alone does not redirect inbound calls to your number.

DIDWW documents DNS SRV for a customer trunk host and trunk groups with selected rerouting disconnect codes, priority and weight. Flowroute documents per-number primary and failover destinations. Neither pattern implies that every SIP error or an already established call will move. Record the triggering response and every attempted destination when you test.

SIP.US documents primary and secondary trunk assignments plus PSTN Backup and Forward options. These have different triggers and channel use; see the SIP.US record rather than treating them as one universal failover mode.

Voxtelesys portal route profiles can prioritize registered-PBX, customer-IP and external-transfer destinations. Review the provider record and validate the actual advance trigger, cost and shared dependencies.

Amazon Chime SDK Voice Connector uses priority and weight for customer SIP hosts, while connector groups can span AWS Regions. Review the provider record and keep provider-region fallback distinct from the customer PBX, access network and active-call state.

Test recovery as well as failure

Use an agreed maintenance exercise. Confirm new calls on the backup path, expected handling of active calls and return to the primary route. Check capacity, billing assumptions and emergency-calling arrangements for the backup. Record the observed recovery time instead of describing the design as seamless without evidence.

Where the provider exposes a separate CDR for each delivery attempt, reconcile attempts by call identifier and time. DIDWW describes that behavior for SRV and trunk-group failover. A single successful final leg can hide a repeatedly failing primary leg.

Model every BYOC-P failure domain

Zoom Phone BYOC-P can use regional trunks, alternate Zoom data-center routing, multiple customer SBCs and Internet or private connectivity. Those controls do not establish one universal route order, timer, access diversity, carrier recovery or established-call behavior; test each accepted boundary separately.

Keep Genesys provider requirements separate from the deployed sequence

For Genesys Cloud BYOC, the provider record distinguishes OPTIONS, 503 and sequential-failover requirements from the selected carrier's actual target order, timers, capacity, restoration and established-call behavior.

Bind ACS Direct Routing failover to route priority and response code

For Azure Communication Services Direct Routing, the provider record preserves regular-expression match, route priority, equal-priority random SBC selection, OPTIONS health and Microsoft's documented 408, 503 and 504 next-SBC failover boundary.

Keep the CCAI Platform BYOC failover owner explicit

Google assigns customers responsibility for high availability and call routing from carrier services to the CCAI Platform media edge. The BYOC record preserves multiple inbound carriers, the single outbound-carrier boundary and requested Google-telephony fallback as different designs.

Trace a peoplefone offline-forwarding path

The peoplefone fallback diagnostic follows registration expiry, provider line state, the offline role, number filtering, alternate delivery and return to primary without representing forwarding as active-call survival.

Keep redundant targets distinguishable from stale branches

The A&A duplicate-ringing diagnostic inventories registration, direct server and Also Ring branches before deciding whether an alternate path is intended resilience or a retired target.

Apply SureVoIP’s timeout-only destination policy

For SureVoIP inbound delivery, use the provider-specific destination diagnostic to preserve the ordered routes and distinguish a timeout from Busy, Unavailable or later PBX failure.

Distinguish Magrathea health probes from call delivery

Use the Magrathea SIP Resilience diagnostic to correlate nominated addresses, provider probes, pool membership, new-call selection and later PBX routing.

Distinguish NFON multi-PBX modes from PSTN backup

Use the NFON backup-PBX diagnostic to correlate the selected mode, endpoint readiness, provider branch, PBX route and restoration.

Prove SIP DNS selection before expecting another target

Use the Voip Unlimited DNS failover diagnostic to trace NAPTR, SRV, address records, cache state, a qualifying failure and the new transaction.

Resolve Broadvoice failover mechanics for the ordered route

Broadvoice publishes built-in redundancy and failover without one public timer or route contract. The Broadvoice provider record keeps targets, health checks, failure responses, detection, restoration, new-call recovery and established-call behavior as separate acceptance evidence.

Qualify SIPcity’s optional peering failover address

SIPcity permits a primary and optional failover IP for peering, but does not publish one trigger or timer contract. The SIPcity provider record requires an approved new-call exercise and keeps active-call survival and restoration as separate evidence.

Separate Toku platform redundancy from customer-trunk failover

Toku describes redundant infrastructure, but the reviewed material does not define one customer trunk trigger, retry path or restoration timer. The Toku provider record requires the selected design and an approved new-call failure and recovery exercise.

Separate LoopUp endpoint distribution from DNS and WAN failover

LoopUp offers round-robin or ordered failover across customer endpoints and separately publishes regional platform FQDNs. The provider record requires each new-call choice and recovery path to be proved.

Separate SIPTRUNK gateway redundancy from call treatment

SIPTRUNK documents multiple gateway registration or SRV behavior separately from PSTN Backup, hard forwarding and voicemail. The mode-mismatch diagnostic keeps provider reachability, inbound destination, treatment trigger and restoration as different observations.

Do not combine SIP.US gateway failover with secondary routing

SIP.US documents provider-gateway redundancy, secondary-trunk DID routing and PSTN Backup as separate mechanisms. Use the SIP.US failover diagnostic to capture the qualifying failure, next attempted path, caller result and restoration.

Keep Flowroute provider-edge selection and number-route failover separate

Flowroute documents current PoP selection separately from per-number primary and failover route relationships. Use the Flowroute diagnostic to record the first delivery result, any second attempt and return to primary without assuming which responses advance.

Keep DIDWW trunk-group and DNS SRV attempts separate

DIDWW can create a new CDR for each trunk-group or DNS SRV attempt. The provider-specific diagnostic binds every attempt to the layer, configured trigger and destination that owned it.

Use every available Twilio edge address without losing trunk identity

Twilio recommends avoiding a single termination IP and preserving the personal trunk domain while edge routing changes. The termination diagnostic separates DNS or address failover from ACL and credential acceptance.

Preserve SIPStation failover precedence

Sangoma documents different behavior when no failover is configured and when account-level or per-DID failover exists. The SIPStation diagnostic records the first server, configured override, next attempt and final route.

Keep IP Telecom access diversity separate from SIP failover

IP Telecom recommends resilient connectivity such as backup broadband or 4G/5G. The provider record keeps access failover, provider SIP routing, alternate inbound delivery, PBX redundancy and established-call survival as separate evidence.

Treat Clearfly forwarding and virtual attendant as routing controls

Clearfly describes personalized forwarding and a virtual attendant for weather or phone-system outages. The provider record keeps those controls separate from SIP target health, access diversity, PBX resilience and established-call survival.

Bind Redcentric failover to the ordered access design

A legacy Redcentric description tied standard failover to provider-supplied circuits and treated third-party access as designed work. The provider record uses that only as a present-day acceptance question for circuits, targets, triggers, recovery and support.

Translate CommPeak redundancy claims into a tested route map

CommPeak publishes geo-redundant routing and failover language. The provider record still requires selected targets, DNS behavior, triggers, established-dialog limits, alternate inbound handling, recovery and rollback evidence.

Require an explicit Voximplant alternate-path design

The reviewed Voximplant pages do not define one universal customer failover sequence. Use the provider record to record targets, DNS dependency, triggers, retry behavior, established-dialog limits, recovery and rollback.

Separate Voip Unlimited DNS routing from portal diversion

The provider profile distinguishes NAPTR or SRV target selection, registered Contact, customer-system diversion and non-registration alerts.

Keep SignalWire resource assignment separate from failover

The reviewed SignalWire material documents number and Resource SIP Address routing but does not establish a redundant PBX retry policy. The provider profile keeps that gap explicit.

Interpret Telnyx failover from the recorded first result

Telnyx documents response-specific advancement for IP and FQDN routes and a separate registered-instance path for credential Connections. Use the Telnyx diagnostic to retain each attempt, response and next destination.

Do not invent Bandwidth failover triggers

Bandwidth Build documents prioritized routes and later failover routes but the reviewed public page does not publish a complete response-code or timer contract. The Bandwidth diagnostic preserves the observed attempt, result and any next route.

Classify Voipfone diverts before calling them failover

Voipfone publishes Always, closed, busy, no-answer and PSTN-failover controls. The Voipfone diagnostic records which rule was enabled, what triggered and which attempt occurred.

Classify the VoIP.ms failover state first

VoIP.ms separates Busy, Unreachable, No Answer and Max Capacity. The VoIP.ms diagnostic records the trigger evidence and alternate attempt for each.

Read the Twilio stopping response before expecting another URI

Twilio publishes response classes that stop Origination URL advancement and a four-second no-response boundary. The Twilio diagnostic preserves each attempt.

Test Plivo fallback only at its documented boundary

The Plivo inbound diagnostic distinguishes an unresponsive primary from a reachable destination that returns a final SIP response.

Test Vonage priority and timeout at their documented boundary

The Vonage inbound diagnostic distinguishes an unreachable URI from a reachable target that returns a final SIP response.

Preserve Voxtelesys destination priority and transfer ownership

Voxtelesys supports prioritized route destinations and a later Transfer using an outbound trunk group. The diagnostic retains the actual attempt and avoids inventing a universal response matrix.

Separate Amazon Chime group fallback from origination routing

Voice Connector group priority and origination-host priority are different selection layers. The Amazon Chime diagnostic traces each without claiming active-call survival.

Test Callcentric Network Down Forward below DID Forward

A direct DID Forward has higher priority than Call Treatments, including a network-down treatment. The Callcentric diagnostic tests precedence, the separate forwarded leg and return to primary.

Scope Anveo Direct failover to the DID add-on

The Failover Add-on can send an inbound DID to a backup SIP URI, while outbound LCR has different controls. The diagnostic records the actual attempts without inventing a trigger matrix.

CarrierX soft failure is not dead-trunk state

CarrierX separates one-call soft failure from thresholded hard-failure state and SIP OPTIONS monitoring. The diagnostic retains each transition and next attempt.

AVOXI terminal codes are explicit stop controls

An AVOXI URI can list 400–699 responses that terminate a call. The diagnostic does not infer universal retry or alternate-target behavior for other outcomes.

Separate Easybell address order from Offline forwarding

A later Trusted IP and an Offline forward to a telephone number are different mechanisms. The diagnostic requires observed attempts instead of an invented universal trigger.

SIP.US Forward, Backup and secondary trunks have different precedence

PSTN Forward bypasses the PBX and prevents conditional Backup from engaging; a secondary trunk is a separate SIP route. The diagnostic requires observed attempts.

Separate Flowroute edge recovery from number-route failover

A preferred PoP can change the Flowroute source edge while the number remains on the same customer route. The Flowroute failover diagnostic records both layers.

ClearlyIP number-level failover has separate precedence

The ClearlyIP workflow keeps per-number rules, Location rules, Smart Routing and observed recovery as different evidence.

Keep Simwood routing controls and observed recovery separate

The Simwood workflow records time-of-day routing, forwarding, failover and the provider attempt as different evidence.

Do not pin one Sinch regional edge

The Sinch diagnostic preserves the regional FQDN, DNS answers, selected address and observed result.

Sources & applicability

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

Continue your research

Hub

VoIP networking

Trace signaling and audio through your actual topology before changing ports or prioritization.

Explore topic →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →
Hub

VoIP planning tools

Use calculations to make assumptions visible, then validate them against real workload and equipment.

Explore topic →
Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Provider research · DIDWW failover, trunk-group and response-code documentation updated October 7–8, 2026 was reviewed October 14, 2026; it documents priority, weight, ringing timeout, selected re-routing disconnect codes, capacity controls, DNS SRV and a separate CDR for each routing attempt, but no account, DID, trunk group, endpoint, DNS answer, capacity state, request, response, CDR stream, failover event, media stream or live call was inspected or tested

DIDWW SIP Trunking: inbound delivery, outbound calling and resilience research

Distinguish inbound static or registered delivery from outbound auth, trunk groups, encryption and emergency identity.

Read guide →
Provider research · Current first-party SIP.US identity, registration, gateway, DID routing, failover, channel-capacity and E911 documentation reviewed October 18, 2026. The pages distinguish digest registration from IP authentication, provider-gateway redundancy from secondary-trunk routing, unconditional PSTN Forward from conditional PSTN Backup, and signaling selection from PBX and media evidence. Public examples and portal descriptions are documentation evidence, not observed tenant state. No SIP.US account, trunk, DID, credential, registration, address, portal setting, balance, DNS answer, PBX, firewall, packet, media stream, emergency workflow, invoice or live call was inspected or tested

SIP.US trunks: identity, DID routing, failover precedence and capacity evidence

Separate registration or IP identity, current gateways, DID trunk assignment, PSTN Forward, conditional backup, channel use, PBX matching and media.

Read guide →
Provider research · Current first-party Voxtelesys portal, registrar, routing, security, call-record, emergency and service documentation reviewed October 18, 2026. DID ownership, route-profile assignment, destination priority, registered-PBX Contact, Customer IP, transfer leg, provider attempt, PBX handling, media and caller outcome remain separate evidence. The reviewed pages do not publish one complete SIP-response advancement matrix, timeout contract, retry count, restoration timer or established-call survival promise for every route. No Voxtelesys account, DID, route profile, registration, ACL, IP address, transfer, PBX, call record, packet, media stream, emergency workflow or live call was inspected or tested

Voxtelesys SIP trunking: DID route profiles, registration and failover evidence

Separate DID assignment, route profile, prioritized destinations, registration Contact, Customer IP, transfer failover, PBX handling and media.

Read guide →
Provider research · Current first-party AWS Voice Connector, group, origination, encryption, quota, number, emergency, network and pricing documentation reviewed October 18, 2026. Phone-number assignment, Voice Connector group priority, selected connector, origination-route priority and weight, AWS attempt, customer-edge receipt, PBX handling, media and caller outcome remain separate evidence. AWS documents provider-side routing controls but the reviewed pages do not establish one universal SIP-response advancement matrix, timeout schedule, restoration timer or established-call survival promise. No AWS account, Service Quotas view, phone number, Voice Connector, group, route, CloudWatch log, PBX, packet, media stream, emergency workflow or live call was inspected or tested

Amazon Chime SDK Voice Connector: groups, origination routes and evidence

Separate phone-number assignment, group priority, connector selection, origination priority and weight, encryption, quotas and customer-edge evidence.

Read guide →
Provider research · Current first-party Zoom Phone BYOC-P architecture, deployment, infrastructure, call-processing, configuration, dial-plan, emergency-calling and BYOC-messaging documentation reviewed October 9, 2026; no Zoom account, license, carrier order, number, port, SBC, firmware, certificate, private key, firewall, route group, SIP group, trunk, call, media stream, emergency workflow, message, serviceability, availability, price, compatibility or support response was inspected or tested

Zoom Phone BYOC-P: carrier, SBC and routing boundaries

Connect a retained carrier to Zoom Phone through a customer-managed SBC while keeping Zoom routing objects, E.164 numbers, protected peering and emergency responsibilities distinct.

Read guide →
Troubleshooting · Current first-party Zoom Phone BYOC-P architecture, deployment, infrastructure, call-processing, configuration, dial-plan, emergency-calling and BYOC-messaging documentation reviewed October 9, 2026; no Zoom account, license, carrier order, number, port, SBC, firmware, certificate, private key, firewall, route group, SIP group, trunk, call, media stream, emergency workflow, message, serviceability, availability, price, compatibility or support response was inspected or tested

Zoom Phone BYOC-P trunk is down or calls fail

Trace one failed call through carrier delivery, customer SBC, Zoom transport and certificate state, routing objects, E.164 normalization, destination mapping and media before changing firewall or codec policy.

Read guide →
Provider research · Current first-party Genesys Cloud BYOC Cloud architecture, carrier, trunk, routing, transport, TLS, Dynamic Cloud Voice migration, site, emergency-service, fair-use and configuration-checklist documentation reviewed October 9, 2026; the Dynamic Cloud Voice default announcement has no effective date in the reviewed record and existing trunks retain their current platform unless deliberately migrated; no Genesys Cloud organization, license, carrier order, trunk, site, location, number plan, route, peer, address, certificate, firewall, call, media stream, fax, emergency workflow, message, usage record, price, availability, compatibility or support response was inspected or tested

Genesys Cloud BYOC Cloud: carrier, trunk and Voice-platform boundaries

Connect a third-party carrier or PBX to Genesys Cloud while keeping Voice platform, region, inbound organization identity, site routing, media, emergency service and carrier ownership separate.

Read guide →
Troubleshooting · Current first-party Genesys Cloud BYOC Cloud and BYOC Premises architecture, carrier, Edge, trunk, routing, transport, TLS, Dynamic Cloud Voice migration, site, status, capacity, emergency-service and hardware-lifecycle documentation reviewed October 10, 2026; the Dynamic Cloud Voice default announcement has no effective date in the reviewed record and existing Cloud trunks retain their current platform unless deliberately migrated; Genesys states support for the BYOC Premises Genesys Hardware Solution ends December 1, 2026; no Genesys Cloud organization, license, carrier order, Edge, trunk, interface, site, location, number plan, route, peer, registration, address, certificate, firewall, call, media stream, fax, emergency workflow, message, usage record, price, capacity, availability, compatibility, migration or support response was inspected or tested

Genesys Cloud BYOC trunk is down or calls fail

First separate BYOC Cloud from BYOC Premises, then trace one failed call through the selected cloud Voice platform or premises Edge, trunk state, site routing, carrier response and media before changing firewall or routing policy.

Read guide →
Provider research · Current first-party Microsoft Azure Communication Services Direct Routing retirement, provisioning, infrastructure, SIP, monitoring, migration, emergency-calling, known-limitations, certified-SBC and pricing documentation reviewed October 9, 2026; Microsoft identifies Direct Routing for retirement on September 30, 2028 and limits continued transition-period calling to customer tenants with an existing ACS resource as of the September 2026 announcement; no Azure subscription, Communication Services resource, access token, domain, DNS record, certificate, SBC, carrier trunk, number, route, SDK application, call, media stream, emergency workflow, message, price, availability, capacity, compatibility or support response was inspected or tested

Azure Communication Services Direct Routing: retirement, SBC and application boundaries

Operate or migrate an eligible existing ACS Direct Routing deployment while keeping Azure resource, supported SBC, carrier trunk, voice route, application destination and retirement plan separate.

Read guide →
Troubleshooting · Current first-party Microsoft Azure Communication Services Direct Routing retirement, provisioning, infrastructure, SIP, monitoring, migration, emergency-calling, known-limitations, certified-SBC and pricing documentation reviewed October 9, 2026; Microsoft identifies Direct Routing for retirement on September 30, 2028 and limits continued transition-period calling to customer tenants with an existing ACS resource as of the September 2026 announcement; no Azure subscription, Communication Services resource, access token, domain, DNS record, certificate, SBC, carrier trunk, number, route, SDK application, call, media stream, emergency workflow, message, price, availability, capacity, compatibility or support response was inspected or tested

Azure Communication Services Direct Routing SBC is offline or calls fail

Trace one failed call through retirement eligibility, resource pairing, TLS and SBC-originated OPTIONS, voice-route matching, bounded failover, application delivery and media before changing DNS or carrier routing.

Read guide →
Provider research · Current first-party Google Cloud CCAI Platform BYOC, IP allow-list, location, SIP URI, high-availability, virtual-agent escalation and telephony-partner documentation reviewed October 9, 2026; the public IP allow-list page is dated October 7, 2026 and must be re-read at each change window; no CCAI Platform instance, license, support case, carrier, SBC, FQDN, address, certificate, firewall, route, number, header, SIP transaction, transfer, media stream, emergency workflow, price, capacity, availability, compatibility or call was inspected or tested

Google Cloud CCAI Platform BYOC: carrier and SIP-edge boundaries

Connect an existing carrier or enterprise SBC to CCAI Platform while keeping instance activation, call direction, authentication, regional serviceability, signaling, media and transfer ownership separate.

Read guide →
Troubleshooting · Current first-party Google Cloud CCAI Platform BYOC, IP allow-list, location, SIP URI, high-availability, virtual-agent escalation and telephony-partner documentation reviewed October 9, 2026; the public IP allow-list page is dated October 7, 2026 and must be re-read at each change window; no CCAI Platform instance, license, support case, carrier, SBC, FQDN, address, certificate, firewall, route, number, header, SIP transaction, transfer, media stream, emergency workflow, price, capacity, availability, compatibility or call was inspected or tested

Google Cloud CCAI Platform BYOC call fails or has no audio

Trace one failed BYOC call through instance activation, direction, unique SIP FQDN, directional authentication, route, header mapping, signaling and media before broadening an allowlist.

Read guide →
Troubleshooting · peoplefone Swiss SIP-TRUNK forwarding, registration, network and firewall guidance reviewed October 11, 2026; exact account, line, number assignment, re-registration behavior, provider state, forwarding role, filter, alternate destination, charge, identity, capacity and restoration remain deployment-specific, and no account, credential, PBX, endpoint, registration, forwarding rule, number, packet, outage or call was inspected or tested

peoplefone fallback does not forward after the SIP trunk goes offline

Trace one failed inbound call through registration expiry, provider line state, forwarding role, number filter, alternate destination and restoration without treating fallback as active-call survival.

Read guide →
Troubleshooting · Andrews & Arnold SIP-trunk, multiple-target, server-selection and security guidance reviewed October 11, 2026; exact account, number, DDI block, base-number inheritance, registrations, direct server target, Also Ring destinations, delay, answer, cancellation and media remain deployment-specific, and no account, credential, PBX, device, number, registration, target, packet, call or media stream was inspected or tested

A&A SIP trunk rings an old device and the PBX

Trace one duplicated inbound call through number ownership, active registrations, SIP-to-server delivery, inherited DDI targets, Also Ring branches and the winning answer.

Read guide →
Troubleshooting · SureVoIP number-destination, SIP-trace and terms pages reviewed October 12, 2026; the provider guide says a number may have up to five destinations and later destinations are attempted when the preceding one times out, while Busy and Unavailable do not count; the exact account, number, destination order, timer, DNS result, provider attempt, SIP response, PBX route and recovery behavior remain deployment-specific, and no account, portal, credential, PBX, packet, call, failover event or emergency call was inspected or tested

SureVoIP inbound call does not try the next destination

Separate an unconfigured alternate, a first-destination response and a genuine timeout before changing the PBX or expecting SureVoIP to try the next route.

Read guide →
Troubleshooting · Magrathea SIP-resilience, numbering and voice-connectivity pages reviewed October 12, 2026; Magrathea says nominated IP addresses are probed several times a minute, removed from the incoming-call pool when failure is detected and returned when responding, while the exact account, number, address list, probe method, threshold, pool state, distribution algorithm, INVITE, response, PBX route and recovery timing remain service-specific, and no account, portal, address, probe, packet, PBX, call, failover event or emergency call was inspected or tested

Magrathea SIP Resilience does not send calls to one IP

Separate the nominated destination list, Magrathea health probes, pool membership, call distribution, SIP delivery and PBX route before changing an address or expecting active-call failover.

Read guide →
Troubleshooting · NFON SIP Trunk Flexx product page and July 2024 v3.1 German technical manual reviewed October 12, 2026; the sources distinguish Primary/Backup, Round Robin, Forking and PSTN backup, while the exact account, order, mode, trunk set, endpoint membership, priority, registration or fault state, number route, INVITE, response, PBX route, timer and recovery remain deployment specific, and no account, portal, endpoint, credential, packet, PBX, call, failover event or emergency call was inspected or tested

NFON SIP Trunk Flexx backup PBX does not receive calls

Prove the ordered multi-PBX mode, trunk-set membership, endpoint priority and readiness, number routing, NFON selection and PBX route before changing registration or forcing a failure.

Read guide →
Troubleshooting · Voip Unlimited SIP-trunk DNS descriptions and RFC 3263, RFC 2782 and RFC 3403 reviewed October 13, 2026; the exact account, service FQDN, URI, transport, port, resolver, NAPTR, SRV, address answers, TTL, client support, cached state, first target, failure class, next transaction, provider edge, PBX route and recovery remain deployment specific, and no account, resolver, PBX, SBC, packet, request, response, call, failover event or media stream was inspected or tested

Voip Unlimited SIP DNS failover does not try the next target

Trace one new SIP request from URI and client discovery behavior through NAPTR, SRV, address records, cached state, selected transport, qualifying failure and the next transaction.

Read guide →
Provider research · Broadvoice current SIP Trunking product, master-service-agreement, Elastic SIP Trunking Addendum link, SIP portal, contact and support, and platform-status pages reviewed October 13, 2026; public pages do not prove the selected account, order, authentication, registration, inbound format, codec, DTMF, fax, encryption, failover mechanics, capacity limit, emergency entitlement, messaging eligibility, price or support response, and no account, portal, credential, number, PBX, SBC, packet, call, media stream, fax, failover event, load test, message or emergency call was inspected or tested

Broadvoice SIP Trunking: routing, capacity and acceptance boundaries

Keep the Broadvoice portal, PBX or cloud target, DIDs, routing, burst capacity, failover, support and signed service terms attached to the selected trunk order.

Read guide →
Provider research · SIPcity SIP Trunking, registration and peering, generic registration, 3CX, network ports and IPs, number-porting, channel, billing and master-service-agreement pages reviewed October 13, 2026; public material does not prove the selected account, order, number inventory, account-specific host, failover behavior, compatibility, negotiated media, fax entitlement, protected path, channel ceiling, call-start rate, price, support response or observed call result, and no account, portal, credential, number, PBX, packet, call, media stream, fax, failover event, load exercise, message or emergency call was inspected or tested

SIPcity SIP trunks: registration, peering and 000 boundaries

Keep SIPcity credential registration, static-IP peering, DID routing, published media parameters, channel entitlement and Australian 000 dependencies attached to the selected order.

Read guide →
Provider research · Toku Carrier Services, Microsoft Teams, Voice Connectivity, Singapore, Malaysia and Indonesia number, Singapore subscriber, portability, regulation and wholesale pages reviewed October 14, 2026; public material does not prove the selected account, universal SIP authentication or registration, DID inventory, customer failover contract, generic trunk encryption, fax, account capacity, price, compatibility, support response or observed call result, and no account, order, credential, trunk, number, PBX, SBC, packet, call, media stream, fax, failover event, load exercise, message or emergency call was inspected or tested

Toku carrier voice: APAC numbers, media and country boundaries

Keep Toku carrier coverage, selected-country numbering, E.164 delivery, media capabilities, purchased channel capacity and emergency rules attached to the exact market and order.

Read guide →
Provider research · LoopUp SIP Trunking Setup, public certificate-chain, supported-root and current AudioCodes and Ribbon configuration pages plus RFC 5246 and RFC 4568 reviewed October 14, 2026; the public material does not prove the selected account, number inventory, endpoint, certificate, DNS answer, route, DTMF method, emergency service, messaging, support entitlement, price, compatibility or observed call result, and no account, portal, credential, key, certificate, DNS answer, PBX, SBC, packet, call, media stream, fax, failover event, load exercise, message or emergency call was inspected or tested

LoopUp SIP Trunking: IP endpoints, regional routing and mutual-TLS boundaries

Keep LoopUp's no-REGISTER IP trunk, regional number assignment, endpoint distribution, channel limit, mutual TLS, SRTP, codecs and T.38 attached to the selected order and observed path.

Read guide →
Troubleshooting · Current SIPTRUNK IP-authentication, registration, status, inbound-call, failover, interconnection and general-configuration documentation reviewed October 14, 2026; the sources describe mutually exclusive credential-registration and static-public-IP modes but do not prove the selected account mode, public address, gateway resolution, Contact, registration, number assignment, route, failover treatment, capacity, compatibility or completed call, and no account, portal, credential, PBX, firewall, DNS answer, packet, registration, number, route, failover event, media stream or live call was inspected or tested

SIPTRUNK registration or IP-authentication mode does not match the call path

Determine whether the trunk uses credential registration or static-IP authentication, then trace the exact public address, gateway, Contact or stored destination, provider state, inbound route and failover treatment.

Read guide →
Troubleshooting · Current SIP.US interconnection, device configuration, registration-status, failover, glossary, IP-authentication and Asterisk guidance reviewed October 14, 2026; the current interconnection guide says the enhanced network uses gw4.sip.us and gw5.sip.us and legacy gw1/gw2-only systems no longer register or receive inbound calls, while an older registration-status paragraph still names gw1 in its SRV example, so current gateway documentation takes precedence; no account, portal, credential, registration, DNS answer, firewall, NAT mapping, PBX, trunk assignment, DID, packet, route, failover event, media stream or live call was inspected or tested

SIP.US primary gateway works but failover or inbound calls fail

Separate current gateway selection, registration or IP authentication, inbound Contact reachability, DID trunk assignment, secondary-trunk routing and PSTN Backup before changing a working primary path.

Read guide →
Troubleshooting · Current first-party Flowroute and BCM One documentation reviewed October 18, 2026. The current support pages were updated August 27, 2026 and list the Oregon and Virginia PoPs, require all listed signaling ranges for provider-side failover and load balancing, and describe Direct Media as RTP from potentially any source IP to the customer system public media-port range. Older but still public first-party route documentation distinguishes route objects from each number's primary and failover relationships, registration from Host or URI delivery, and preferred inbound PoP selection from customer-destination failover. Documentation and examples are not observed tenant state. No Flowroute account, credential, number, route, registration, DNS answer, certificate, PBX, firewall, packet, media stream, invoice, emergency workflow or live call was inspected or tested

Flowroute number does not use the intended route, PoP or failover path

Prove the number relationships, route type, preferred provider edge, first result, any later attempt, PBX handling and direct-media result.

Read guide →
Troubleshooting · DIDWW failover, trunk-group and response-code documentation updated October 7–8, 2026 was reviewed October 14, 2026; it documents priority, weight, ringing timeout, selected re-routing disconnect codes, capacity controls, DNS SRV and a separate CDR for each routing attempt, but no account, DID, trunk group, endpoint, DNS answer, capacity state, request, response, CDR stream, failover event, media stream or live call was inspected or tested

DIDWW inbound trunk group does not try the next trunk

Prove DID assignment, trunk-group membership, priority and weight, the configured rerouting-code set, ringing timeout, capacity and every DIDWW CDR attempt before changing a working inbound route.

Read guide →
Troubleshooting · Current Twilio Elastic SIP Trunking configuration, troubleshooting, sending-SIP, CredentialList, Trunk-resource and error-32201 documentation reviewed October 14, 2026; the sources distinguish Termination URI identification, DNS and edge selection, IP ACL and credential authentication, 407 challenge flow, E.164 addressing, caller identity and later account policy, but do not prove one account, trunk, ACL, credential list, source address, DNS answer, route, caller identity, permission, capacity state, packet, media stream or completed call, and none was inspected or tested

Twilio termination call gets no response or 403 Forbidden

Separate Termination URI and DNS reachability from initial-INVITE ACL rejection, post-407 credential failure, E.164 addressing, caller identity, geographic permission and capacity policy.

Read guide →
Troubleshooting · Current public Sangoma SIPStation troubleshooting, inbound-failover, access-restriction, FreePBX module, PJSIP, PBX-configuration and inbound-route documentation reviewed October 14, 2026; the sources document registration-style and optional peer-to-peer service, primary and secondary SIPStation delivery, configured global or per-DID failover, FreePBX DID routing and capture guidance, but they do not establish the state of any account, credential, registration, number, trunk group, gateway, DNS answer, firewall, NAT mapping, route, destination, failover event, packet, media stream or live call, and none was inspected or tested

SIPStation inbound call does not reach FreePBX or the intended failover

Follow one DID from trunk-group assignment and registration mode through SIPStation delivery, any provider fallback, the first PBX request, inbound-route match and final caller outcome.

Read guide →
Provider research · Current IP Telecom SIP Trunks, SIP Trunking product terms, Fair Use Policy, Ireland copper-transition and contact pages reviewed October 15, 2026; authentication method, registrar and proxy values, DNS behavior, technical routing, codecs, DTMF, RTP addresses, fax, emergency calling, messaging, exact failover, capacity entitlement, availability, compatibility, pricing and support performance remain order specific, and no account, quote, credential, number, port, PBX, endpoint, access circuit, packet, media stream, failover event, load exercise, message, emergency call or live call was inspected or tested

IP Telecom SIP trunks: Irish service, resilience and demarcation boundaries

Scope IP Telecom channel capacity, number porting, access resilience, optional TLS and SRTP, provider demarcation and unresolved technical handoff to the exact Irish business order.

Read guide →
Provider research · Current Clearfly service, FAQ, partner, support and legal pages reviewed October 15, 2026; authentication, registrar and proxy values, DNS behavior, codecs, DTMF, RTP ranges, signaling and media protection, T.38, emergency behavior, capacity limits, routing triggers, current availability, compatibility, exact pricing and support performance remain order specific, and no account, quote, credential, number, port, PBX, endpoint, circuit, portal session, packet, media stream, failover event, load exercise, message, emergency call or live call was inspected or tested

Clearfly SIP trunking: service scope, portal controls and acceptance boundaries

Scope Clearfly trunk quantity, number services, routing features, portal controls, support and unresolved technical handoff to the exact partner-managed order.

Read guide →
Provider research · Current Redcentric voice-modernisation, communications, support and status pages reviewed October 15, 2026; the public SD032 v2.1 PDF is retained only as a legacy service-design reference, not a current contract or topology. Authentication, registrar and proxy, DNS, codecs, DTMF, RTP, TLS and SRTP, capacity, fax, messaging, emergency process, pricing, SLA, availability and compatibility remain order specific. No account, quote, order, credential, trunk, number, port, PBX, SBC, circuit, portal session, packet, media stream, failover event, emergency call or live call was inspected or tested

Redcentric SIP trunks: managed migration, circuit dependency and acceptance boundaries

Scope Redcentric SIP trunks to the exact managed-voice order, current handoff, circuit design, number migration, cutover and support responsibilities.

Read guide →
Provider research · Current CommPeak SIP-trunk product, documentation hub, SIP-account, FreePBX, Asterisk, pricing and status pages reviewed October 15, 2026. Password and IP authentication, sip.commpeak.com examples, FreePBX chan_pjsip steps, a chan_sip-style Asterisk example, routing, monitoring and support are documented; selected-account DNS, proxies, registration timers, inbound numbers, codec and DTMF profile, RTP, TLS and SRTP profile, capacity, failover, fax, emergency service, messaging, pricing, SLA, availability and compatibility remain account, route and contract specific. No account, quote, contract, credential, trunk, number, port, PBX, portal session, packet, media stream, failure event, emergency call or live call was inspected or tested

CommPeak SIP trunks: account method, PBX examples and acceptance boundaries

Qualify CommPeak against the selected SIP account, current portal settings, PBX generation, route scope and observed signaling and media.

Read guide →
Provider research · Current Voximplant SIP-trunking solution, SIP connection and registration FAQs, call-scenario and CallSIP references, telephony capability FAQ, pricing and status pages reviewed October 15, 2026. IP-allowlisted PBX ingress, application-rule and VoxEngine scenario handling, separate SIP-user registration, outbound SIP authentication, UDP/TCP/TLS, SDES/DTLS media protection, codec and DTMF capabilities and public usage pricing are documented; selected-account DNS, proxies, numbers, registration timers, capacity, routing, failover, fax, emergency service, messaging, prices, SLA, availability and interoperability remain account, route, application and contract specific. No account, allowlist, credential, application, scenario, trunk, number, PBX, packet, media stream, failover event, emergency call or live call was inspected or tested

Voximplant SIP trunking: allowlists, application routing and call-leg boundaries

Qualify a Voximplant PBX connection across allowlist or registration, application rule, VoxEngine scenario, external SIP or PSTN leg, media and commercial scope.

Read guide →
Provider research · Current public Voip Unlimited SIP-trunk, voice, partner, legal and Master Services Agreement V3.0 material plus RFC 3263, RFC 2782 and RFC 3403 reviewed October 17, 2026. The SIP service schedule defines a trunk as one registration containing one or more channels, describes account-issued credential details, headline-number and DDI alias routing, portal diversion, non-registration SMS alerts, porting checks and emergency-address obligations. Public product material documents SIP Lite, SIP Unlimited, Bundle Plus, NAPTR, SRV, IPv6, SRTP and T.38-bypass concepts. The selected order, issued registrar and credentials, active binding, assigned and ported numbers, delivered identities, PBX routes, caller identity, codec, DTMF, negotiated protection, fax outcome, DNS answers, access path, service incident, price, availability and compatibility remain account, contract or observation specific. No account, order, portal, credential, PBX, trunk, number, port, resolver, packet, media stream, fax, emergency call or live call was inspected or tested

Voip Unlimited SIP trunks: registration, DDI routing and call evidence

Qualify one Voip Unlimited SIP service by its issued registration, channel model, headline number, DDI aliases, DNS path, portal controls, negotiated media and observed calls.

Read guide →
Troubleshooting · Current public Voip Unlimited SIP-trunk, voice, partner, legal and Master Services Agreement V3.0 material plus RFC 3263, RFC 2782 and RFC 3403 reviewed October 17, 2026. The SIP service schedule defines a trunk as one registration containing one or more channels, describes account-issued credential details, headline-number and DDI alias routing, portal diversion, non-registration SMS alerts, porting checks and emergency-address obligations. Public product material documents SIP Lite, SIP Unlimited, Bundle Plus, NAPTR, SRV, IPv6, SRTP and T.38-bypass concepts. The selected order, issued registrar and credentials, active binding, assigned and ported numbers, delivered identities, PBX routes, caller identity, codec, DTMF, negotiated protection, fax outcome, DNS answers, access path, service incident, price, availability and compatibility remain account, contract or observation specific. No account, order, portal, credential, PBX, trunk, number, port, resolver, packet, media stream, fax, emergency call or live call was inspected or tested

Voip Unlimited trunk registers but inbound DDI calls fail

Follow one affected DDI from provider assignment, port and headline alias through the registered Contact, first INVITE, PBX identity match, loaded route, destination and caller outcome.

Read guide →
Provider research · Current SignalWire SIP trunking, SIP Credential, SIP Profile, FreePBX, caller identity, rate-limit and E911 documentation reviewed October 17, 2026. The documentation distinguishes a project SIP Profile, one SIP Credential, a number-to-resource assignment, Resource SIP Addresses, the credential call handler, permitted outbound identity, PBX registration and dialplan, negotiated signaling and media, account-level call-start limits and number-level E911 provisioning. The selected Space, project, profile revision, credential, password, handler, phone number, assigned resource, PBX object, route, caller identity, encryption, codec, cipher, call rate, concurrency, emergency record, availability, price and compatibility remain account, configuration or observation specific. No account, project, credential, profile, number, resource, PBX, registration, packet, media stream, emergency workflow or live call was inspected or tested

SignalWire SIP trunking: credentials, resources and call-path evidence

Separate the SIP Profile, credential registration, call handler, phone-number assignment, Resource SIP Address, PBX route, caller identity, encryption, media and E911 state.

Read guide →
Troubleshooting · Current SignalWire SIP trunking, SIP Credential, SIP Profile, FreePBX, caller identity, rate-limit and E911 documentation reviewed October 17, 2026. The documentation distinguishes a project SIP Profile, one SIP Credential, a number-to-resource assignment, Resource SIP Addresses, the credential call handler, permitted outbound identity, PBX registration and dialplan, negotiated signaling and media, account-level call-start limits and number-level E911 provisioning. The selected Space, project, profile revision, credential, password, handler, phone number, assigned resource, PBX object, route, caller identity, encryption, codec, cipher, call rate, concurrency, emergency record, availability, price and compatibility remain account, configuration or observation specific. No account, project, credential, profile, number, resource, PBX, registration, packet, media stream, emergency workflow or live call was inspected or tested

SignalWire SIP credential registers but calls fail

Follow one failed inbound or outbound call through the SIP Profile, credential handler, number assignment, PBX context or route, caller identity, encryption, SDP, media and provider log.

Read guide →
Troubleshooting · Current first-party Telnyx SIP Connection, authentication, inbound routing, failover, response-code, Outbound Voice Profile, round-robin, network and configuration-guide documentation reviewed October 17, 2026. The current network page and machine-readable `voice.json` version 2026-05-25 publish Canada signaling addresses `192.76.120.31` and `64.16.250.13`, while the currently accessible failover guide lists `193.108.220.10` and `193.108.220.25`; this source disagreement is preserved rather than resolved editorially. The selected account, number, Connection, authentication method, registered instance, inbound region, DNS answer, signaling address, route order, response, Outbound Voice Profile, channel control, PBX, firewall, packet, media, availability, price and compatibility remain account, configuration, time or observation specific. No account, Connection, number, profile, DNS lookup, firewall, PBX, packet, route, failover event, media stream or live call was inspected or tested

Telnyx inbound route or failover is wrong

Trace one inbound call through number-to-Connection assignment, authentication type, selected region, current network evidence, route order, provider response, PBX match and any next attempt.

Read guide →
Troubleshooting · Current first-party Bandwidth Build SIP trunking and number-feature documentation reviewed October 17, 2026. The Build path uses number-level prioritized inbound routes containing weighted endpoints; outbound setup uses a realm plus SIP credentials. The reviewed public pages do not publish the exact response, timeout, retry, registration, codec, TLS, SRTP or account-capacity contract for every Bandwidth trunk product, so none is invented. Route priority, endpoint weight, Final Destination URI, call forwarding, asynchronous number-option order state, PBX handling, media and caller outcome remain separate evidence. No Bandwidth account, number, route, endpoint, realm, credential, order, DNS answer, PBX, packet, failover event, media stream or live call was inspected or tested

Bandwidth inbound route or failover is wrong

Trace one inbound call through number voice configuration, prioritized routes, weighted endpoints, option-order state, provider attempts, PBX matching and media.

Read guide →
Troubleshooting · Current first-party Voipfone registration, third-party PBX, number-routing, call-divert, porting, emergency-address and terms documentation reviewed October 17, 2026. Account-number registration, telephone-number routing, PBX delivery and customer-side fallback remain separate controls. Portal labels and legacy chan_sip examples do not establish a current PJSIP profile, one universal delivered DID form or the behavior of an uninspected account. No account, credential, number, port, route, divert, extension, PBX, registration, provider attempt, packet, media stream, emergency workflow or live call was inspected or tested

Voipfone inbound number or fallback is wrong

Trace one inbound call through telephone-number routing, account registration, provider delivery, PBX matching, divert precedence, fallback and media.

Read guide →
Troubleshooting · Current first-party VoIP.ms DID-routing, POP-selection, subaccount, registration, troubleshooting, encryption and emergency-service documentation reviewed October 17, 2026. DID ownership, primary route, POP, registration identity, delivered number format, failover state, PBX match and media remain separate evidence. Portal state and provider echo-test results do not establish one uninspected PBX, network path or live call. No account, DID, subaccount, credential, POP, route, failover event, PBX, registration, packet, media stream, emergency workflow or live call was inspected or tested

VoIP.ms DID, POP or failover is wrong

Trace one inbound call through DID ownership, primary route, POP alignment, SIP identity, delivered number format, failover state, PBX match and media.

Read guide →
Troubleshooting · Current first-party Twilio Elastic SIP Trunking configuration, OriginationUrl, failover, IP-address, troubleshooting and Trunk-resource documentation reviewed October 17, 2026. Number association, Trunk SID, enabled Origination URLs, priority, weight, edge selection, provider attempt, SIP result, disaster-recovery webhook, TwiML result, PBX handling and media remain separate evidence. The OriginationUrl page currently contains conflicting default-value presentation, so effective values must be read explicitly. No Twilio account, number, trunk, OriginationUrl, disaster-recovery application, PBX, SBC, DNS answer, firewall, packet, media stream or live call was inspected or tested

Twilio origination URI, failover or disaster recovery is wrong

Trace one inbound call through number association, enabled Origination URLs, priority and weight, edge selection, SIP results, disaster recovery, PBX handling and media.

Read guide →
Troubleshooting · Current first-party Plivo Zentrunk quickstart, technical-specification, account-limit, hangup-code and debug-log documentation reviewed October 18, 2026. Number assignment, inbound trunk, primary and fallback URI, URI authentication, DNS result, provider attempt, SIP response, hangup source and cause, PBX handling, answer and each media direction remain separate evidence. Plivo documents fallback when the primary URI is unresponsive, not as a universal retry after every SIP final response. No Plivo account, trunk, number, URI, credential, PBX, DNS answer, firewall, packet, media stream or live call was inspected or tested

Plivo inbound primary or fallback URI is wrong

Trace one inbound call through number assignment, trunk and URI state, primary reachability, fallback eligibility, SIP results, PBX routing and media.

Read guide →
Troubleshooting · Current first-party Vonage SIP technical, dashboard, Asterisk, FreePBX and Voice Logs documentation reviewed October 18, 2026. Number ownership, number-to-trunk link, trunk type, inbound region, SIP URI, priority, timeout, DNS result, provider attempt, transport, PBX identification, route, answer and each media direction remain separate evidence. Priority orders eligible URIs; the reviewed pages do not publish one universal SIP-response advancement matrix. No Vonage account, number, trunk, URI, credential, PBX, DNS answer, firewall, packet, media stream or live call was inspected or tested

Vonage inbound SIP URI priority or timeout is wrong

Trace one inbound call through number linking, trunk and region, ordered SIP URIs, timeout, transport, PBX identification, routing and media.

Read guide →
Troubleshooting · Current first-party Voxtelesys portal, registrar, routing, security, call-record, emergency and service documentation reviewed October 18, 2026. DID ownership, route-profile assignment, destination priority, registered-PBX Contact, Customer IP, transfer leg, provider attempt, PBX handling, media and caller outcome remain separate evidence. The reviewed pages do not publish one complete SIP-response advancement matrix, timeout contract, retry count, restoration timer or established-call survival promise for every route. No Voxtelesys account, DID, route profile, registration, ACL, IP address, transfer, PBX, call record, packet, media stream, emergency workflow or live call was inspected or tested

Voxtelesys DID route profile or failover is wrong

Trace one inbound call through DID assignment, route profile, destination priority, registration or IP state, provider attempt, PBX match, transfer and media.

Read guide →
Troubleshooting · Current first-party AWS Voice Connector, group, origination, encryption, quota, number, emergency, network and pricing documentation reviewed October 18, 2026. Phone-number assignment, Voice Connector group priority, selected connector, origination-route priority and weight, AWS attempt, customer-edge receipt, PBX handling, media and caller outcome remain separate evidence. AWS documents provider-side routing controls but the reviewed pages do not establish one universal SIP-response advancement matrix, timeout schedule, restoration timer or established-call survival promise. No AWS account, Service Quotas view, phone number, Voice Connector, group, route, CloudWatch log, PBX, packet, media stream, emergency workflow or live call was inspected or tested

Amazon Chime Voice Connector group or origination route is wrong

Trace one inbound call through number assignment, group priority, connector selection, origination route, AWS evidence, customer edge, PBX and media.

Read guide →
Troubleshooting · Current first-party Callcentric SIP-trunk, registration, DID Forward, Call Treatment, Network Down Forward and forwarded-call billing documentation reviewed October 18, 2026. Outgoing plan, incoming number, 1777 registration identity, DID Forward, Call Treatment, network-down condition, forwarded PSTN leg, PBX receipt, answer and media remain separate evidence. Callcentric expressly states that a DID Forward takes higher priority than Call Treatments and that a forwarded call has incoming and outgoing legs, but the reviewed pages do not publish one universal health signal, response-code matrix, timer, retry count, restoration interval or established-call survival promise for Network Down Forward. No Callcentric account, extension, credential, number, rule, registration, PBX, packet, bill, media stream or live call was inspected or tested

Callcentric DID Forward or Network Down Forward is wrong

Trace the incoming number through direct DID Forward precedence, Call Treatments, network-down eligibility, the PBX path and the separate forwarded leg.

Read guide →
Troubleshooting · Current first-party Anveo Direct FAQ, inbound DID, outbound termination, network and services pages reviewed October 18, 2026. The pages distinguish source-IP-authenticated outbound service, inbound delivery to a SIP URI, optional backup SIP URI, Anveo signaling sources and media sent directly by an underlying carrier. SIP REGISTER is not supported. The reviewed pages do not publish one universal failover trigger, SIP-response matrix, timeout, retry count, restoration interval, RTP source inventory, port range or active-call survival promise. No Anveo Direct account, DID, add-on, trunk, authorized address, SIP URI, PBX, firewall, packet, carrier media path, bill or live call was inspected or tested

Anveo Direct signaling works but audio or SIP-URI failover fails

Trace the DID destination, provider signaling, primary and backup URI attempts, direct carrier RTP and PBX handling without treating REGISTER as a health signal.

Read guide →
Troubleshooting · Current first-party CarrierX trunk-group, trunk, SIP-trunk, call and phone-number documentation reviewed October 18, 2026. The pages distinguish DID assignment, trunk-group routing type, per-trunk priority and weight, soft and hard SIP failure handling, SIP OPTIONS monitoring, endpoint authorization, capacity and codecs. Documented defaults are configuration references, not observed account values. The reviewed pages do not establish SIP REGISTER as the inbound binding, one universal failover result for every response, access-path diversity, established-call survival or an account-wide calls-per-second limit. No CarrierX account, API response, DID, endpoint, trunk group, trunk, ACL, credential, token, PBX, packet, media stream, rate, emergency workflow or live call was inspected or tested

CarrierX trunk-group failover or round-robin selects the wrong trunk

Trace DID assignment, routing type, priority or weight, hard and soft failures, SIP OPTIONS state, endpoint delivery and PBX handling for one CarrierX call.

Read guide →
Troubleshooting · Current first-party AVOXI outbound-trunk, inbound SIP-URI, diagnostic and network documentation reviewed October 18, 2026. The pages distinguish outbound authentication from inbound forwarding, named SIP URIs from number routing targets, terminal response codes from other failures, on-demand test calls from customer calls, and signaling from media. Public examples and defaults are documentation evidence, not observed tenant values. No AVOXI account, number, routing rule, SIP URI, trunk, credential, PBX, firewall, packet, media stream, invoice or live call was inspected or tested

AVOXI inbound SIP URI target or terminal response is wrong

Trace one AVOXI number through its enabled routing rule, named SIP URI, terminal-code policy, provider attempt, PBX response and media.

Read guide →
Troubleshooting · Current first-party Easybell registration, Trusted IP, trusted-FQDN and automatic-fallback documentation reviewed October 18, 2026. The pages distinguish inbound and outbound authentication, registration from IP-only delivery, sequential trusted-IP attempts from offline forwarding, DNS acceptance from later DNS answers, and provider selection from PBX handling. Public examples and defaults are documentation evidence, not observed tenant values. No Easybell account, connection, number block, credential, address, FQDN, DNS answer, PBX, firewall, packet, media stream, invoice or live call was inspected or tested

Easybell trunk registers but Trusted IP or FQDN inbound calls miss the PBX

Trace one inbound call through Easybell’s directional authentication mode, stored address or FQDN, provider attempt, PBX match, offline forwarding and media.

Read guide →
Troubleshooting · Current first-party SIP.US identity, registration, gateway, DID routing, failover, channel-capacity and E911 documentation reviewed October 18, 2026. The pages distinguish digest registration from IP authentication, provider-gateway redundancy from secondary-trunk routing, unconditional PSTN Forward from conditional PSTN Backup, and signaling selection from PBX and media evidence. Public examples and portal descriptions are documentation evidence, not observed tenant state. No SIP.US account, trunk, DID, credential, registration, address, portal setting, balance, DNS answer, PBX, firewall, packet, media stream, emergency workflow, invoice or live call was inspected or tested

SIP.US DID bypasses the PBX or PSTN Backup does not engage

Trace one inbound call through DID ownership, Forward and Backup precedence, identity mode, trunk assignment, channel use, PBX handling and media.

Read guide →
Troubleshooting · Current first-party Flowroute and BCM One documentation reviewed October 18, 2026. The current support pages were updated August 27, 2026 and list the Oregon and Virginia PoPs, require all listed signaling ranges for provider-side failover and load balancing, and describe Direct Media as RTP from potentially any source IP to the customer system public media-port range. Older but still public first-party route documentation distinguishes route objects from each number's primary and failover relationships, registration from Host or URI delivery, and preferred inbound PoP selection from customer-destination failover. Documentation and examples are not observed tenant state. No Flowroute account, credential, number, route, registration, DNS answer, certificate, PBX, firewall, packet, media stream, invoice, emergency workflow or live call was inspected or tested

Flowroute call signaling works but audio is missing

Separate SIP completion from Direct Media by preserving SDP, public media ports, translated addresses, observed RTP sources, packet direction and decoded audio.

Read guide →
Troubleshooting · The current ClearlyIP product page and first-party configuration references were reviewed October 18, 2026. The legacy knowledge base now expressly says that it is no longer updated and directs readers to kb.14ip.com; its registration, Location, number-routing, failover and FreePBX-module details are therefore retained only as historical workflow evidence that must be confirmed against the replacement documentation, current portal, installed module and running PBX. The batch separates product availability from documentation currency, number ownership from Smart Routing, Location and SubLocation registration from inbound route matching, generated FreePBX objects from loaded state, and failover configuration from an observed provider attempt. No ClearlyIP account, Location, SubLocation, number, credential, keycode, module, PBX, registration, DNS answer, route, failover event, packet, media stream, price, availability, compatibility, capacity or live call was inspected or tested

ClearlyIP trunk registers but DID routing or failover is wrong

Trace the number owner, Location or Smart Routing mode, delivered identity, generated FreePBX route and effective failover rule without treating registration as end-to-end proof.

Read guide →
Troubleshooting · Current first-party Simwood Hosted SIP Trunks, interop, trunk overview, Asterisk 16 sample, hosted TLS/SRTP, Partner and Direct whitelisting and portal material were reviewed October 19, 2026. The batch keeps Hosted, Partner, Direct, Wholesale and Carrier Services scopes separate; outbound digest authorization separate from inbound registration; Contact user separate from the called-number value in To; configured routes separate from observed delivery; and the version-scoped Asterisk 16 example separate from current FreePBX or Asterisk configuration. No Simwood account, trunk, credential, number, registration, PBX, FreePBX route, DNS answer, firewall, packet, media stream, failover event, price, availability, compatibility, capacity or live call was inspected or tested

Simwood outbound works but inbound registration or routing fails

Trace a Hosted trunk from registration and Contact-user addressing through the provider attempt, PJSIP identification, context and called-number route without treating outbound digest success as inbound proof.

Read guide →
Troubleshooting · Current first-party Sinch Voice API SIP Trunking, callback, authentication, call-header, CDR and release-note material and retained Elastic and BYOC product-scope pages were reviewed October 19, 2026. The batch keeps the Voice API static SIP trunk path separate from Elastic and BYOC products and from Callback API control; termination toward Sinch separate from origination toward the customer; each flow's application configuration separate; regional FQDNs separate from their current address ranges; SIP signaling separate from RTP; and configured TLS or SRTP separate from observed negotiation. No Sinch account, application, key, secret, number, trunk, callback endpoint, DNS answer, certificate, PBX, firewall, packet, CDR, media stream, price, availability, compatibility, capacity or live call was inspected or tested

Sinch termination works but origination or audio fails

Trace separate Voice API applications, regional FQDNs, forwarding or callback control, customer-edge receipt, PBX routing, TLS, SDP and media without treating one working direction as proof of the other.

Read guide →