VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

VoIP Innovations wholesale SIP trunking: endpoint groups and failover

Separate source-IP authorization, Endpoint Group hunting, DID failover, media, E911 and messaging before accepting wholesale service behavior.

Reviewed 2026-09-28First-party VoIP Innovations and Sangoma Wholesale Carrier Services service, FreePBX/Asterisk, Endpoint Group, DID failover, DID, E911, API and messaging documentation reviewed September 28, 2026; no account, endpoint group, trunk, DID, call, codec, DTMF, fax, protected transport, failover, capacity, emergency call, message, rate, availability or support response was testedAdvancedDocumentation based · not lab tested

Use the source-IP service boundary

The current Sangoma Wholesale Carrier Services FreePBX procedure sets Authentication and Registration to None. The provider identifies the trunk through the customer's approved source address and Endpoint Group rather than a REGISTER binding or an outbound-auth object. Preserve the account-assigned signaling destinations, accepted customer addresses, PBX transport and firewall owner. Example addresses in a setup article are not permanent account data.

Treat configuration, provider acceptance and completed calls as separate states. Do not add a registration or copy a documentation example address merely because a generic PBX template expects credentials. If the account owner supplies a different interop profile, preserve it as the authority for that account and date.

Documented service facts

Reviewed 2026-09-28. Compare SIP trunk services →

Authentication

Documented

Current Sangoma wholesale and FreePBX procedures document source-IP identification with no trunk authentication object: the customer endpoint group and approved addresses define the service boundary. Preserve the assigned account addresses and provider signaling set; do not copy example IP addresses as permanent account data.

SIP registration

Documented

The current FreePBX setup sets both Authentication and Registration to None for the documented source-IP trunk. A configured endpoint group, accepted source address and successful call remain separate evidence states; do not troubleshoot this path by adding REGISTER unless the account owner supplies a different interop procedure.

Inbound delivery

Documented

DIDs route to an Endpoint Group containing customer IP destinations. Sangoma documents E.164 delivery by default in the FreePBX workflow. Preserve the exact DID assignment, endpoint group, destination address and port, provider source set, delivered called-party format and PBX context; a working outbound call does not prove inbound routing.

Inbound failover

Documented

Endpoint Groups support top-down or round-robin selection and advance on non-response or documented SIP rejections. Per-DID off-net failover is a later, separately billed path after customer addresses are exhausted; Sangoma warns that groups with more than four addresses may consume the call timeout before DID failover. This is new-call routing, not established-dialog survival.

Number and regional availability

Not verified

The current wholesale origination page advertises local and toll-free inventory and associated 911, messaging and caller-name capabilities. Exact number stock, portability, activation, identity documents, outbound-name eligibility and feature combinations remain specific to number, account and date.

Audio codecs and DTMF

Documented

Sangoma's Asterisk example lists G.711 mu-law, optional G.729 and RFC 2833 DTMF. These are configuration and capability statements, not proof of route availability, licensing, transcoding, negotiated payload or digit delivery. Capture SDP, RTP endpoints and DTMF on each representative route.

T.38 fax

Not verified

The wholesale portal documentation treats T.38 as a DID feature that can be exposed to client accounts, while the generic Asterisk example leaves T.38 disabled. Neither page establishes that a selected DID, direction, carrier route, gateway or document set will negotiate and complete T.38. Qualify fax separately and retain audio fallback policy.

Signaling and media encryption

Not verified

The reviewed public wholesale procedures use source-IP identification and UDP examples; they do not establish a customer-facing TLS identity, certificate-validation procedure, SRTP profile or downgrade policy for this service. IP authorization and firewall allowlisting are not encryption. Obtain protected-transport requirements in writing and verify the negotiated leg.

Concurrent calls and burst

Not verified

Endpoint count, DID count and failover destinations do not establish simultaneous-call or call-start capacity. The reviewed public pages do not publish one account's concurrent-call, CPS, burst, queueing or abuse limits. Obtain the active limits, per-destination behavior and billing treatment before an authorized load test.

Emergency calling

Documented

Current VoIP Innovations material describes E911 callback and location provisioning and a dynamic-location option. The governing service terms make customer-supplied validated location and SIP-invite data part of the workflow. Confirm eligible numbers, static or dynamic location mode, caller identity, alerts and the provider-approved test process for every site; retain an independent fallback.

Pricing model

Not verified

The public service pages describe wholesale origination, termination and optional features but do not publish a complete current account rate card. Obtain a dated quote or portal export covering numbers, inbound and outbound destinations, billing increments, failover, E911, messaging, porting, taxes, commitments and renewal terms.

Administration and support

Documented

The BackOffice portal manages endpoint groups, DIDs, features and client permissions, and Sangoma publishes programmable service interfaces. Portal state and an API response do not define the account SLA, support response, configuration propagation or audit retention. Preserve exports, redacted traces, provider call identifiers and cases together.

SMS and MMS

Documented

VoIP Innovations publishes wholesale SMS/MMS and programmable messaging, while the service API exposes destination types including SIP, email and HTTP callbacks. Voice service on a DID does not prove messaging eligibility, campaign registration, consent, sender approval, throughput, payload support or fees. Verify the exact number and messaging program independently.

Bind each DID to an Endpoint Group deliberately

Inbound DIDs route to an Endpoint Group containing customer IP destinations. The current FreePBX procedure describes E.164 delivery by default. Record the exact DID, group, destination address and port, provider source set, delivered called-party format and PBX context; a successful outbound call does not prove this inbound chain.

Endpoint Groups offer top-down and round-robin selection. Top-down starts with the first address and advances under documented failure conditions. Round-robin distributes the first attempt but can still advance through other destinations. Keep selection order, response handling and restoration behavior visible instead of describing both modes as load balancing.

Keep three recovery mechanisms separate

Endpoint Group advancement is a new-call routing decision triggered by non-response or documented SIP rejections. Per-DID failover can then send a call to an off-net telephone number after customer addresses are exhausted. Sangoma warns that more than four group addresses may consume the call timeout before DID failover is reached. This does not preserve an established SIP dialog or its media.

Call forwarding is a third feature and has its own billing boundary. Write tests for the intended address order, each approved response, total timeout, off-net destination and restoration. Record provider call identifiers and both PBX and edge traces. Do not infer a completed recovery from a configured secondary address.

Prove media, fax and protection on the selected route

Sangoma's Asterisk example lists G.711 mu-law, optional G.729 and RFC 2833 DTMF. These are configuration and capability statements, not evidence that a route is available, a codec is licensed, media is direct or digits complete. Capture the offer, answer, RTP endpoints, payloads and DTMF result for representative directions and destinations.

The reviewed procedures use UDP examples and do not establish a customer-facing TLS identity, certificate-validation procedure, SRTP profile or downgrade policy. Source-IP authorization is not encryption. T.38 appears as a DID or client feature, while the generic Asterisk example leaves it disabled. Qualify the exact DID, direction, carrier route, gateways and document set separately, retaining an approved audio-fax fallback policy.

Turn inventory and capacity claims into account facts

The current wholesale origination page describes local and toll-free inventory plus associated E911, messaging and caller-name features. It does not establish the stock, portability, identity documents or feature combination for one number on one date. Preserve the search or port decision, required documents, activation result and caller-identity rights.

Endpoint count, DID count and failover destinations do not define simultaneous-call or call-start capacity. The reviewed public material does not publish one account's concurrency, CPS, burst, queuing or abuse limits. Obtain those limits and per-destination behavior before a bounded, authorized load test. Likewise, obtain a dated quote covering numbers, traffic, billing increments, failover, E911, messaging, porting, taxes, commitments and renewal terms.

Coordinate emergency, messaging and operational ownership

VoIP Innovations describes E911 callback and location provisioning plus a dynamic-location option. Its service terms make customer-supplied validated location and SIP-invite data part of the workflow. Confirm eligible numbers, static or dynamic mode, caller identity, dispatchable location, alerts, update ownership and the provider-approved test process for every site. Do not place an unapproved emergency call, and retain an independent fallback.

Voice activation does not prove SMS or MMS eligibility. Verify the exact number, campaign and sender approvals, consent, destination type, callback protection, throughput, payloads and fees. The BackOffice portal and programmable interfaces can manage service objects, but neither an on-screen state nor a successful API response defines the account SLA, propagation time, support response or audit retention. Preserve exports, redacted traces, provider identifiers and cases together. No VoIP Innovations account, endpoint group, trunk, DID, call, codec, DTMF, fax, protected transport, failover, capacity, emergency call, message, rate, availability or support response was tested for this guide.

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 · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
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 →
Guide

SIP trunk channels and simultaneous calls

Size external capacity around busy-hour demand and the provider’s counting rules.

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

Planning emergency calling for a VoIP deployment

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

Read guide →
Guide

Business number porting: a cutover checklist

Keep ownership records, dependencies and a fallback plan aligned with the gaining provider’s process.

Read guide →
Guide · Analog interface and carrier behavior vary by device, region and firmware

Fax over VoIP: T.38 relay versus G.711 passthrough

Choose a fax path from end-to-end support and observed document delivery, not a codec checkbox.

Read guide →