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-30Foundational

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.

Map an AireSpring order before choosing a trunk template

The AireSpring guide starts with the exact product, peers, trust method, DIDs, route controls and account capacity.

Map the OnSIP trunking-user contract before building objects

The OnSIP guide starts with account user state, current PBX driver, assigned identity, registration, 000 transformation and inbound number state.

Choose the DIDforSale interconnection model before building trunks

The DIDforSale guide starts with the current portal IP or FQDN record or the activated SIP account, not a generic template.

Choose the Zadarma connection model before building trunks

The Zadarma guide starts with credential registration or confirmed static-IP authorization, not a blended template.

Model Voxbeam outbound and inbound controls independently

The Voxbeam guide separates source-authorized termination from trunk defaults and DID-level inbound overrides.

Model GoTrunk inbound and outbound identity independently

The GoTrunk guide preserves direction-specific static-address or credential controls and the selected inbound destination.

Model DIDWW call directions as separate trunks

The DIDWW guide follows one inbound destination or one outbound authentication decision before interpreting call evidence.

Model Exotel inbound and outbound paths independently

The Exotel guide maps outbound authorization and inbound Flow delivery without treating one direction as proof of the other.

Model Voximplant registrations and call legs independently

The Voximplant guide preserves registration, application binding, rule selection and each created call leg as separate evidence.

Bind Allstream behavior to the ordered service option

The Allstream guide keeps Native SIP, PRI-SIP, SIP Extreme or Gateway portal controls, Internet or private access, country and PBX handoff distinct.

Bind Cloudli behavior to current portal parameters

The Cloudli guide keeps portal-issued identity, authentication, proxy, port, plan capacity, continuity and the loaded PBX distinct.

Bind Orange Business Talk settings to one ordered site

The Orange Business Talk guide follows the selected site, current project documents, eSBC demarcation and effective call evidence.

Bind Vodafone Evolved Voice behavior to the current order

The Vodafone Evolved Voice guide follows the ordered service, public access, endpoint design, number state and observed call evidence.

Bind Swisscom behavior to the ordered SIP variant

The Swisscom Enterprise SIP guide follows the ordered access, service access point, eSBC or SBC, PBX, number and option evidence.

Bind Sunrise behavior to the ordered package

The Sunrise Business Voice SIP guide follows the ordered Basic or Premium package, access, peer, PBX, number and continuity evidence.

Bind Proximus behavior to the ordered flavour

The Proximus Business Trunking guide follows access, CPE, SBC, PBX, number, channel and acceptance evidence.

Bind Crazytel behavior to the selected product

The Crazytel SIP Trunking guide separates portal configuration, authentication, delivery, signaling, media and commercial evidence.

Keep MaxoTel portal, registration and call proof distinct

The MaxoTel SIP Trunking guide follows ordered service, portal-issued identity, UDP exchange, routing and media evidence.

Keep the Aussie Broadband order and PBX handoff distinct

The Aussie Broadband SIP Trunks guide follows supplier, NBN access, equipment, channel, signaling and media evidence.

Keep the Symbio order and handoff distinct

The Symbio Enterprise SIP Trunking guide follows product, access, handoff, number, channel, signaling and media evidence.

Keep the Telstra order and eligible access together

The Telstra SIP Connect guide follows feature pack, access, accredited CPE, numbers, channels, signaling and media.

Keep the Optus application and handoff together

The Optus Evolve Voice guide follows the governing agreement, Evolve IP VPN, router model, service-delivery point, PBX and features.

Identify the exact One NZ SIP service

The One NZ SIP guide follows the selected service, legal description, site, access, demarcation, PBX and options.

Identify the exact 2degrees SIP trunk order

The 2degrees SIP Trunks guide follows the governing agreement, site, access, handoff, PBX and implementation pack.

Identify the exact Vocus voice product

The Vocus SIP Voice guide starts with the named offer, current schedule, order, site and implementation pack.

Start from the Superloop service order

The Superloop SIP guide binds access, PBX, identity, DID and features to the ordered product.

Identify the exact Enreach offer

The Enreach SIP Trunks guide starts with product, country, account, profile, number range and support owner.

Keep MetTel product, order and call proof distinct

The MetTel SIP Trunking guide follows the exact order, site, access, number, policy, signaling and media boundaries.

Keep NUSO order, handoff and call proof distinct

The NUSO SIP Trunking guide follows the exact product, region, order, access, portal, number, signaling and media boundaries.

Keep Telesystem handoff and portal evidence distinct

The Telesystem SIP Trunks guide follows the accepted order through tenant, site, access, trunk, number and call evidence.

Keep TPx UCx SmartVoice product and path evidence distinct

The TPx UCx SmartVoice guide follows one order through handoff, access, DID, forwarding, continuity and completed call.

Keep Lingo Cloud SIP product and path evidence distinct

The Lingo Cloud SIP guide follows one order through platform, access, DIDs, call paths, failover and completed call.

Keep Voyant order and runtime evidence distinct

The Voyant guide follows one service order through access, trunk type, numbers, identity, emergency records and calls.

Keep Windstream order and runtime evidence distinct

The Windstream Dynamic IP guide follows one ordered trunk through access, capacity, DTO, signaling, media and restoration.

Keep Granite order and runtime evidence distinct

The Granite SIP Trunking guide follows one ordered service through handoff, capacity, DTFO, signaling, media and restoration.

Keep FirstLight order and runtime evidence distinct

The FirstLight SIP Trunking guide follows one ordered service through access, signaling, media and restoration.

Sources & applicability

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