Identify the order, tenant, site and exact handoff
Start with the accepted Telesystem order, customer and tenant, Blue Platform site or group, trunk name, enabled features, service address and activation record. Telesystem documents public-Internet and private-network routing plus dynamic or dedicated bandwidth choices; its product page also lists DS-0/FXS, DS-1/PRI and RJ-45/Ethernet handoffs. Preserve the exact ordered demarcation instead of flattening these into a generic SIP service.
A product page, portal row, network point of presence, loaded PBX object and completed call are separate evidence. Hosted Station and other Telesystem voice products are not automatically part of a SIP Trunk order.
Documented service facts
Reviewed 2026-10-29. Compare SIP trunk services →
SIP authentication
DocumentedThe tenant guide distinguishes registration-based authentication, ESBC and direct peering. The exact trunk checkbox, username reference and network point of presence govern; no universal credential or source-IP model is inferred.
SIP registration
DocumentedThe portal can indicate that the PBX sends SIP registration. A checkbox, username or configured object does not prove a current accepted registration or completed call.
DIDs and inbound delivery
DocumentedThe portal exposes trunk DIDs, ranges and a main or pilot number. Assignment, activation, delivered called value, forwarding state, PBX route and final answer remain unverified.
Forwarding, reroute and trunk groups
DocumentedAlways, Unreachable, phone-number forwarding, same-tenant reroute and optional Enterprise Trunking are separate controls. Enrollment, trigger, alternate answer, established-call behavior and restoration remain unverified.
Access and handoff
DocumentedTelesystem describes public or private routing, dynamic or dedicated bandwidth and several physical handoffs. The accepted order, site, demarcation, serviceability, activation and observed route govern.
Codecs and media
Not verifiedReviewed public records do not publish one universal codec, packetization, DTMF, encryption or transcoding profile. Offer, answer, packet directions, decoding and audibility remain unverified.
Fax
Not verifiedThe reviewed SIP Trunks records do not establish T.38, passthrough, fallback, gateway requirements or completed-page behavior for one order.
Portal and edge custody
DocumentedTenant credentials, read-only access details and provider-engineer changes are documented. Password custody, edge hardening, certificate policy, encryption and observed protection remain deployment-specific.
Sessions and bursting
DocumentedThe portal documents total and optional directional session limits; zero directional fields mean no separate directional cap. Bursting is a chargeable option not typically enabled by default. Entitlement and observed capacity remain separate.
E911 and dispatchable location
DocumentedE911 is optional, and an authorized contact can request the addresses on file. One number’s eligibility, location, callback, notification, provider route and approved validation remain unverified.
Price, fees and availability
Not verifiedTelesystem publishes fee definitions but not a complete account quote. Access, sessions, bursting, forwarding licenses, numbers, usage, support, taxes, term, serviceability and activation remain order-specific.
Portal, status and support
DocumentedTelesystem publishes portal resources, 24x7 technical support, status, ticket and escalation paths. Portal rows, notices, tickets, provider findings and verified restoration remain separate evidence.
SMS and MMS
Not verifiedThe reviewed SIP Trunks records do not establish SMS or MMS eligibility, sender registration, consent controls, API access, throughput, retention or pricing for trunk numbers.
Read authentication and network-point-of-presence evidence together
The tenant-admin guide makes Access Details read-only and distinguishes registration-based authentication, an installed enterprise session border controller and direct peering. Record whether “My PBX Will Send SIP Registration” is enabled, the authorized username reference, the displayed network point of presence, ESBC label or direct-peer trunk name, and the configuration actually loaded on the customer edge.
Do not publish passwords or copy settings from another site. Registration, IP reachability, a responding peer and an accepted call remain different states. Telesystem’s broad “any phone system” language is a product statement, not certification of one model, release or configuration.
Separate total capacity, directional limits and bursting
The portal documents a total maximum simultaneous-call value and optional incoming and outgoing limits. A displayed directional value of zero means no directional limit is configured; it does not mean zero calls are allowed. Preserve total entitlement, each directional control, active dialogs, new attempts, PBX resources and provider responses separately.
Bursting is described as a chargeable feature that is not typically enabled by default. A product claim that sessions can be purchased individually, or a visible maximum, does not prove bursting, calls-per-second behavior, current usage, billing treatment or the result of a load event.
Bound forwarding, reroute and enterprise trunk groups
The guide separates Call Forwarding Always from Call Forwarding Unreachable. It allows a phone-number destination or reroute to another trunk in the same tenant; Unreachable can wait 1–15 seconds for registration before forwarding. Switch-level forwarding bypasses the PBX, and whole-trunk forwarding differs from separately licensed DID-level forwarding.
Enterprise Trunking and the Trunkgroups menu are not configured by default. Load balancing, redundancy and aggregate capacity apply only when that design is ordered and configured. A saved destination does not prove the trigger occurred, the alternate answered or established calls survived.
Keep DID inventory, forwarding and PBX routing distinct
The portal exposes read-only trunk DIDs, ranges and a main or pilot number. The separate DID-forwarding guide says portal forwarding for an individual DID overrides native PBX settings. Preserve number order, port or activation state, trunk association, DID-level license, portal setting, delivered called value, PBX route and final answer separately.
A main number may be used as an identifier or for authentication, but that description does not establish the rule for every account. An inventory row or forwarding toggle is not proof of live provider routing.
Bind E911 to the authorized number and dispatchable location
Telesystem lists E911 as optional and directs an authorized contact to request the location addresses on file. Keep service eligibility, assigned number, dispatchable address, callback number, notification behavior, PBX access code, provider route, power and network dependency separate.
The public E911 page discusses Kari’s Law and RAY BAUM’S Act, but it is not a legal determination for one deployment. Use the provider-approved non-live validation path; never place an uncoordinated live emergency call.
Preserve commercial, status, ticket and restoration evidence
Telesystem publishes fee definitions, including change, support, network recovery, number-portability and E911 categories, but those definitions are not a complete account quote. The status page, 24x7 support path, trouble-ticket route and escalation chart provide operational channels.
Keep notice, affected service, ticket, provider finding, action and verified restoration separate. A public maintenance or outage item does not prove one customer is affected, and a cleared notice does not prove every trunk, route or media path recovered.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Telesystem — SIP Trunks product page ↗
- Telesystem — SIP Trunks feature guide ↗
- Telesystem — SIP Trunk Administration for Tenant Admins ↗
- Telesystem — Blue documents and help videos ↗
- Telesystem — SIP Trunk DID Forwarding quick reference ↗
- Telesystem — E911 compliance guidance ↗
- Telesystem — product and service fee definitions ↗
- Telesystem — network status and support paths ↗
- Telesystem — account support and escalation contacts ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.