Identify the exact GTT voice product and handoff
GTT presents its core SIP Trunking service for customer PBXs or cloud phone systems and separately presents Cloud Phone Direct connections for Microsoft Teams, Cisco Webex Calling and Zoom Phone, plus a Google SIP Link offer. Preserve the legal product name, countries, sites, phone systems, number inventory, access network, ordered sessions, implementation worksheet and support owner. A Cloud Phone Direct or Google integration statement is not a generic PBX configuration or an entitlement on every SIP Trunking order.
Record which party owns the PBX or tenant, SBC, public addressing, firewall, DNS, number port, emergency location and change window. GTT says it coordinates migration and integration, but the accepted design and handover record must define the actual demarcation for the account.
Documented service facts
Reviewed 2026-10-06. Compare SIP trunk services →
Authentication
Not verifiedThe reviewed public GTT product and data-sheet material does not publish one generic PBX authentication template. Obtain the ordered peer addresses, source-address policy, digest or certificate requirements, ports and identity rules from the current implementation worksheet; do not copy a Cloud Phone Direct or Google handoff into a core PBX trunk.
SIP registration
Not verifiedThe reviewed sources do not establish SIP REGISTER as a universal requirement or inbound-binding mechanism. Record the exact ordered service and handoff before treating an absent registration object as either healthy or failed.
Inbound delivery
DocumentedGTT describes core SIP Trunking plus distinct Cloud Phone Direct and Google SIP Link integrations. Its data sheet says numbers can be activated or migrated and describes assigned or ported numbers for named cloud-phone paths. The current order must still define the trunk group, destination, number format, identity treatment and customer acceptance result.
Inbound failover
DocumentedGTT advertises automatic failover routing, disaster-recovery architecture and globally deployed SBCs. The public sources do not define one account's health input, response or timeout trigger, destination order, restoration rule or last-resort behavior. Treat these as new-call controls until an authorized design proves otherwise; they do not establish survival of an active dialog.
Number and regional availability
DocumentedThe 2026 GTT data sheet says new or existing geographic numbers can be activated or migrated in more than forty countries and describes global termination and cloud-phone integrations. That portfolio claim is not proof that a requested number type, address, port, regulatory feature or emergency workflow is available; verify the exact country and order.
Audio codecs
Not verifiedThe reviewed public sources describe voice delivery over GTT's backbone but do not publish a universal PBX codec, packetization, DTMF or transcoding profile. Preserve the current service worksheet and actual offer/answer for every route rather than inferring media support from a completed call or cloud-platform integration.
T.38 fax
Not verifiedThe reviewed GTT trunk and cloud-phone sources do not establish T.38, fax-over-audio or error-correction behavior for a general order. Qualify the exact number, direction, endpoint, media path and page profile before relying on fax.
Signaling and media encryption
Not verifiedGTT describes private protected IP connectivity, global SBCs and pre-established secure connections for named cloud platforms. Those statements do not define TLS, certificate validation, SRTP, keying, public-internet exposure or end-to-end protection for a core customer-PBX trunk. Confirm every signaling and media leg separately.
Concurrent calls and call starts
DocumentedGTT says its design process plans concurrent call sessions and that sessions can be pooled across an organization. Pooling does not prove that every country, site or service shares one unrestricted bucket, and the reviewed sources do not publish a generic calls-per-second value. Preserve ordered concurrency, eligibility, call starts, PBX channels and observed rejections as separate controls.
Emergency calling
Not verifiedGTT lists emergency services for named Cloud Phone Direct and Google SIP Link portfolios, but the reviewed sources do not define a universal core-trunk address workflow, accepted caller identity, callback route or approved test procedure. Bind emergency evidence to the exact product, country, number and physical location.
Pricing model
Not verifiedThe reviewed public sources make cost and consolidation claims but do not provide a current quote or complete fee schedule. Obtain dated terms for sessions, call starts, numbers, usage, access, cloud-platform integration, emergency service, porting, support, commitments, taxes, renewal and cancellation.
Administration and support
DocumentedGTT describes a centralized service with design, deployment and ongoing optimization steps. Public workflow language does not establish portal roles, change lead times, monitoring coverage, retention, support priority or restoration objectives for one account. Preserve the implementation worksheet, accepted configuration and escalation ownership.
SMS and MMS
Not verifiedThe reviewed GTT SIP Trunking, Cloud Phone Direct and Google SIP Link sources do not establish SMS or MMS entitlement on trunk-assigned numbers. Verify number capability, sender registration, consent, application path, throughput, retention and fees independently.
Keep network transport, SIP identity and authorization separate
GTT describes voice traffic using its global Tier 1 IP backbone and says SIP Trunking can integrate with SD-WAN, MPLS or Internet services. Those access choices do not by themselves define the SIP peer, source-address policy, registrar, digest credentials, certificates, transport, ports, Contact behavior or media addresses for a particular order. Copy those values only from the current implementation worksheet.
For each direction, distinguish network reachability, SIP endpoint identification, request authorization, number assignment, route selection, final response and usable media. Do not infer SIP REGISTER, source-IP authentication, TLS, SRTP or end-to-end private routing from broad security or protected-connectivity language.
Treat pooled sessions as one capacity input
GTT says sessions can be pooled across an organization and that its design process plans concurrent call sessions. Preserve the ordered pool, location or service eligibility, active calls, call-start rate, PBX channels, licences, bandwidth, codec packetization and observed rejection as separate quantities. Pooling language does not prove that every site or country shares one unrestricted capacity bucket.
Establish the accounting boundary for transfers, conferences, forwarded calls and cloud-platform legs before sizing. A successful call does not prove the purchased session ceiling, and a portal or order value does not establish the PBX or access network's usable capacity.
Decompose automatic failover and disaster recovery
GTT advertises automatic failover routing, disaster-recovery architecture and globally deployed session border controllers. For the ordered design, document the normal destination, alternates, health input, SIP response or timeout trigger, route order, retry interval, restoration rule and failure domains. Separate provider-edge redundancy, customer access, PBX or cloud-tenant availability, alternate destination routing and number forwarding.
Treat these as new-call controls until an authorized case proves otherwise. They do not establish independent power, internet, firewall, DNS, PBX or downstream carrier paths and do not promise survival of an established dialog. Retain timestamps and provider correlation identifiers for rejected, unanswered and unreachable cases.
Bind numbers, cloud platforms and emergency service to locations
GTT describes number porting and assigned or ported numbers for several cloud-phone integrations. It also lists emergency services in those integration portfolios. Keep order acceptance, number inventory, port completion, inbound route, outbound identity permission, physical emergency address, callback route and provider-approved non-live test record together for each country and site.
Do not transfer a Cloud Phone Direct or Google SIP Link emergency statement to an ordinary PBX trunk without the account design. Likewise, number portability and service coverage are regulatory and location-sensitive; a global product page is not proof that one number type, feature or emergency workflow is available at a requested address.
Resolve media, operations and commercial unknowns before acceptance
Require the current design to define codecs, packetization, DTMF, fax, signaling and media protection, media anchoring, concurrency, call-start limits, monitoring, records, alarms, escalation, maintenance and rollback. Keep a completed SIP exchange, received RTP, decoded audio and conversational acceptance separate.
Obtain dated terms for activation, sessions, usage, numbers, porting, emergency service, support, access connectivity, commitments, renewal and cancellation. Public claims about scale, savings, quality or global reach are not a quote, serviceability result or measured outcome. No account, order, country, number, PBX, cloud-phone tenant, connection, trunk, route, call, media path, failover, emergency workflow, session pool, price, availability, compatibility or support response was tested for this guide.
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.