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

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Reviewed 2026-10-19First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call testIntermediateDocumentation based · not lab tested

Find the last successful boundary

Call the published number from an independent outside service. Record the source, destination, exact time, caller experience and carrier call identifier. At the PBX edge, capture whether an INVITE arrived and retain its Call-ID, source address, Request-URI and To header. Protect the trace because signaling can contain identities, dialed numbers and credentials.

If no request reaches the managed edge, move upstream through number assignment, provider route, provider trace and firewall or SBC admission. Do not change the PBX dialplan to compensate for an INVITE that was never delivered.

Inbound and outbound routing are separate
Inbound calls use called-number matching to reach an extension, queue or IVR. Outbound calls use dialed-number rules to choose a permitted trunk.

A working outbound call does not prove inbound number routing. Diagnose the direction and the matching rule independently.

Prove which endpoint Asterisk selected

Every inbound SIP request must be associated with an Asterisk endpoint before it can enter that endpoint's context. Use the live logger and pjsip show endpoint evidence to confirm the selected endpoint, loaded Identify object and expected source match. Asterisk can identify by the From user or by an IP Identify object depending on loaded modules and configuration.

Do not interpret every 401 response as a bad password: Asterisk documents a dummy challenge when it cannot identify an endpoint. Prove endpoint recognition first, then examine any real authentication exchange. Avoid enabling an anonymous endpoint as a shortcut unless anonymous admission is an intentional, restricted design.

Follow the delivered number into the running dialplan

Record the number format actually delivered in the Request-URI and compare it with the endpoint context and inbound-route match. Country code, leading plus, national prefix and provider-added digits can select a different extension. Caller-ID screening is a separate decision from the called number.

Asterisk's rejection notice names the selected endpoint, requested extension and context when no extension exists. Use dialplan show <context> to inspect the running dialplan. In FreePBX, verify the intended route and destination were saved and applied; generated dialplan is runtime evidence, not the durable edit surface.

Follow the destination

After a route matches, follow time conditions, manual overrides, ring-group membership, queue admission, extension dialing and voicemail fallback. A correct DID match can still lead to an unavailable extension or an after-hours destination the caller did not expect. Keep a dial attempt, provisional response, answered bridge and usable media as separate outcomes.

Retest narrowly

Test the repaired number from an outside service, then test another existing number to detect an overly broad match. Confirm the expected daytime or after-hours destination without leaving a catch-all route in place merely because it masks an unexplained mismatch. Keep the carrier and SIP identifiers with the incident if upstream escalation is required.

When more than the intended PBX rings

Use the A&A target-graph diagnostic when one inbound call alerts an old device and the PBX. It resolves provider-side branches before changing the PBX route.

Separate Zen inbound signaling from the later audio path

If a Zen call reaches and answers on the PBX but audio is missing, continue with the Zen media diagnostic rather than changing inbound routing that already completed.

When a SureVoIP alternate destination never receives an attempt

The SureVoIP destination diagnostic follows one number from the configured route order through the first outcome, timeout trigger, next attempt and recovery.

Keep caller-name lookup after carrier delivery and route matching

If an inbound call reaches FreePBX but displays the wrong name, follow the CallerID Lookup diagnostic from the matched route through the source, cache and destination channel.

When Magrathea does not send a call to one nominated IP

Follow the Magrathea SIP Resilience workflow from the selected number and address pool through health probes, distribution, INVITE arrival and PBX route.

When an NFON backup PBX receives no inbound calls

Follow one number through NFON trunk-set membership, endpoint selection and PBX routing before changing registration or firewall state.

Trace SIPTRUNK delivery from the selected authentication mode

For registered service, SIPTRUNK uses the REGISTER Contact for inbound delivery; for IP authentication it uses the stored public address and port. The mode-mismatch diagnostic follows that destination through DID assignment, INVITE, number format and the first PBX route.

Trace Blink Reject or Busy before changing inbound routing

When one Blink user action stops parallel phones or voicemail, use the Blink inbound-disposition diagnostic to preserve the 603, 486 or absent response, identify which proxy cancelled branches and compare the final caller treatment.

Trace SIP.US inbound delivery beyond the working primary gateway

The SIP.US failover diagnostic follows current gateway acceptance, registered Contact or stored IP, DID primary and secondary trunk assignment, eleven-digit called number and first PBX rule before any fallback change.

Prove a Flowroute failover assignment before changing the PBX

The Flowroute inbound-failover diagnostic follows the number's primary and failover relationship IDs, destination types, first provider attempt, Request-URI and first PBX rule.

Prove DIDWW group policy before changing an inbound route

The DIDWW trunk-group diagnostic follows one DID through assignment, group membership, policy, first result, every later CDR and PBX handling.

Trace SIPStation delivery before changing a general inbound route

Use the SIPStation inbound diagnostic to prove account mode, registration address, provider fallback, first PBX request and DID match.

Trace an IP Telecom port and inbound target independently

For an IP Telecom number, use the provider record to preserve the accepted port state, delivered Request-URI and identity, first PBX match and final destination without assuming a general portability statement proves live routing.

Trace Clearfly inbound delivery through every routing layer

Use the Clearfly service record to preserve the public number, port state, delivered Request-URI and identity, PBX match, forwarding or attendant control and final destination without assuming a portal label proves delivery.

Trace Redcentric inbound delivery after number migration

Use the Redcentric service record to preserve port state, provider route, delivered Request-URI and identity, PBX match, call-flow object, destination, answer and media without treating project completion as delivery proof.

Verify that CommPeak DID service is actually in scope

CommPeak lists DIDs separately from SIP termination. Use the provider record to prove number ownership, provider route, delivered Request-URI and identity, PBX match, destination, answer and media before changing the trunk.

Trace Voximplant ingress beyond the IP allowlist

Use the Voximplant provider record to compare source address, Request-URI, identity, application-rule match, scenario event, next leg, destination answer and media before changing the trunk.

Trace TelVox SIP delivery and webhook execution separately

For TelVox Connect, use the provider record to correlate trunk state, SIP dialog, voice-webhook request, five-second application response, returned markup, later callback and media outcome without treating any one layer as end-to-end proof.

Do not let VoIP Much registration stand in for number routing

For VoIP Much, prove the owned number, provider route, delivered identity, selected PBX rule and destination separately with the provider-specific diagnostic.

Prove the VoIPline number route after registration

The VoIPline diagnostic separates an active or ported number, provider route, delivered identity, PBX rule and final destination.

Trace one Voip Unlimited DDI from alias to destination

The Voip Unlimited diagnostic proves provider assignment and delivery before changing a general inbound route.

Prove the SignalWire resource assignment before widening a route

The SignalWire diagnostic distinguishes a phone number assigned to a SIP endpoint from a Resource SIP Address and then traces the PBX context and DID.

Prove Telnyx number assignment, region and first attempt

The Telnyx inbound-route diagnostic compares the number-to-Connection relationship, selected inbound region, current network evidence, delivered request and first PBX match.

Prove the Bandwidth number, routes and first attempt

The Bandwidth inbound-route diagnostic compares number voice mode, effective routes, weighted endpoints, actual attempts and the first PBX match.

Prove the Voipfone portal route before changing the PBX

The Voipfone inbound-number diagnostic starts with the number’s effective destination, then follows provider attempt, delivered identity and PBX match.

Prove the VoIP.ms DID route and POP before changing the PBX

The VoIP.ms DID diagnostic starts with the number’s effective route and POP, then follows provider attempt and PBX match.

Prove Twilio URL selection before changing the inbound route

The Twilio origination diagnostic begins with the number, Trunk SID and effective OriginationUrl resources before the PBX match.

Prove the Plivo number-to-URI chain before changing routing

The Plivo inbound diagnostic starts with number assignment and the effective primary and fallback URI before the PBX match.

Prove the Vonage number-to-URI chain first

The Vonage inbound diagnostic starts with the number link and effective priority and timeout before the PBX match.

Start a Voxtelesys inbound incident at the DID route profile

The Voxtelesys diagnostic proves number assignment and effective destinations before changing registration, firewall or PBX routing.

Start Amazon Chime inbound incidents at number assignment

The Amazon Chime diagnostic proves the assigned connector or group before changing origination routes, firewall or PBX routing.

Begin a didlogic inbound incident at the purchased number

The didlogic diagnostic proves the destination type and target before changing registration, firewall or PBX routing.

Check Callcentric DID Forward before the PBX path

Callcentric direct DID Forward rules outrank Call Treatments. The diagnostic establishes whether an INVITE should have reached the customer edge at all.

Trace an Anveo Direct DID to its exact SIP URI

A working outbound trunk and an absent REGISTER status do not explain inbound routing. Use the Anveo Direct diagnostic to follow the DID, primary URI, provider attempt and PBX match.

Follow a CarrierX DID through its assigned group

Use the CarrierX trunk-group diagnostic to distinguish number assignment, provider selection, edge receipt, PBX matching and media.

Follow an AVOXI number through its enabled rule

Use the AVOXI SIP URI diagnostic to distinguish number mapping, URI configuration, provider attempt, PBX matching and media.

Do not let an Easybell registration hide the inbound mode

Use the Easybell diagnostic to distinguish credential registration, IP-only delivery, FQDN targeting, PBX matching and Offline forwarding.

Check SIP.US Forward and Backup before rewriting routes

A DID can intentionally bypass the PBX through PSTN Forward, while Backup has a narrower trigger. Use the SIP.US diagnostic to preserve precedence and capacity evidence.

A correct Flowroute route can still have a separate media failure

First prove number relationship and provider edge, then use the Flowroute audio diagnostic if signaling completes without sound.

A Bulk Solutions outbound success does not establish inbound DID assignment

Use the Bulk Solutions diagnostic to trace trunk-group ownership, edge receipt, Request-URI and route matching.

A Yay.com trunk can exist while its number routes elsewhere

Use the Yay.com diagnostic to prove number assignment, delivered identity, destination and first PBX route.

A ClearlyIP DID can select another Location or identity

Use the ClearlyIP diagnostic to prove Primary or Smart Routing ownership and the delivered number form.

A working Simwood outbound call does not prove inbound registration

Use the Simwood diagnostic to prove the provider binding and attempt before PBX route changes.

A working Sinch termination leg does not prove origination

Use the Sinch diagnostic to prove the number's origination application and actual customer-facing attempt.

A registered SIPTRUNK Contact can still point to the wrong destination

The SIPTRUNK diagnostic compares Contact, provider source, attempt and first PBX response.

Watch the explanation

Grandstream GRP phones: prevent accidental DND activationVoIP knowledge · Version-specific

Learn the difference between turning Do Not Disturb off and removing the user controls that enable it. The demonstration examines the idle mute-key action and the separate DND feature setting, which can matter when users accidentally stop their phones ringing.

Read applicability and editorial notes →
Watch this video here

GRP-family web interface; the spoken model number is unclear. Match the controls to your exact model and firmware before applying a policy change. Review used the available transcript and primary references; audio and screen readability remain unverified.

Open on YouTube ↗

The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.

Sources & applicability

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

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

Continue your research

Hub

VoIP troubleshooting

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

Explore topic →
Guide · Asterisk 22 LTS res_pjsip and endpoint-identifier references, the Asterisk endpoint-identification article and GHSA-qqxj-v78h-hrf9 were reviewed October 8, 2026; no PBX, package, module, configuration, endpoint, identify object, address, DNS answer, request, security event, registration, authentication, route, media path or live call was inspected or tested

Asterisk PJSIP endpoint identification: order, scope and evidence

Control how Asterisk 22 maps an incoming SIP request to an endpoint before authentication and dialplan routing.

Read guide →
Guide · Asterisk 22 LTS

Asterisk PJSIP: understand the configuration objects

Connect endpoint behavior, authentication, contacts and transport without collapsing them into one account setting.

Read guide →
Guide · Asterisk 22 LTS documentation reviewed September 30, 2026; external_signaling_hostname is documented only from Asterisk 22.11.0 in this branch; no PBX, endpoint, transport, NAT device, packet path or call test

Asterisk PJSIP NAT: map the advertised addresses

Choose NAT settings from the PBX and phone topology, then verify the actual signaling and media destinations.

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 · Zen Business SIP Trunking, General SIP Settings and Business Talk SIP specific terms reviewed October 12, 2026; the terms document carries an issue date of March 3, 2011 and must be confirmed against the selected current order, exact account, PBX, registration, dialog, SDP, firewall, NAT, provider address, RTP stream, codec, DTMF, fax and audio result remain deployment-specific, and no account, credential, device, PBX, packet, call, media stream or emergency call was inspected or tested

Zen SIP trunk registers but call audio is missing

Follow one Zen Business Talk SIP call from registration and dialog establishment through SDP, the documented B2BUA media ranges, both RTP directions, codec selection and decoded audio.

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 · FreePBX CallerID Lookup release/17.0 metadata, generated-dialplan and configuration source plus current Asterisk caller-ID, party-ID and internal-database documentation reviewed October 12, 2026; the exact module version, inbound route, source assignment, normalized number, external result, AstDB key, channel identity, destination device and display behavior remain deployment-specific, and no PBX, source, credential, database, cache, call or endpoint was inspected or tested

FreePBX caller name is missing, wrong or stale

Trace one inbound caller number through route selection, the assigned lookup source, live or cached result, channel caller name and the final endpoint display.

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 · 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 Blink Windows/Linux manual pages for SIP accounts, the main interface, incoming-call alerts and audio calls, the platform-specific changelog, and RFC 3261 response and proxy-processing rules reviewed October 14, 2026; the documentation describes Blink sending 603 for Reject, 486 for Busy, and no SIP response when Escape only silences the local alert, but it does not prove the selected package, account, registrar, proxy, forked branches, PBX response handling, voicemail policy, forwarding policy or observed call result, and no package, workstation, account, credential, SIP trace, PBX, provider, branch, forwarding rule, voicemail destination, alert action or live call was inspected or tested

Blink Reject stops other phones or voicemail

Distinguish Blink Reject, Busy and local alert dismissal, then correlate the exact SIP response with proxy branches, forwarding and voicemail before changing server policy.

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 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 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 →