Freeze package membership before changing a trunk
IntelePeer describes a package as the container for numbers and trunks. Numbers in a package follow that package's routing policy, so the account, billing type, package, number inventory, trunk order and routing profile are separate objects that must be recorded together. Moving a number to another package can change the routing policy it follows.
A number visible in inventory does not establish its current package, profile, selected trunk, customer-edge receipt or PBX destination. Preserve the completed order, current package membership, route-profile name and every trunk in that profile before changing local SIP configuration.
Documented service facts
Reviewed 2026-10-20. Compare SIP trunk services →
SIP authentication
Not verifiedThe reviewed portal and trunk-management material does not publish one universal SIP digest realm, credential lifecycle, mutual-certificate procedure or source-IP authorization rule. Portal and API login controls are management credentials, not evidence of how the ordered SIP trunk identifies a PBX. Obtain the trunk order and turn-up record.
SIP registration
Not verifiedThe reviewed first-party pages establish ordered trunks and routing policies but do not state that every trunk uses REGISTER, a fixed peer or one registrar. Record the exact ordered interconnection point, transport, addresses, registration requirement and contact ownership rather than importing a generic PBX template.
Inbound delivery
DocumentedNumbers belong to packages and follow that package's routing policy. Bundle packages use a primary and optional redundant trunk; usage packages use Round Robin, Sequential or Proportional profiles. Package membership, profile type, selected trunk, number translation, edge receipt and PBX result remain separate evidence.
Routing and failover
DocumentedPackage-level redundant trunks, usage-profile selection and switched-number translations are distinct. Forward is unconditional; number Failover applies when the trunk is not responding to INVITEs and can take five to ten minutes after submission. The public material does not define one universal timer, retry-code or established-call contract.
Number and regional availability
DocumentedThe portal distinguishes US domestic, toll-free and international number inventories and supports new-number and port orders. Inventory visibility does not establish current stock, portability, identity rights, regulatory eligibility or service coverage for a particular country and number type; use the dated order result.
Audio codecs
Not verifiedThe reviewed portal, routing and emergency guides do not publish a generic production-trunk codec, packetization, DTMF or transcoding profile. RTP in the emergency-routing description does not establish the codec or media result for an ordinary trunk call. Obtain the current interface specification and preserve the actual offer and answer.
T.38 fax
Not verifiedNo universal T.38 procedure or fax guarantee was found in the reviewed first-party trunk, portal, routing and emergency material. Confirm the exact account feature, gateway mode, switchover, codecs, page profile and delivery report rather than inferring fax support from ordinary voice service.
Signaling and media encryption
Not verifiedThe reviewed sources do not define one customer-facing SIP TLS hostname, certificate-validation procedure, SRTP profile or downgrade policy for every trunk. HTTPS portal and API access and a SIP location object for emergency routing do not establish protected PBX-facing signaling or media.
Concurrent calls and call starts
Not verifiedThe portal exposes bundle allocations and can notify a contact when port utilization reaches 80 percent, but the reviewed sources do not publish one numeric concurrent-call or calls-per-second limit for every account. Purchased ports, active calls, utilization, call starts, trunk resources, PBX channels and bandwidth remain separate quantities.
Emergency calling
DocumentedThe portal distinguishes static 911, Generic Dynamic 911 and Microsoft Teams Dynamic 911. Dynamic service requires prevalidated locations and SIP location information; missing or invalid routing data can send a call to an emergency call center. The integration guide documents coordinated 933 and failover tests. Exact country, number, package, caller identity, callback number, location and approved test path still require account validation.
Pricing model
Not verifiedThe portal distinguishes bundle, usage and outbound-only customers and supports billing and usage reports, but the reviewed public material is not a complete current rate card. Obtain dated contract terms for ports, minutes, numbers, porting, emergency service, messaging, support, minimums, taxes, renewal and cancellation.
Administration and support
DocumentedThe portal manages packages, trunks, profiles, numbers and translations. CDRs can identify the record, trunk name, package, label, translated number, codec and identity; optional daily ADR CSV files can be retained for forty-five days. These records remain correlation evidence rather than proof of PBX or media outcomes.
SMS and MMS
DocumentedIntelePeer documents separate SMS/MMS-capable numbers and APIs, including send, receive-webhook and message-status operations. A voice number or SIP trunk order does not itself prove messaging capability, campaign registration, sender authorization, webhook security, throughput or price; confirm the exact number and messaging entitlement.
Keep bundle and usage routing models distinct
For bundle customers, IntelePeer documents one primary trunk and an optional redundant trunk per package. For usage customers, the Routing Policy Manager can arrange trunks in Round Robin, Sequential or Proportional profiles. These are different models; a usage profile is not evidence of bundle primary-and-redundant behavior, and a bundle redundant trunk is not a weighted usage-profile member.
Record the billing model, profile type, ordered trunks, production signaling addresses and current order state. A portal save or trunk order does not prove provider execution, independent customer access, PBX readiness or media continuity.
Separate redundant trunks from number translations
A package-level redundant trunk and a switched-number translation are different controls. IntelePeer documents Forward as unconditional redirection and Failover as sending the active number to an alternate telephone number when its trunk is not responding to INVITEs. The portal guide says a submitted forward can take five to ten minutes to be in place.
Preserve the affected number, translation type, destination, failover value, overwrite choice, submission result and observation time. Do not treat a forwarded PSTN answer as proof that the SIP trunk recovered, or use a translation to conceal an unresolved package or PBX route mismatch.
Trace the selected route without inventing failure rules
For every failed or unexpected inbound attempt, retain the number's package, route-profile type, ordered or weighted trunk membership, provider timestamps, each customer signaling address and the first SIP response or absence of response. The public FAQ describes network-failure routing but does not publish one universal timer, retryable-response table, restoration sequence or established-dialog guarantee for every trunk.
Classify what is actually observed: the number belonged to another package, the profile contained the wrong trunks, the selected customer edge did not receive the INVITE, the PBX rejected it, or a separate telephone-number failover was active. Change only the first proven divergence.
Use CDRs as correlation evidence, not delivery proof
IntelePeer's CDR reference includes a unique CDR identifier, customer-defined trunk name, package, number label, negotiated codec, translated number and optional P-Asserted-Identity. The quick-start guide also describes optional daily ADR CSV delivery with files available for forty-five days through the account's secure FTP site.
Correlate the provider record with UTC time, called and calling identities, customer-edge capture, SIP Call-ID, PBX route, SDP and both RTP directions. A CDR row, package name, codec field or billable duration does not by itself prove the expected PBX accepted the call or that users had intelligible two-way audio.
Keep emergency failover and commercial terms bounded
IntelePeer's Dynamic 911 testing guide documents a coordinated 933 process and a simulated SIP 410 that should cause the customer system to try the alternate SBC. It also distinguishes other 4xx, 5xx, 6xx or no-response failures from 487 generated after CANCEL. That emergency test contract is not a generic inbound package-failover rule.
Preserve endpoint identifier, caller and callback identity, validated location, package, SBC, approved test window and observed response together. Obtain account-specific contracts for capacity, coverage, pricing and support. No account, route, CDR, failover or call was laboratory validated for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IntelePeer Customer Portal quick-start guide ↗
- IntelePeer Customer Portal FAQs ↗
- IntelePeer number inventory and package management ↗
- IntelePeer call-detail record reference ↗
- IntelePeer number forwarding and failover ↗
- IntelePeer Phone Number DID Management API ↗
- IntelePeer Dynamic 911 configuration guide ↗
- IntelePeer Dynamic 911 location routing ↗
- IntelePeer Dynamic 911 integration testing ↗
- IntelePeer SMS and MMS API portal guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.