Identify the ordered Granite service and agreement
Start with the active agreement, accepted service order, customer, service location, Granite legal entity or affiliate, start date, on-net or off-net scope, underlying provider when applicable, support entitlement and service form. The current product page lists Business SIP Trunks, Direct Routing and Emulated PRI; the VoIP terms separately define SIP Trunking, Hosted PBX, SIP PRI, Hosted Voice, Virtual Auto Attendant and Virtual Voicemail. Do not collapse those products into one configuration.
The legal index describes the agreement as a set of general terms, service-specific terms, service-order documents and applicable tariffs. Preserve the controlling documents and effective dates rather than inferring entitlement from a product page.
Documented service facts
Reviewed 2026-10-30. Compare SIP trunk services →
SIP authentication
Not verifiedPublic records do not publish one universal registration, source-address, username, password, realm, certificate or managed-edge identity model. The current order and implementation record govern.
SIP registration
Not verifiedSIP Trunking and SIP PRI are defined, but public records do not establish whether one order registers, peers by address, uses provider equipment or combines controls.
Telephone numbers and inbound calling
DocumentedSIP trunking, toll-free and call-path features are documented. Number order, port, provider attempt, delivered value, PBX route and answer remain unverified.
DTFO and redundancy
DocumentedDTFO and redundant-solution language are published. Entitlement, trigger, alternate target, access survival, alternate answer, established-call continuity and restoration remain order- and observation-specific.
Service form and handoff
DocumentedBusiness SIP Trunks, Direct Routing and Emulated PRI are listed, while the VoIP terms distinguish other service families. The accepted order, site, access, demarcation and loaded handoff govern.
Codecs and media
Not verifiedReviewed public records do not establish one universal codec, packetization, DTMF, encryption, transcoding or media-range policy. SDP, packets, decoding and audibility remain unverified.
Fax and analog behavior
Not verifiedEmulated PRI is listed, but reviewed SIP records do not establish T.38, passthrough, fallback, analog adapter behavior or completed-page results for one order.
Credential and equipment custody
Not verifiedTerms distinguish Granite or provider equipment from customer equipment. Exact authentication, certificates, encryption, ACLs and credential custody remain implementation-specific.
Base call paths and bursting
DocumentedBursting and optional usage bundles are listed. Purchased base paths, burst entitlement and ceiling, active dialogs, attempts, PBX limits, network demand and completed calls remain separate.
E911 location and notifications
Documented911 outbound notifications and additional E911 registration are listed; a Canadian VoIP 911 notice is separately published. Jurisdiction, registered location, callback, notifications, PBX route and approved validation remain order-specific.
Price and availability
Not verifiedThe legacy brief contains old price figures that are not current quotes. Service form, access, call paths, bursting, numbers, DTFO, usage, equipment, support, taxes, term, serviceability and activation remain order-specific.
Portal, SLA and support
DocumentedCustomer portals and a VoIP SLA are published. Portal rows, on-net or off-net scope, tickets, response objectives, findings, actions, service credits and verified restoration remain separate evidence.
SMS and MMS
Not verifiedReviewed SIP trunk records do not establish SMS or MMS eligibility, sender registration, consent, throughput, retention or pricing for trunk numbers.
Separate handoff, access and loaded edge state
Record the ordered handoff, access service, demarcation, service location, customer equipment, Granite or provider equipment, PBX or SBC, signaling target, identification or authentication method, telephone numbers and support owner from implementation records. Compare those facts with the objects actually loaded and the network path actually selected.
The public sources do not establish one universal registrar, proxy, realm, username, password, source-address rule, transport, certificate, codec or media range. A reachable portal, access link or provider device does not prove that the intended trunk, route, SDP or media path is working.
Keep base call paths, bursting and completed calls distinct
The current product page lists bursting as a feature. Preserve purchased base call paths, burst entitlement, burst ceiling or policy, usage interval, active dialogs, offered attempts, PBX resources, access demand, provider responses, destination responses and completed calls as different quantities. Confirm how the active order describes usage bundles and bursting before planning load or overflow.
A burst feature does not establish unbounded concurrency, PBX capacity, network readiness, destination acceptance or a completed call. Do not create production load merely to discover an undocumented limit.
Bound DTFO and redundancy to the ordered design
The current product page lists DTFO, or Direct Trunk Failover, and describes a fully redundant IP voice solution. Record the ordered DTFO option, protected number block or trunk, documented trigger, alternate target, activation owner, last review, test authorization and rollback.
Feature and design language do not prove that DTFO is ordered, loaded, triggered or observed. An alternate inbound answer does not establish outbound rerouting, access survival, established-call continuity, alternate-site readiness, media quality or primary-path restoration.
Preserve number and E911 evidence by jurisdiction
The product page lists 911 outbound call notifications and additional E911 registration. Keep the applicable order, registered location, callback number, notification recipients, validation or effective time, PBX emergency route, access and power dependencies, provider-approved non-live validation and any exception separately.
The Canadian VoIP 911 notice is jurisdiction-specific. Do not transfer its procedures to a US order or treat a portal address as proof that an emergency record is accepted, routed, current or operational. Do not place an uncoordinated live emergency call as a test.
Treat the SLA as scope and remedy evidence
The VoIP SLA names SIP Trunking among covered VoIP services, distinguishes on-net and off-net scope, defines Level 1 and Level 2 events, response objectives, exclusions and potential service credits. Preserve the applicable service object, activation date, affected call path or number, ticket-open time, severity, provider response, finding, action, restoration time, exclusions and credit request independently.
A response objective is not a repair promise. A ticket, response, service credit or shipped replacement does not prove root cause, restoration, recurring stability or what callers experienced.
Keep legacy claims and current evidence labeled
The legacy SIP Trunking brief describes older product positioning, PBX categories and price figures. Retain it only as dated historical scope evidence. Do not use its price table as a current quote or its compatibility wording as approval for a current PBX, gateway, firmware, topology or feature.
Use the current order, current technical handoff, current service terms and an authorized proof plan for deployment decisions. Record portal inventory, case, provider finding, change and bounded ordinary-call retest as separate evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Granite — VoIP & Cloud Phone Systems ↗
- Granite — SIP Trunking brief (legacy, date-scoped) ↗
- Granite — Legal & Policy ↗
- Granite — General Terms of Service (May 2026) ↗
- Granite — VoIP Services Additional Terms and Conditions of Service ↗
- Granite — VoIP Services Service Level Agreement ↗
- Granite — Canadian VoIP 911 English ↗
- Granite — Resources and customer portals ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.