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

Bandwidth outbound SIP realm or registration fails

Find the first mismatch across product entitlement, realm FQDN, credential, optional Registrar binding, caller identity, PBX route, response and media.

Reviewed 2026-10-23Current first-party Bandwidth Build SIP Trunking, SIP Registrar, integration, number-feature, IP-whitelist, number-move and product material was reviewed October 23, 2026. Build routes, outbound realms and credentials, optional Registrar registrations, Programmable Voice Inbound SIP URI, number options and IP whitelists belong to different objects and are not represented as one universal trunk profile. No Bandwidth account, product entitlement, realm, credential, registration, number, route, endpoint, weight, Final Destination URI, whitelist, E911 record, DNS answer, PBX, firewall, packet, call, media stream, failover event, price, capacity, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed transaction and the selected product path

Record local and UTC time, account, number, Build trunk or Registrar entitlement, realm FQDN, credential identifier, PBX object, DNS answer, source address, destination, caller identity, SIP Call-ID and first response or timeout. Redact passwords, digest material, bearer tokens and personal numbers.

Classify the earliest divergence: wrong product, realm missing, credential not attached, DNS target wrong, REGISTER not loaded, challenge unanswered, number belongs to another account, PBX selected another trunk, provider rejected identity or signaling succeeded while media failed.

Verify realm, credential and account ownership before rotating secrets

Compare the configured gateway with the exact generated realm hostname. Confirm that the credential exists under that realm and that the originating number belongs to the intended Bandwidth account. Preserve the initial request, 401 or 407 challenge, challenge realm, bare username, retried request and final responder.

Repeated 407, 403 and 500 results have different possible causes in current Bandwidth integration guidance. Do not rotate a secret until realm, username form, account enablement and request ownership are established, and never expose reusable Authorization material in tickets.

Determine whether REGISTER is actually required

Confirm whether the account uses the optional Bandwidth Registrar. Build outbound realm credentials do not by themselves establish a REGISTER requirement. If Registrar is enabled, verify the loaded registration object, DNS SRV answer, target and port, Contact, expiry, response and refresh timing.

If Registrar is not the ordered path, remove the assumed binding from the fault model and follow the outbound INVITE authentication exchange instead. An absent registration can be expected in one product path and a defect in another.

Trace number, caller identity and route selection separately

Confirm the Bandwidth number’s account, voice configuration and association with the intended realm or trunk. Then retain user-entered digits, PBX normalization, outbound-route match, selected trunk, Request-URI, From and asserted identity. A valid credential does not authorize every number or caller identity.

If the PBX selects another trunk or modifies the number unexpectedly, correct that local boundary before changing the realm. If Bandwidth rejects the correct transaction, escalate with redacted signaling, exact time, Call-ID and object identifiers.

Keep IP whitelists, inbound routes and emergency state outside outbound digest

Voice or E911 whitelist state does not replace the outbound realm credential documented for this path. Build inbound route priority, endpoint weights, Final Destination URI and call forwarding also do not diagnose an outbound digest rejection. Preserve those objects only when the failed scenario actually traverses them.

Do not broaden voice or E911 address permissions to repair a credential mismatch. Moving a number or location can change Voice and E911 state; reconcile those changes through their documented workflows and approved validation.

Correct one owner and retest call and media stages

Change only the demonstrated realm hostname, credential association, Registrar object, DNS target, number ownership, PBX route, caller identity or media boundary. Record prior and new values, approval, effective time and rollback, then repeat the exact authorized call.

Preserve challenge, final response, PBX state, answer, SDP and packets in both directions. One successful call does not establish account capacity, availability, pricing, emergency behavior or general compatibility. No Bandwidth account, registration, packet, media stream or call was inspected or tested for this diagnostic.

Sources & applicability

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

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

Continue your research

Provider research · Current first-party Bandwidth Build SIP Trunking, SIP Registrar, integration, number-feature, IP-whitelist, number-move and product material was reviewed October 23, 2026. Build routes, outbound realms and credentials, optional Registrar registrations, Programmable Voice Inbound SIP URI, number options and IP whitelists belong to different objects and are not represented as one universal trunk profile. No Bandwidth account, product entitlement, realm, credential, registration, number, route, endpoint, weight, Final Destination URI, whitelist, E911 record, DNS answer, PBX, firewall, packet, call, media stream, failover event, price, capacity, availability, compatibility or support response was inspected or tested

Bandwidth SIP trunking: routes, realms, registration and number evidence

Separate Build inbound routes, endpoint weights, outbound realm credentials, optional Registrar registration, number features, IP whitelists and observed call results.

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

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

Read guide →
Guide · Asterisk 22 LTS

Asterisk outbound registration: what it proves

Distinguish a carrier registration from endpoint configuration and successful incoming or outgoing calls.

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 →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Troubleshooting · Current Sangoma outbound-route guidance, current Asterisk Dial and troubleshooting documentation, and SIP standards reviewed October 5, 2026; no phone, PBX, carrier or live call test

Outbound VoIP calls fail: locate the broken call leg

Classify one failed call, then follow the exact digits through the phone, PBX route, attempted trunk, remote response, answer and media.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

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

Read guide →
Hub

VoIP troubleshooting

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

Explore topic →