Identify the Bandwidth product path before configuring SIP
Bandwidth documents Build SIP Trunking, a SIP Registrar for registered devices and a Programmable Voice Inbound SIP URI as different entry points. Start with the account entitlement, number voice configuration, route or application object, realm, credential, assigned source addresses and current handover. Do not copy a registrar requirement into a Build trunk or treat a Programmable Voice application URI as a telephone-number route.
Preserve the exact portal or API object identifiers and effective times. A created realm, enabled inbound SIP URI or accepted management request proves only that object state; it does not prove number assignment, registration, provider routing, PBX acceptance or media.
Documented service facts
Reviewed 2026-10-23. Compare SIP trunk services →
Outbound authentication
DocumentedBuild outbound SIP uses credentials bound to an exact generated realm hostname. Voice IP whitelists are separate source controls and do not replace the documented digest path.
SIP registration
DocumentedBandwidth documents an optional Registrar for activated accounts and registered devices. Build realms and credentials do not establish that every trunk must REGISTER.
Inbound delivery
DocumentedBuild numbers use prioritized routes containing weighted endpoints. Number voice mode, route priority, endpoint weight, provider attempt and PBX match remain separate.
Inbound failover
DocumentedSecondary and tertiary Build routes can act as failover, while Final Destination URI and call forwarding are separate controls. The public material does not publish one complete trigger, timer or restoration table.
Number and regional availability
DocumentedBandwidth markets global SIP trunking. Number inventory, portability, regulatory eligibility, account location and current service availability still require a dated result.
Audio codecs
Not verifiedThe reviewed pages do not establish one universal codec, packetization, DTMF or media-source profile for every Bandwidth product path. Preserve SDP and both RTP directions.
T.38 fax
Not verifiedThe reviewed AAW sources do not establish a universal T.38 or fax-pass-through profile. Qualify fax on the exact account, route and PBX.
Signaling and media encryption
Not verifiedSource whitelists, digest authentication, SIP transport and media encryption are different controls. Obtain the exact current signaling and media security profile.
Call-start capacity
Not verifiedPublic product language is not purchased concurrency, call-start rate or over-limit behavior. Confirm account entitlements and observe exact rejection evidence.
Emergency calling
Not verifiedVoice and E911 whitelists are separate structures, and number moves can require E911 removal or reapplication. Confirm location, identity and approved validation per number.
Pricing model
Not verifiedObtain dated account terms for numbers, routes, calls, features, support, emergency services, taxes and fees. No price was tested or normalized.
Administration and support
DocumentedManagement objects include numbers, routes, endpoints, realms, credentials, Registrar state, features and whitelists. Record object IDs, owners, timestamps and redacted support evidence.
SMS and MMS
Not verifiedSIP Trunking voice configuration does not establish messaging registration, sender eligibility, throughput, retention or price. Qualify messaging independently.
Keep inbound route priority separate from endpoint weight
The Build guide defines routes as prioritized groups: the primary route is tried first, while a secondary or tertiary route can act as failover. Endpoints inside one route use weights for traffic distribution. Preserve the number voice mode, ordered route identifiers, endpoint targets and weights, then retain the actual first request, response or timeout and any later attempt.
Priority and weight answer different questions. A weighted endpoint is not a standby sequence, and the existence of a secondary route does not publish a complete trigger, timer, retry or restoration contract. Final Destination URI and call forwarding are separate number or location controls rather than extra route groups.
Bind each outbound credential to its exact realm
Build outbound setup creates a realm, then SIP credentials linked to a Bandwidth number. The current integration guide likewise says outbound calls use SIP digest credentials against the exact generated realm hostname and identifies repeated 407 or 403 results as potential realm, username or password mismatches. Record the realm FQDN, credential identifier, bare username, number account, challenge realm and responder without exposing the secret.
A realm hostname identifies the authentication domain; a credential authenticates a request. Neither proves the selected outbound number, caller identity, destination authorization, PBX route or final call result. Confirm the request that received the challenge and the retried Authorization transaction.
Treat SIP Registrar registration as an optional account path
Bandwidth’s Registrar guide requires activation, then a realm, credential and registered device. That is distinct from the Build trunk page, which documents realms and credentials for outbound SIP without stating that every Build trunk must maintain a REGISTER binding. Verify whether the account actually uses Registrar before creating an outbound-registration object or diagnosing an absent binding.
For an enabled Registrar path, retain DNS SRV resolution, selected target and port, REGISTER Request-URI, From, To, Contact, challenge, expiry, response and refresh. Registration success proves a current binding only; it does not prove a telephone number is assigned, an outbound INVITE is authorized or an inbound route is effective.
Version number features, whitelists and E911 state independently
Bandwidth publishes Final Destination URI, call forwarding, inbound number-format and Remote Party ID options separately from Build routes. It warns that a location-level failover PUT is idempotent and can overwrite omitted settings. Preserve the complete before-and-after payload, order or processing state, effective value, owner and rollback.
Voice and E911 IP whitelists also use separate structures. A permitted address does not prove SIP authentication, number routing or emergency eligibility. Moving a number can affect Voice and E911 services, so record preflight warnings, account and location ownership, service removal or reapplication and approved validation separately.
Trace one call through signaling, identity and media evidence
For one authorized call, correlate number assignment, route or realm, credential or source control, Request-URI, From, asserted identity, response, PBX object, normalized digits, answer, SDP and both media directions. Do not infer that a 200 response proves a person answered or that an accepted request proves two-way audio.
The reviewed pages do not establish one universal current codec, DTMF, TLS, SRTP, fax, capacity, emergency or commercial profile for every Bandwidth service. Obtain the current account terms and technical handover, preserve exact evidence and qualify unsupported capabilities independently.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Bandwidth Build SIP trunking setup ↗
- Bandwidth SIP Registrar setup ↗
- Bandwidth Vapi SIP integration ↗
- Bandwidth number features and Final Destination URI ↗
- Bandwidth telephone-number options and features ↗
- Bandwidth voice and E911 IP whitelist ↗
- Bandwidth moving phone numbers ↗
- Bandwidth global SIP trunking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.