Start with the ordered business or wholesale interface
Iristel publishes separate business and wholesale SIP-trunk offers. The business page describes an on-premises SIP-compatible PBX, while the wholesale page describes connectivity and capacity controls. Neither page supplies one universal registrar, source-address policy, transport, codec, media or certificate profile for every customer. Preserve the current order, provider handoff, signaling peers, source controls, credentials owner and loaded PBX or SBC objects.
Generic authentication, encryption and compatibility language is not an implementation profile. Do not infer REGISTER, static IP peering or a supported configuration from the product name. Prove the observed transaction and the specific handoff before changing authentication or transport.
Documented service facts
Reviewed 2026-10-21. Compare SIP trunk services →
SIP authentication
Not verifiedIristel uses generic authentication language but the reviewed public pages do not define the ordered method, credential owner, digest realm, algorithms, source controls or certificate role. Preserve the handoff and observed exchange without publishing secrets.
SIP registration
Not verifiedThe reviewed pages do not establish whether an ordered trunk registers, uses static IP peering or supports both. Portal-editable connectivity IPs are configuration inputs, not proof of the active model. Preserve signaling peers, transport, Contact and source requirements.
Inbound delivery
DocumentedEspresso DID is described for DID ordering and configuration, LNP workflows, connectivity, CDRs and reporting. Portal inventory and port status do not prove activation, provider delivery, Request-URI, edge receipt or PBX matching.
Routing and failover
DocumentedIristel describes automatic failover destinations and redirection to backup lines when a primary path fails. The public pages do not establish one account trigger, timer, response-code policy, retry order, restoration sequence or active-call result.
Number and regional availability
DocumentedIristel describes broad Canadian CLEC coverage and DID/LNP functions. Preserve serviceability, number inventory, port status and activation for the exact rate centre and use; network language is not eligibility proof.
Audio codecs and DTMF
Not verifiedThe reviewed SIP-trunk pages do not publish a complete current codec, packetization, DTMF, early-media, transcoding or media-address profile for the ordered interface. Obtain the provider handoff and retain both SDP bodies, negotiated payload mapping, RTP evidence and decoded digit results on each required call path.
T.38 fax
Not verifiedIristel's support page discusses general fax-quality symptoms, but the reviewed SIP-trunk pages do not establish T.38 or audio-fax entitlement, direction, switchover, gateway compatibility, redundancy or page limits. Treat fax as a separately ordered and accepted workflow using the current interface record.
Signaling and media encryption
Not verifiedThe business page uses general encryption and authentication language, but the reviewed public pages do not define SIP TLS versions, certificate validation, client certificates, SRTP mode, media-key exchange or protection across every call leg. Record the ordered controls and preserve handshake and SDP evidence for the actual path.
Concurrent calls and call starts
DocumentedIristel describes portal capacity changes and metered or unmetered service. These are not numeric channel, CPS, burst or performance proof. Bind capacity and usage controls to the dated order and account records.
Emergency calling
DocumentedIristel says 911 termination is added upon request and supports DID-level address listings through API or portal paths. Listing, termination and a working route are separate records; use only the provider-approved validation procedure.
Pricing model
DocumentedIristel says wholesale trunks can be metered or unmetered, while its public business page describes cost savings without publishing a complete account price. Use a dated quote, contract and bill for access, channels, usage, numbers, ports, failover, emergency service, support, taxes, term, deposits, renewal and cancellation.
Administration and support
DocumentedEspresso DID supports DID, connectivity, LNP, CDR and reporting functions; MyIristel and Service Portal are separate account surfaces. A saved portal IP or provider CDR does not prove customer-edge receipt, PBX routing or media.
SMS and MMS
Not verifiedIristel offers separate messaging products, but the reviewed SIP-trunk pages do not establish SMS or MMS entitlement on trunk DIDs, sender registration, API access, throughput, webhook security, retention or price. Treat messaging as a separately ordered product and workflow rather than an implied property of a voice trunk or DID.
Keep DID, LNP, connectivity and activation state distinct
Iristel describes Espresso DID functions for simple or batch LNP submission, status tracking, editing pending or rejected requests, activating confirmed ports, cancellation and history. It also describes DID ordering and configuration plus connectivity controls. A portal record is administrative evidence; it does not prove that a number is active on the expected trunk, that the selected connectivity IP is carrying traffic or that the PBX matches the delivered identity.
Preserve the DID, port request, confirmed activation, trunk, configured IP, provider delivery target, Request-URI, asserted identity, digit normalization and first loaded route. Treat a portal IP change as a configuration input until an authorized call proves edge receipt.
Correlate provider CDRs with edge and PBX evidence
The Espresso DID portal is described as providing real-time CDRs and reporting. A provider CDR can correlate a number, direction and time window, but it cannot prove which customer interface received an INVITE, which PBX route loaded, what SDP was accepted or whether audio was bidirectional.
Match one provider record to an authorized edge trace. Preserve source, Request-URI, To, asserted identity, Via, Contact, authentication exchange, SDP and response sequence, then follow the effective PJSIP identify, endpoint, transport, context, digit normalization and first matching Asterisk or FreePBX route.
Separate provider redundancy from failover destination behavior
Iristel describes redundant infrastructure and automatic failover destinations, and its failover article discusses redirecting calls to backup lines when a primary path fails. The reviewed pages do not define a universal trigger, timer, response-code policy, retry order, restoration sequence or established-call result. Record those values from the order and provider change history for the affected number or trunk.
Provider-core redundancy, the customer access path, the customer edge, PBX routing and a telephone-number failover destination are separate layers. An answered backup line proves that one redirected leg answered; it does not prove why the primary failed, that another SIP target was tried, that an existing call survived or that normal routing was restored.
Bind calling identity and capacity to account records
Iristel says wholesale customers can augment capacity and add, remove or change IPs through a portal, and offers metered or unmetered service. Those statements do not establish an account channel entitlement, call-start rate, burst, active edge or price. The Reasonable Use Policy also says calls must originate from assigned Iristel numbers within the provided trunk and ANI must correspond to one of those numbers.
Preserve the dated order, assigned-number inventory, allowed ANI, channels, rate controls, bandwidth, IP changes and current bill. Do not use an arbitrary caller ID as a diagnostic shortcut or infer capacity from an ordinary successful call.
Keep emergency listing, termination and validation separate
Iristel says wholesale 911 termination is added upon request and that address listings can be updated through API or portal paths at DID level. An address row, a termination order and a working emergency route are distinct records. Preserve the DID, civic address, calling identity, callback path, ordered termination, PBX route, power and access dependencies and the provider-approved validation procedure.
Do not place an uncoordinated emergency call. Maintain an independently powered alternative method. No Iristel account, trunk, number, portal, route, call, media, failover, emergency result, price, availability or compatibility was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Iristel business SIP Trunking ↗
- Iristel wholesale SIP Trunking ↗
- Iristel SIP trunk failover and redundancy ↗
- Iristel wholesale E-911 services ↗
- Iristel account and Espresso DID portals ↗
- Iristel support centre ↗
- Iristel network status ↗
- Iristel Reasonable Use Policy ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.