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

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Reviewed 2026-10-19Foundational

Explore SIP trunking: numbers, capacity and operational control

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 →

Separate service from platform

A trunk supplies a carrier connection; your PBX supplies internal call handling. Number ownership, concurrent capacity, calling permissions and billing should be documented independently. Start with what a SIP trunk is when these distinctions are new.

The parts of a VoIP system
A phone or app sends calls to a PBX, which connects through a trunk or service to other networks. A phone number routes incoming calls to PBX destinations.

A simplified logical view. A hosted service may combine PBX and carrier functions; actual signaling and media paths can differ.

Choose a supported interconnection

Collect the carrier's current authentication, transport, number-format and media requirements. Follow the Asterisk trunk workflow or FreePBX trunk workflow for your platform. Do not treat another carrier's configuration as a universal template.

Design failure behavior

Verify incoming-number diversion separately from outbound trunk fallback. A second carrier does not remove PBX, power or network dependencies. Test the behavior under the specific failure you expect to survive.

Keep the account governable

Assign ownership for billing, spend alerts, number changes and incident escalation. Restrict expensive destinations and review authorized caller identities. Keep commercial links separate from the technical configuration record; changing an affiliate relationship should never alter factual compatibility guidance.

Separate IP Telecom service scope from its technical handoff

IP Telecom publicly describes an Irish business SIP-trunk service but does not publish one complete registrar, authentication, codec or RTP profile. The provider record requires the issued handoff, loaded PBX state and observed path instead of invented defaults.

Separate Clearfly service features from the SIP handoff

Clearfly publicly describes SIP trunking and portal-managed voice services but does not publish one complete registrar, authentication, codec or RTP profile. The provider record requires the issued handoff, loaded PBX state and observed path.

Separate Redcentric programme scope from the trunk handoff

Redcentric presents SIP trunks within a broader voice-modernisation programme. The provider record requires the current order, handoff, loaded PBX or SBC state and observed path instead of assuming legacy technical details remain current.

Do not collapse CommPeak products into one trunk scope

CommPeak publishes termination, DIDs, messaging, Cloud PBX, Dialer and Softphone products. The provider record requires the signed scope and selected SIP account before treating any adjacent capability as part of the trunk.

Do not collapse Voximplant platform paths into one trunk

Voximplant documents IP-allowlisted PBX ingress, SIP-user registration and scenario-originated SIP calls as different patterns. The provider record requires one selected design and direction before configuration or acceptance.

Do not flatten TelVox provisioning into trunk readiness

A TelVox create response starts at pending and later may become active. The provider record keeps API success, active state, loaded PBX credentials, registration, signaling, media and user outcome as distinct gates.

Keep VoIP Much registration distinct from call acceptance

VoIP Much documents registration-based PBX examples, but a completed REGISTER does not prove number routing, caller identity, channel entitlement, answer or media. The provider profile and focused workflow preserve those gates.

Do not merge VoIPline interconnect modes

VoIPline documents registration, URI diversion and a Teams gateway as separate modes. Use the provider profile to preserve each identity and acceptance boundary.

Do not treat a registered Voip Unlimited trunk as an inbound route

The Voip Unlimited profile distinguishes the binding from DDI assignment, provider delivery, PBX identity, route matching and media.

Do not turn a SignalWire SIP Credential into the whole trunk

SignalWire separates profile defaults, credential registration, inbound resources and outbound handling. The provider guide and failed-call diagnostic preserve each boundary.

Keep Telnyx inbound and outbound control objects distinct

Telnyx uses a SIP Connection and number assignment for inbound delivery, while the Outbound Voice Profile controls outbound associations, destinations, rate and spend policy. The Telnyx diagnostic starts with the inbound objects actually used.

Separate Bandwidth inbound routes from outbound realm credentials

Bandwidth Build assigns inbound routes to a SIP-trunking number and uses a realm plus credentials for outbound calls. The Bandwidth diagnostic starts with the number and actual inbound attempts.

Separate a Voipfone registration from inbound-number ownership

Voipfone’s published PBX examples register an account number, while control-panel routing applies to telephone numbers. The Voipfone diagnostic preserves both identities.

Match each VoIP.ms DID POP to the intended identity

VoIP.ms documents a per-DID POP that must match the registration server or proxy. The VoIP.ms diagnostic preserves both controls.

Inventory Twilio numbers and Origination URLs as separate objects

A Twilio number association, Trunk SID and enabled OriginationUrl resource are different evidence. Follow them through the Twilio origination diagnostic.

Inventory Plivo inbound objects by direction

A Plivo number link, inbound trunk, primary URI and fallback URI are separate from outbound authentication. Follow them through the Plivo inbound diagnostic.

Inventory Vonage inbound objects before troubleshooting

A Vonage number link, trunk type, inbound region, SIP URI, priority and timeout are distinct. Follow them through the Vonage inbound diagnostic.

Do not collapse Voxtelesys registration and DID routing

A Voxtelesys registration supplies a current Contact, while a DID separately selects a route profile and prioritized destination. The diagnostic follows both.

Follow Amazon Chime inbound selection in two stages

Amazon Chime can select a Voice Connector from a group before applying that connector’s origination priorities and weights. The diagnostic preserves both decisions.

An outbound didlogic call does not prove the inbound DID path

The didlogic inbound-DID diagnostic separates egress authentication from number destination, provider delivery, PBX matching and media.

Separate Callcentric registration, number and forwarding rules

A 1777 registration binding, incoming DID, direct DID Forward and Network Down Call Treatment are different objects. The diagnostic follows each one.

Do not add REGISTER to an Anveo Direct trunk

Anveo Direct documents source-IP-authenticated outbound service and SIP-URI inbound delivery without REGISTER. Use the diagnostic for the direction-specific evidence chain.

Map CarrierX objects before copying a trunk template

A CarrierX DID, trunk group, trunk and endpoint are separate objects. Use the diagnostic to prove their current linkage before changing the PBX.

Map the AVOXI number rule before changing the PBX

An AVOXI SIP URI becomes a live inbound path only when an enabled number rule targets it. Use the diagnostic to preserve that mapping and its shared-edit scope.

Map Easybell identity before interpreting registration

A successful REGISTER does not prove inbound delivery when Trusted IP or FQDN owns the path. Use the diagnostic to follow one call.

Do not flatten SIP.US identity and DID treatment

Credential registration, IP authentication, trunk assignment, Forward and Backup can diverge. The SIP.US diagnostic follows one inbound call through those boundaries.

Flowroute has more than one recovery layer

Provider-edge selection, the number's failover relationship and the customer media path are separate. Use the Flowroute guide to preserve each observed attempt.

Do not transfer Bulk Solutions outbound success to inbound DID delivery

The Bulk Solutions diagnostic follows the independently owned DID assignment, destination, PBX match and media path.

Do not transfer Yay.com outbound success to inbound routing

The Yay.com diagnostic starts with the number-to-trunk assignment before PBX or media changes.

Registration does not establish ClearlyIP number routing

The ClearlyIP diagnostic starts with the number owner and routing mode before PBX changes.

Simwood outbound authorization is not an inbound binding

The Simwood diagnostic proves REGISTER and Contact independently of a successful outbound challenge.

Sinch uses different controls for each direction

The Sinch diagnostic keeps termination credentials separate from origination application assignment and SIP forwarding.

SIPTRUNK registration is not end-to-end proof

The SIPTRUNK diagnostic follows one DID from the provider destination through PBX routing and RTP.

Sources & applicability

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

Continue your research

Guide · SIP, SDP, media-security and Asterisk PJSIP documentation reviewed October 5, 2026; no carrier account, number, PBX, trunk, route, call, media stream, failover, emergency workflow, price, availability or compatibility was inspected or tested

What is a SIP trunk? Service, identity, media and capacity boundaries

Understand a SIP trunk as a provider-to-PBX service relationship, then separate numbers, identity, signaling, media, capacity, failover and emergency obligations.

Read guide →
Guide

SIP trunk channels and simultaneous calls

Size external capacity around busy-hour demand and the provider’s counting rules.

Read guide →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

Business number porting: a cutover checklist

Keep ownership records, dependencies and a fallback plan aligned with the gaining provider’s process.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Provider research · 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 Elastic SIP Trunking: origination URI, priority, weight and recovery evidence

Keep number association, enabled Origination URLs, priority, weight, edge selection, SIP results, disaster recovery, PBX handling and media separately observable.

Read guide →
Provider research · 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 SIP trunking: connections, regions and route evidence

Separate number assignment, Connection authentication, inbound region, current network evidence, route order, failover response, outbound policy and PBX handling.

Read guide →
Provider research · First-party public documentation reviewed September 30, 2026; no account, endpoint, call, rate deck or support response was tested

Skyetel SIP Trunking: endpoint groups, registration and failover research

Keep IP-group delivery, credential registration, failover handling, emergency identity and unverified service claims separate.

Read guide →
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 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 TelVox Connect trunk, authentication, call, number, recording, webhook, pricing and security documentation plus Renav Limited company identification reviewed October 16, 2026; Connect is live but its API is v0.x, and coverage, portability, emergency calling, fax, messaging, codecs, DTMF transport, RTP, media protection, redundancy, concurrency, call-start limits, availability, compatibility, exact pricing and support performance remain account, order, route or version specific; no account, API key, trunk, SIP credential, number, registration, webhook, callback, recording, packet, media stream, emergency call or live call was inspected or tested

TelVox Connect SIP trunks: provisioning, credentials and call evidence

Separate TelVox API access, trunk lifecycle, SIP registration, webhooks, callbacks and call outcomes while keeping pre-v1 and account-specific limits explicit.

Read guide →
Provider research · Current VoIP Much SIP-trunk product, 3CX, FreePBX, UniFi Talk, IP-blocking, SIP ALG, codec, quality, status and service-agreement pages reviewed October 16, 2026. Registration-based account examples, account-issued server and credentials, paid channel scope, supported codec lists, SIP-server port guidance and several network cautions are documented; selected-account DNS, transport and proxy profile, number inventory, caller identity, routing, failover, RTP range, DTMF, fax, emergency service, messaging, encryption, capacity, price, SLA, availability and compatibility remain account, route, contract or observation specific. No account, order, credential, trunk, number, registration, packet, media stream, status incident, emergency call or live call was inspected or tested

VoIP Much SIP trunks: registration, channels and acceptance evidence

Qualify a VoIP Much trunk against the account-issued server and credentials, paid channel scope, number routes, signaling, media, network controls and contract rather than a generic PBX template.

Read guide →
Troubleshooting · Current VoIP Much SIP-trunk product, 3CX, FreePBX, UniFi Talk, IP-blocking, SIP ALG, codec, quality, status and service-agreement pages reviewed October 16, 2026. Registration-based account examples, account-issued server and credentials, paid channel scope, supported codec lists, SIP-server port guidance and several network cautions are documented; selected-account DNS, transport and proxy profile, number inventory, caller identity, routing, failover, RTP range, DTMF, fax, emergency service, messaging, encryption, capacity, price, SLA, availability and compatibility remain account, route, contract or observation specific. No account, order, credential, trunk, number, registration, packet, media stream, status incident, emergency call or live call was inspected or tested

VoIP Much trunk registers but calls or audio fail

Separate registration, source-address policy, number and route selection, channel scope, signaling, SDP and both media directions before changing credentials or firewall rules.

Read guide →
Provider research · Current VoIPline Telecom Australian SIP-trunk product, pricing, legal index, Voice and SMS (IP) service schedule, SIP-trunk critical-information summary, network, number-porting and service-status material reviewed October 16, 2026. Registration, SIP URI diversion and Microsoft Teams gateway are documented as distinct operation modes; the service schedule documents public-internet and private-IP delivery, ordered concurrent-call channels, default bidirectional service and selected codec boundaries. The selected order, registrar values, number inventory, caller identity, routing, DTMF, fax, messaging, emergency service, signaling and media protection, failover, price, SLA, availability and compatibility remain order, location, contract or observation specific. No account, order, credential, trunk, number, registration, port, packet, media stream, emergency call or live call was inspected or tested

VoIPline Telecom SIP trunks: modes, channels and call evidence

Qualify one Australian VoIPline SIP trunk by its ordered operation mode, interconnect, channels, numbers, caller identity, negotiated media, contractual boundary and observed calls.

Read guide →
Troubleshooting · Current VoIPline Telecom Australian SIP-trunk product, pricing, legal index, Voice and SMS (IP) service schedule, SIP-trunk critical-information summary, network, number-porting and service-status material reviewed October 16, 2026. Registration, SIP URI diversion and Microsoft Teams gateway are documented as distinct operation modes; the service schedule documents public-internet and private-IP delivery, ordered concurrent-call channels, default bidirectional service and selected codec boundaries. The selected order, registrar values, number inventory, caller identity, routing, DTMF, fax, messaging, emergency service, signaling and media protection, failover, price, SLA, availability and compatibility remain order, location, contract or observation specific. No account, order, credential, trunk, number, registration, port, packet, media stream, emergency call or live call was inspected or tested

VoIPline trunk registers but calls or audio fail

Separate operation mode, interconnect, number and caller-identity routing, channel scope, SIP response, SDP and both media directions before changing credentials or firewall rules.

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 didlogic SIP-account, inbound-destination, regional-gateway, PBX, Asterisk and interconnection documentation reviewed October 18, 2026. Digest registration and source-IP authentication are separate models; purchased-number destination, current registration Contact or SIP URI, provider attempt, customer-edge receipt, Asterisk endpoint identification, dialplan match, answer and media remain separate evidence. The reviewed pages do not publish one universal response-code, timeout, retry, sequence-advancement or restoration contract for every destination type. No didlogic account, credential, number, destination, registration, authorized IP, DNS answer, PBX, packet, media stream or live call was inspected or tested

didlogic outbound calls work but an inbound DID misses the PBX

Trace the purchased number, destination type, registration Contact or SIP URI, provider attempt, Asterisk identification, dialplan match and media without treating outbound success as inbound proof.

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 · Current first-party Bulk Solutions IP-authentication, registration, inbound, outbound, direction-split integration and emergency documentation reviewed October 18, 2026. The current material separates portal host or trunk-group ownership, DID assignment, source-IP authorization, digest credentials, optional registration requirements, provider service-hostname use, request identity, PBX matching and call media. The public FreePBX PDF identifies FreePBX 14.0.4.5 and chan_sip and is retained only as legacy field-orientation context, not a FreePBX 17 PJSIP template. Provider examples are documentation evidence rather than observed account state. No Bulk Solutions account, host, trunk group, DID, credential, registration, DNS answer, address, PBX, firewall, packet, media stream, emergency workflow, price, invoice or live call was inspected or tested

Bulk Solutions outbound works but the inbound DID misses the PBX

Trace DID assignment, inbound trunk group, provider destination, signaling source, Request-URI, PJSIP identification, FreePBX route and media without changing outbound identity.

Read guide →
Troubleshooting · Current first-party Yay.com SIP-trunk creation, authentication, number assignment, inbound destination, encryption, firewall and FreePBX-example documentation reviewed October 18, 2026. The material separates number-to-trunk assignment, inbound identity selection, IP address or FQDN destination, port and transport, outbound IP or username/password authorization, optional registration, TLS signaling, dashboard and endpoint SRTP settings, PBX routing and media. The public FreePBX example uses legacy chan_sip-style fields and is retained only as historical field-orientation context, not a FreePBX 17 PJSIP template. Provider examples are documentation evidence rather than observed account state. No Yay.com account, number, trunk, credential, address, FQDN, DNS answer, registration, certificate, PBX, firewall, packet, media stream, price, availability, compatibility, capacity or live call was inspected or tested

Yay.com trunk connects but inbound routing or audio fails

Trace number assignment, inbound identity, destination, TLS, PBX matching, SDP and SRTP without changing a working outbound authorization path.

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 →
Provider research · Current first-party SIPTRUNK device, registration, inbound-call, IP-authentication, failover, registration-status, interconnection and direct-media documentation was reviewed October 19, 2026. Credential registration and static-IP authentication remain different service paths; portal registration, Contact address, observed public source, inbound route, signaling gateways, direct-media RTP sources and failover treatments remain separate evidence. No SIPTRUNK account, trunk, credential, registration, number, route, gateway, DNS answer, PBX, firewall, packet, media stream, failover event, price, availability, compatibility or live call was inspected or tested

SIPTRUNK registration, inbound Contact routing and direct-media evidence

Keep credential registration or IP authentication, Contact delivery, inbound number matching, gateway redundancy, direct-media RTP and failover treatment independently observable.

Read guide →
Troubleshooting · Current first-party SIPTRUNK device, registration, inbound-call, IP-authentication, failover, registration-status, interconnection and direct-media documentation was reviewed October 19, 2026. Credential registration and static-IP authentication remain different service paths; portal registration, Contact address, observed public source, inbound route, signaling gateways, direct-media RTP sources and failover treatments remain separate evidence. No SIPTRUNK account, trunk, credential, registration, number, route, gateway, DNS answer, PBX, firewall, packet, media stream, failover event, price, availability, compatibility or live call was inspected or tested

SIPTRUNK is registered but inbound calls or audio fail

Trace the selected authentication mode, registered Contact, provider attempt, PBX route and direct-media RTP without treating portal registration as end-to-end proof.

Read guide →