Bandwidth SIP trunking: routes, endpoints and number evidence

Inventory the number, voice mode, routes, endpoints and realm separately

Record the account path, telephone number, its enabled voice mode, every inbound route and priority, every endpoint and weight, any Final Destination URI or call-forward option, the outbound realm, SIP credential identifier, PBX object and operating owner. Protect passwords, bearer tokens, customer identifiers and personal numbers.

Bandwidth Build documents SIP Trunking and Voice API traffic as alternative voice configurations for a number. It then treats inbound routes and endpoints separately from the outbound realm and credentials. A valid realm does not prove that a number has SIP Trunking enabled, and an inbound route does not prove that outbound credentials or Voice API behavior apply.

Interpret route priority and endpoint weight at different levels

The current Build guide describes routes as prioritized groups. The primary route is tried first, with secondary or tertiary routes acting as failover after a failure. Inside a route, endpoint weights determine the traffic split. A domain, IP address, SIP URI or forwarded telephone number can be an endpoint in the Build workflow.

Preserve route priority, endpoint weight, configured target, actual first attempt, response or timeout, elapsed time and any later attempt. A 33-percent endpoint weight is distribution evidence inside its route; it is not a standby order, a promise that three consecutive calls choose different targets or proof of geographic, carrier or access-network independence.

Keep final-destination options outside the route model

Bandwidth’s number-feature documentation exposes FinalDestinationURI as an optional telephone-number setting and separately exposes call forwarding. Those settings are not the same as the primary, secondary and tertiary route groups described by Build. Record which account surface owns the number, which control is populated and which destination the failed call actually reached.

The number-option workflow is asynchronous: the create response can show RECEIVED, while later status can show COMPLETE with warnings or errors. Request acceptance is not proof that a number option became effective, and an effective final destination does not prove the earlier SIP routes were attempted under an assumed response policy.

Do not invent failover triggers or registration behavior

The reviewed Build page says a later route can act as failover when a call fails at the first endpoint, but it does not publish a complete response-code list, timeout schedule, retry count or restoration rule. Record the observed first request, response or transport failure and any next attempt instead of importing another provider’s policy.

For outbound traffic, Build documents a realm hostname and username/password credentials that authenticate calls. The reviewed page does not show a REGISTER exchange or establish one universal registration rule across Bandwidth products. Preserve the actual initial request, challenge, source policy and configured product rather than treating registration as an assumed prerequisite for inbound routing.

Trace delivered signaling through PBX matching and media

When an INVITE reaches the edge, retain its source, Request-URI, called-number form, transport, first PBX object or context, normalized DID, first matching inbound rule, destination and final SIP response. A Bandwidth attempt does not prove that FreePBX, Asterisk, an SBC or another PBX selected the intended extension, queue, menu or voicemail.

After signaling succeeds, compare SDP offers and answers, the chosen codec, RTP endpoints, NAT or firewall decisions, packet flow in both directions and an authorized listening result. The current public Build setup does not establish an account-specific codec, TLS or SRTP contract, and a successful signaling route does not prove decoded two-way audio.

Confirm capacity, emergency, number and commercial state separately

The product page describes broad capacity and coverage benefits, while the reviewed public material does not define the selected account’s concurrent-call or call-start limit, over-limit response or change lead time. Confirm number inventory, port eligibility, regulatory requirements, emergency service, approved emergency test procedure, messaging registration, support commitment, rates, taxes and fees for the exact account and date.

A saved route, completed option order or one successful call is not a guarantee of future availability, capacity, failover, emergency behavior or compatibility. No Bandwidth service, PBX or live call was tested for this guide.

Trace a Bandwidth inbound call from number configuration outward

Use the Bandwidth inbound-route diagnostic to prove number voice mode, route priority, endpoint weight, first attempt, option-order state, PBX match and restoration.