Identify the ordered service, affiliate and country
Start with the accepted service order, legal customer, contracting affiliate, country, site, service address, Enterprise SIP Trunking product, broadband owner, PBX, IAD if ordered, telephone numbers, features, start date and support path. Voyant by Sinch product identity, legacy ANPI references and Inteliquent network guidance help correlate evidence but do not replace the order.
The SIP terms describe enterprise voice and optional data SIP trunking and say an IAD may be included. Preserve what was actually ordered instead of transferring a feature or limitation from another customer, country or service.
Documented service facts
Reviewed 2026-10-29. Compare SIP trunk services →
SIP authentication
Not verifiedPublic records do not publish one universal registration, address-identification, username, password, realm or certificate model. The accepted order and loaded edge govern.
SIP registration
Not verifiedEnterprise SIP Trunking and an optional IAD are documented, but public records do not establish whether one order registers, peers by address or uses managed edge equipment.
Telephone numbers and inbound calling
DocumentedTelephone numbers and inbound calling are documented. Order, port, assignment, provider attempt, delivered value, PBX route and answer remain unverified.
Network redundancy and restoration
Not verifiedNetwork redundancy is marketed, but one order trigger, target, access survival, alternate answer, established-call behavior and restoration remain unverified.
Country, access and handoff
DocumentedBroadband is required and service scope is order- and country-specific. The exact affiliate, site, circuit, demarcation, IAD, PBX and activation govern.
Codecs and media
Not verifiedReviewed public records do not establish one universal codec, packetization, DTMF, encryption, transcoding or media-range policy. Offer, answer, packets and audibility remain unverified.
Fax
Not verifiedVoyant markets fax separately. Reviewed SIP trunk records do not establish T.38, passthrough, fallback or completed-page behavior for one order.
Caller identity and credential custody
DocumentedAssigned-number caller-ID requirements are documented for Voyant/ANPI trunks. Credentials, attestation, provider rewrite and destination display remain separately observable.
Lines and elastic channels
DocumentedSelected voice lines and dynamically allocated elastic channels are documented as different order models. Entitlement, active dialogs, attempts, PBX limits and completion remain separate.
E911 location and notification
DocumentedPer-number E911 addresses, bulk import and notifications are documented. Eligibility, effective update, callback identity, PBX route, power, broadband and approved validation remain unverified.
Price and availability
Not verifiedReviewed public records do not establish one complete quote. Lines or elastic channels, access, numbers, usage, features, support, taxes, term, serviceability and activation remain order-specific.
Status and support
DocumentedVoyant publishes Enterprise SIP Trunking components and technical-support paths. Notices, cases, provider findings, actions and verified customer restoration remain separate evidence.
SMS and MMS
Not verifiedThe reviewed SIP trunk records do not establish SMS or MMS eligibility, consent, sender registration, throughput, retention or pricing for trunk numbers.
Separate access, line allocation and elastic capacity
Voyant says broadband is required. The master agreement distinguishes a selected number of voice lines terminating to customer premises equipment from dynamically allocated channels through an elastic SIP trunk. Record trunk type, ordered line or channel policy, broadband service, demarcation and PBX resources separately.
Assigned lines, elastic allocation, active dialogs, offered attempts, call starts, bandwidth, local channels, provider responses and completed calls remain different quantities. Public scale, call-completion or backbone language is not a measured ceiling or load result.
Keep portal state, loaded configuration and calls distinct
Voyant describes self-service through portals and APIs, while the status page exposes a Customer Administration Portal component. Record the authorized account, exact trunk, number, E911 row, saved value, audit time and effective status separately from PBX or SBC objects loaded at the edge.
A portal login, saved row, API response or green component does not prove authentication, inbound delivery, outbound acceptance, two-way media or service restoration.
Bind caller identity to assigned on-net numbers
Voyant/ANPI guidance published through Sinch says the caller-ID model changed with STIR/SHAKEN: the FROM identity must be a number owned, configured and assigned to the account, and off-net numbers no longer carry guaranteed completion or presentation. Preserve the calling number, P-Asserted-Identity, account assignment, provider rewrite, attestation evidence, destination display and response separately.
Do not infer caller-ID authorization from ownership of a different pilot number, and do not treat presentation at one destination as proof for every call type.
Bind E911 to each number, location and effective record
Voyant documents per-number E911 addresses, bulk CSV updates and optional notification recipients in the Customer Administration Portal. Its emergency notices retain dependencies on accurate records, equipment location, power, broadband, account state and callback communication.
Keep eligibility, number, validated address, effective update, notification, callback identity, PBX route and access separately observable. Use only the provider-approved non-live validation process; a saved address or 933 playback is evidence of the checked record, not proof of every live emergency outcome.
Treat caller-ID, emergency and country rules as scoped evidence
The reviewed US SIP terms, US emergency information and Canadian 9-1-1 notice carry different scopes. Retain the service country, contracting record, number jurisdiction and applicable notice before applying a requirement.
Do not flatten US E911 portal controls, Canadian third-party routing language, legacy ANPI caller-ID guidance and one current Voyant order into a universal configuration or compliance conclusion.
Preserve status, case, finding and restoration separately
Voyant publishes Enterprise SIP Trunking components for portal, inbound, outbound, toll-free, international, 911 and network trunking, plus separate technical-support and NOC paths. Preserve the public notice, affected account and site, case number, sanitized evidence, provider finding, action and verified ordinary-call restoration as different records.
A green status component does not prove one customer route is healthy. A case, cleared notice or configuration change does not prove signaling, caller identity, media and emergency records all recovered.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voyant — communications products and SIP Trunking ↗
- Voyant — Master Services Agreement ↗
- Voyant — SIP Trunking terms and conditions ↗
- Voyant — VoIP 911 information ↗
- Voyant — Canadian 9-1-1 service notification ↗
- Sinch Community — SIP Trunk E911 bulk import in CAP, August 2024 ↗
- Sinch Community — Voyant/ANPI SIP Trunking STIR/SHAKEN caller-ID changes ↗
- Voyant — support contacts ↗
- Voyant — service status ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.