Start with the selected access and handoff
Eastlink describes SIP Trunking as one converged voice and data connection delivered to the customer's chosen phone system. It offers a QoS-enabled private network or secure encryption over the Internet, and says the service is commonly delivered over its facilities-based fibre. Those are different access and protection choices, not one universal configuration.
Require the dated order and accepted implementation handoff. Record each location, demarcation, access circuit, PBX or SBC version, signaling and media peers, authentication owner, number inventory, capacity and support boundary before adapting a configuration.
Documented service facts
Reviewed 2026-10-08. Compare SIP trunk services →
SIP authentication
Not verifiedEastlink's public product pages do not define the selected PBX handoff's credential or source-address authentication method, digest realm or algorithms, certificate roles, mutual authentication or allowlist. Obtain the accepted implementation record and map each secret, address and certificate to its Eastlink, PBX or SBC owner without exposing reusable values.
SIP registration
Not verifiedThe reviewed public pages do not establish whether an ordinary Eastlink PBX trunk uses REGISTER, static peering or another handoff. The separately described Microsoft Teams Direct Routing service uses Eastlink-hosted certified SBCs, but that does not define a generic registrar, proxy, Contact, expiry, qualification, DNS or source-address rule for every trunk. Use the selected order and implementation handoff.
Inbound delivery
Not verifiedEastlink describes SIP as connecting a chosen phone system to the PSTN and says its Teams offer can retain, activate and deactivate phone numbers. Those portfolio capabilities do not establish one trunk's assigned inventory, completed port, delivered Request-URI, asserted identity, digit format or PBX route. Preserve the order, number record and authorized traces for every accepted pattern.
Routing and failover
Not verifiedThe SIP page describes facilities-based fibre and extending channels over IP networks to multiple locations. The Teams page separately describes redundant hosted certified SBCs. Neither source defines one ordinary trunk's ingress and egress peers, customer-access diversity, route priority, trigger, timers, alternate destination, established-call behavior or restoration order. Bind continuity to the selected topology and an approved new-call exercise.
Number and regional availability
Not verifiedThe reviewed pages describe multi-location and Microsoft Teams deployments but do not publish a current rate-centre inventory or establish serviceability, number availability, portability or installation lead time for one address. Retain dated qualification and port responses for every service location, number block and requested activation date.
Audio codecs and DTMF
Not verifiedThe reviewed public pages do not publish a complete current codec, packetization, DTMF, early-media, transcoding or media-address profile for the selected interface. Obtain the Eastlink-approved handoff and preserve both SDP bodies, negotiated payload mapping, RTP evidence and decoded digits for each required call path.
T.38 fax
Not verifiedEastlink says its Teams programme can integrate legacy fax through supporting voice services, but that does not establish T.38 or audio-fax entitlement, direction, switchover, gateway compatibility, redundancy or page limits on a SIP trunk. Treat fax and other non-voice devices as separately designed and accepted workflows.
Signaling and media encryption
Not verifiedEastlink offers a QoS-enabled private network or secure encryption over the Internet as different delivery choices. That statement does not publish SIP TLS versions, certificate validation, client certificates, SRTP suites, keying or protected call legs for the selected order. Keep access isolation, authentication, signaling protection, media protection, PBX hardening and fraud controls separate until the handoff and authorized traces prove them.
Concurrent calls and call starts
DocumentedEastlink says SIP scales to hundreds of channels on one IP interface and that channels can be added or removed. This is a portfolio-scale statement, not an accepted account value. Ordered channels remain separate from simultaneous calls, calls per second, bursts, codec bandwidth, IP-interface capacity, PBX or SBC resources and measured performance. Use the order and an approved load plan for numeric acceptance.
Emergency calling
Not verifiedThe reviewed SIP-trunk pages do not publish the selected service's emergency-calling model, dispatchable-location workflow, callback identity, nomadic-user handling, test process or outage behavior. Eastlink's Teams page says emergency phones and other ancillary cases may be delivered through separate hosted wireline voice services; that is a design warning, not proof that an ordinary trunk or Teams user has the required emergency path. Obtain the order-specific record and maintain an independent means of calling emergency services.
Pricing model
Not verifiedThe reviewed pages do not publish a complete selected-account price. Bind channels, numbers, fibre or Internet access, installation, PBX or SBC work, Direct Routing, continuity, long distance, emergency service, support, taxes, fees, term, renewal and termination to a dated quote, contract and bill rather than a general savings claim.
Administration and support
Not verifiedEastlink describes engineering, implementation and support involvement and says channel changes can be requested by email or phone. Its public SIP page lists current contact hours, while the Teams page separately describes 24/7/365 support for that programme. Neither establishes one trunk's portal roles, monitoring, change controls, escalation path, response target or service-credit process. Preserve the current support schedule, accepted changes, tickets and timestamps from the order and support record.
SMS and MMS
Not verifiedThe general Business Phone page describes SIP as capable of calls, messaging and video, but the reviewed Eastlink SIP-trunk record does not establish SMS or MMS entitlement on trunk numbers, sender registration, API access, throughput, webhook security, retention or price. Treat messaging as a separate service and workflow unless the order and current technical documentation say otherwise.
Keep channels, calls and interface scale separate
The product page says SIP scales to hundreds of channels on one IP interface and that channels can be added or removed. That portfolio-scale statement does not establish the selected account's ordered channels, simultaneous-call allocation, calls per second, bursts, codec bandwidth, interface headroom or PBX and SBC resources.
Use the order and an approved load plan for numeric acceptance. A channel count is not a measurement of busy-hour demand, call-start behavior, access diversity or emergency capacity.
Do not turn fibre and multiple locations into automatic failover
Eastlink says channels can extend over IP networks to multiple locations and describes facilities-based fibre as a continuity benefit. The Microsoft Teams service separately uses redundant hosted certified SBCs. Multi-location reach, redundant provider SBCs and diverse customer access are distinct failure domains.
Record ingress and egress peers, route priority, customer-access paths, trigger, timers, alternate destination, established-call outcome and restoration order for the selected design. Exercise only an approved new-call failure case; a general reliability statement is not accepted failover evidence.
Keep ordinary PBX trunks and Microsoft Teams paths distinct
Eastlink's Direct Routing service connects Microsoft Teams through hosted Microsoft-certified SBCs and can integrate legacy alarm, elevator and fax cases using supporting voice services. Operator Connect is a separate service model. None of those details defines the registrar, credential, proxy, transport, media route or licensing for an ordinary PBX trunk.
Map the actual call path and ownership for the PBX or Microsoft tenant, SBCs, numbers, identity, media, legacy devices and support. Do not copy a Direct Routing assumption into a PBX trunk or treat a provider-hosted SBC as proof of customer-site, tenant or access resilience.
Resolve emergency and legacy-device design before migration
The public SIP pages do not publish a complete emergency-calling model, dispatchable-location workflow, callback identity, nomadic-user handling, test method or outage behavior. Eastlink's Teams page says emergency phones and other ancillary cases may require separate hosted wireline voice services. That is an explicit design boundary, not evidence that every SIP or Teams endpoint has an accepted emergency path.
Obtain the order-specific emergency record, map every fixed and nomadic location to the required number and service, coordinate any permitted test, and retain an independent means of reaching emergency services. Treat fax, elevator, alarm and other non-voice devices as separate acceptance workflows.
Close technical and commercial gaps from account records
The reviewed public records do not define a complete authentication or registration profile, number delivery, codecs, DTMF, fax transport, TLS and SRTP parameters, messaging interface, exact call-start limits, serviceability or account price. Engineering and support claims do not fill those fields.
Bind signaling, media, security, numbers, access, installation, continuity, legacy devices, emergency service, support, taxes, fees, term and termination to the current order, technical handoff and bill. A capability described on a public page is not proof that it is ordered, configured, available or compatible.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.