Treat the package as the routing and number boundary
IntelePeer's portal documentation describes a package as the container for trunks and numbers. Numbers in that package follow its routing policy. That makes package membership, number inventory, routing profile and trunk order separate operational objects; moving a number to another package can change the route it follows.
Record the account, billing type, package, assigned numbers, primary or routing-profile trunks and current order status before touching PBX configuration. A visible number or trunk in the portal does not prove the number is assigned to that route, the PBX accepts its traffic or the intended destination answers.
Documented service facts
Reviewed 2026-10-06. 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. Usage accounts can place available trunks into a routing profile, while bundle accounts use a primary trunk and optional redundant trunk. Number assignment, package, profile, selected trunk, delivered identity and PBX destination remain separate evidence.
Routing and failover
DocumentedUsage-account routing profiles can be round-robin, sequential or proportional. Bundle packages can have one primary and optional redundant trunk, with traffic described as moving to the redundant trunk after network failure. These new-call controls do not prove the trigger, independence, retryable responses, restoration sequence or survival of an established call; verify the ordered design and test plan.
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 Customer Portal manages packages, trunks, routing, numbers, port orders, roles, support cases, usage and billing. Daily application-data records can be retained for 45 days on the account's secure FTP site when enabled. Portal configuration is administrative evidence; it does not prove a trunk is loaded on the PBX or a call succeeded.
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 separate
For bundle customers, IntelePeer documents one primary trunk and an optional redundant trunk per package, with traffic routed to the redundant trunk after a network failure. For usage customers, the Routing Policy Manager can arrange available trunks in round-robin, sequential or proportional profiles. These are different models and should not be blended into one universal failover procedure.
Preserve route order or weighting, ordered trunk endpoints, failure criteria, SIP responses, timeout, restoration and established-call behavior. Provider routing controls do not prove independent customer access paths, PBX survival or media continuity. Test only coordinated new-call failure scenarios and record which owner detected and repaired each fault.
Do not infer SIP identity from portal access
The reviewed public portal and FAQ material explains how to order and manage trunks but does not publish one generic digest realm, REGISTER workflow, source-IP rule, TLS hostname or SRTP profile for every account. Portal credentials, API access and optional two-factor authentication protect management access; they are not SIP trunk credentials.
Obtain the exact turn-up record and interface specification. Record peer addresses, transport, authentication direction, registration requirement, called- and calling-identity formats, codecs, DTMF, capacity and protection controls. Verify the loaded PBX object and one authorized call without copying parameters from a different package or service.
Separate port capacity, utilization and call starts
The portal can expose bundle allocations and notify a designated contact when port utilization reaches 80 percent. The reviewed sources do not publish one numeric account-wide calls-per-second or concurrent-call ceiling. A port allocation, an active call, a utilization threshold, a call start and a PBX channel are different quantities.
Use dated contract and portal evidence to record purchased ports, any pooling boundary, inbound and outbound treatment, burst controls and call-start limits. Then compare authorized observations with the PBX and access bandwidth. An alert configuration is not proof that a notification was delivered or that added capacity is active.
Provision emergency service as its own workflow
IntelePeer distinguishes Static 911, Generic Dynamic 911 and Microsoft Teams Dynamic 911. Dynamic routing requires the customer's equipment to send supported location information and depends on prevalidated locations. The routing guide says missing, invalid or unmatched information can route the call through an emergency call center rather than directly to the intended public-safety answering point.
Preserve number, package, caller name, callback number, identifier, validated location, SIP location object and actual routing result separately. Use the documented coordinated 933 and failover test process; do not place an uncoordinated live emergency call or treat a stored address as proof that every endpoint supplies current location.
Keep messaging and commercial terms separate from voice
The portal can manage SMS services, and IntelePeer documents separate send, receive-webhook and status APIs for messaging-capable numbers. A voice number or trunk does not automatically carry messaging entitlement, sender registration, throughput, webhook protection or commercial terms. Confirm each capability on the exact number.
Likewise, bundle, usage and outbound-only account types do not provide a complete public rate card. Obtain a dated contract or quote covering ports, minutes, number rental, porting, emergency features, messaging, support, minimums, taxes, renewal and cancellation. No account, contract, package, trunk, number, route, credential, PBX, SBC, port allocation, call, media stream, failover event, emergency workflow, message, price, availability or support response was inspected or tested 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 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.