| Outbound authentication | Documented Termination requires the personal Termination SIP URI plus at least an IP Access Control List or Credential List. When both are configured, both are enforced; an attached Credential List produces a 407 challenge before the authenticated retry. | Documented Documented methods include credentials, IP plus token, IP plus tech prefix, IP plus P-Charge-Info, FQDN plus credentials and FQDN plus IP. FQDN handles inbound delivery while outbound authentication still uses credentials or source IP. | Documented IP authentication identifies outbound traffic by the configured public source address. Credential registration is a separate, PBX-only mode that the provider does not place under the same SLA treatment. | Documented Subaccounts can use username/password or IP authentication. IP-authenticated subaccounts do not display registration status in the portal, so the indicator cannot diagnose that path. | Documented Flowroute documents credential registration and static source-IP authentication as separate outbound choices. Preserve direction, selected PoP, approved source, egress address and Tech Prefix where applicable; neither choice assigns an inbound DID route. | Documented Outbound Credentials & IP-Based authentication combines a matching source range with SIP Digest using realm out.didww.com. IP-Only is support-enabled. Authentication remains separate from allowed Caller IDs and destinations. | Documented Outbound trunks accept an IP access-control list, username/password credentials, or both. These controls authenticate INVITEs sent by customer infrastructure; they do not create a registrar binding. | Documented A project-scoped SIP Credential supplies the registration username and password and selects profile-default, passthrough, block-PSTN or resource handling. API project credentials manage resources and are not the SIP registration secret; preserve both without exposing either. | Documented Build outbound SIP uses credentials bound to an exact generated realm hostname. Voice IP whitelists are separate source controls and do not replace the documented digest path. | Documented Current Voice API static-trunk termination authenticates with the application key, application secret and selected regional realm. REST and callback request authentication are separate controls, and the Numbers API uses different credentials. | Documented The current SIP Dashboard documentation supports digest authentication and/or an IP Access Control List. Digest uses a trunk user key and a 12-to-64-character password meeting the documented character-class rules; those trunk credentials are separate from the account API key and secret. | Documented Each trunk uses either digest registration credentials or IP authentication bound to one configured static public address and port. The modes are mutually exclusive; enabling IP authentication can cause REGISTER from that public address to be ignored in favor of the IP-authenticated trunk. | Documented Voxtelesys documents registrar credentials and a separate static-IP model. Registration ACLs can restrict credentialed REGISTER attempts to listed source addresses; the selected mode and route destination remain separate controls. | Documented Termination settings can combine publicly routable source CIDR allowlisting with SIP username/password credentials. The selected calling plan and caller-ID policy are separate controls; record the exact enabled combination instead of treating AWS account credentials as SIP credentials. | Documented Outbound call-termination trunks use source-IP authentication; each can have an authorized address and LCR controls. This outbound identity does not establish a DID destination, inbound attempt or media path. | Documented didlogic documents digest username/password registration and a separate source-IP authentication model. The selected mode, optional SIP-account IP restriction and purchased-number destination remain different controls. | Documented Outbound source-IP authentication uses portal host entries and the translated public source address. Credential mode uses a trunk-group username and password for digest authentication. Current first-party examples show that inbound and outbound directions can use different identity owners. | Documented Voxbeam's current getting-started page documents outbound authorization by customer public source IP entered in account Settings. Preserve the intended account, saved address, actually translated egress source, DNS-selected provider target and first response; these are separate observations. | Documented Callcentric assigns a 1777 account number and per-extension SIP password. The published proxy, realm and registrar are sip.callcentric.net on port 5060. Record the exact extension identity; SIP digest credentials authenticate requests but do not encrypt signaling or media. | Documented AVOXI documents one authentication type per individual outbound trunk: Basic credentials, authorized source IP, SIP-header authentication or the documented number option. Preserve the effective selection and redact reusable values; outbound authorization does not establish inbound number routing. | Not verified The legacy portal workflow assigns each Location or SubLocation a SIP username and password, while the FreePBX module uses a separate keycode to pair the PBX with a Location. These values have different owners and must be confirmed in the current portal because the source knowledge base now says it is no longer updated. | Not verified The public pages expose outbound permission and caller-ID controls but do not establish digest, source-IP or another universal trunk-authentication method. Use the current account handoff. | Documented SIPTRUNK documents credential registration and a separate static-IP authentication mode. Record the selected trunk path; an absent REGISTER is a fault for the credential path but can be expected for an IP-authenticated trunk. | Documented CarrierX documents IP authorization, proxy authentication and a clear-text header-token alternative for outbound calls. Preserve the exact method and remove reusable tokens from shared traces; outbound authorization does not establish inbound DID assignment. | Documented Outbound trunks authorize the observed public source IP and can use an optional four-digit Request-URI prefix. Portal propagation and actual acceptance remain separate evidence. | Documented SIPStation supplies service-specific SIP credentials and a SIPStation account key used by its FreePBX module. Those values are distinct from store credentials. Treat the module key, SIP username and SIP password as separate secrets; a credential reset requires the new keycode on the PBX and can interrupt both directions until the configuration is updated. | Documented Wavix documents Digest authentication using the generated trunk ID and password, and IP Authentication using a dedicated static address after manual approval. Preserve the selected method and its current owner. | Documented Infobip documents static trunks authenticated by declared public dedicated source IPs and registered trunks authenticated by username and password. A separate authenticated-trunk type uses DIGEST credentials and an X-IB-AccessCode header for selected external platforms. Record the ordered trunk type and credential owner; these models are not interchangeable. | Documented Zadarma documents credential registration and a separate trunk authorized by one or more confirmed static source addresses. Enabling the IP-authorized trunk consumes a selected SIP login as its identifier and makes that login unavailable for registration. Preserve one intended model and its owner. | Documented DIDforSale documents portal-approved IP or FQDN interconnection and a separately activated SIP account with domain, username and password. Preserve one intended model and its owner. For IP interconnection, outbound termination must be enabled on the portal record. | Documented ThinkTel documents IP authorization against the pilot's configured binding and digest authentication for SIP requests requiring authorization. A wrong source can receive 403 and an absent or wrong digest can receive 401. Preserve binding, realm and challenge evidence without publishing secrets. | Documented Current Sangoma wholesale and FreePBX procedures document source-IP identification with no trunk authentication object: the customer endpoint group and approved addresses define the service boundary. Preserve the assigned account addresses and provider signaling set; do not copy example IP addresses as permanent account data. | Documented GoTrunk documents direction-specific endpoint choices. A static public source can authorize outbound traffic, while credential mode generates username and password values. Inbound can also use a configured static SIP URI or credentials and registration. Preserve endpoint, direction, selected model, observed source and first response. | Not verified Lumen's public service and portal pages describe service IDs, locations, trunks and route plans, but the reviewed pages do not establish one universal customer-PBX authentication method. Preserve the exact SONUS- or Broadsoft-based service, provider interop profile, source addresses and any redacted credentials separately; do not infer source-IP, digest or certificate identity from the portal object alone. | Documented The September 2024 implementation guide separates static-public-IP service from credentialed registration. It says dynamic-public-IP PBXs require registration using the assigned username and password, while a static-public-IP PBX does not need to register. Preserve public-address ownership, source authorization, credentials and the selected service model separately. | Conflicting documentation The general SIP configuration guide requires an account username and password against the assigned domain. Separate IPComms pages for Zoom, Webex Contact Center, Teams and a 3CX deployment describe IP-authorized or SBC-mediated paths. Preserve the exact ordered service, portal worksheet and authentication model; do not transfer a specialized integration's identity method to the general trunk. | Documented Hosted outbound can answer a 401 digest challenge without a REGISTER, while Hosted inbound requires a current registration. Keep outbound authorization, registration and Carrier, Wholesale, Partner or Direct account models separate. | Not verified The Local terms describe routing to a customer IP address, but the reviewed public sources do not publish one universal registrar, credential, source-IP, SBC, transport or certificate contract. Use the accepted implementation handoff; an IP-address reference is not proof of IP-only authentication. | Documented Colt's February 10, 2025 external technical guide defines VoIP Access as a static-mode trunk between fixed Colt SBC and customer IP-PBX addresses. That establishes an address-bound service model, not permission to accept arbitrary traffic. Preserve the implementation worksheet, assigned SBC pair, customer source addresses, access type, ACLs and any mutually authenticated TLS certificates; confirm the exact current order because partner-delivered Global SIP features may differ. | Not verified The public page establishes internet or private-circuit access but does not publish one universal registrar, credential, fixed-source policy, SBC list, transport or port set. Build from the dated Gamma or partner handover and verify assigned peers and customer addresses. | Documented 8x8's published interface specification requires signaling from a pre-registered static public IP address and challenges outbound INVITE requests with SIP digest authentication. Both controls belong to the documented interface: a permitted source address alone does not prove the credentials, Request-URI or calling identity are accepted. Obtain the current Professional Services handover because the specification is historical and X Series changes are support-managed. | Not verified Bell's reviewed public product, portal and support material does not define the production SIP peer-authentication model, credentials, source-address controls or trust handover for an ordered trunk. Obtain the exact implementation worksheet and keep network reachability, endpoint identification, authentication and accepted calling identity as separate evidence states. | Documented Outbound SIP authorization uses an allowed source address and/or digest credentials. The REST management API instead uses an API key and token over HTTPS. These identities, the account domain and the final SIP response remain separate evidence. | Documented Nextiva onboarding supplies a pilot user or number, authentication name, authentication password and domain after a support case. Preserve those fields separately and do not substitute a hosted-seat login or a number from another PBX. | Not verified The reviewed public trunk pages do not define one account's source-IP or digest-authentication contract, credential lifecycle or accepted outbound identities. Obtain the current implementation record and preserve secrets outside shared traces. | Not verified The public one-sheet advertises static and registered trunks but does not define one order's source-address or digest-authentication contract, credential lifecycle, accepted outbound identities or whether the methods can be combined. Obtain the current implementation worksheet and keep secrets out of shared traces. | Not verified The 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. | Not verified The current service-schedule addenda distinguish private MPLS, dedicated-IP and public-IP access, but the reviewed public sources do not define a universal SIP digest, certificate or source-address authentication procedure. Obtain the exact handoff, permitted peers and SBC policy from the order before selecting a PBX template. | Documented The current technical specification describes a Spectrum-managed Enterprise SIP Gateway at the customer site and a static SIP interface with optional authentication. Preserve the ordered gateway, PBX or SBC peer, addressing and authentication setting separately; the public page does not disclose a universal username, secret lifecycle or source-address policy. | Not verified The API key and environment-specific API secret authorize HTTPS management calls; they are not SIP credentials. The reviewed public sources still do not publish one universal outbound digest realm, registrar, secret lifecycle or source-address rule. Preserve API and SIP trust as separate account records. | Not verified The reviewed portal and trunk-management material does not publish one universal SIP digest realm, credential lifecycle, mutual-certificate procedure or source-IP authorization rule. Portal and API login controls are management credentials, not evidence of how the ordered SIP trunk identifies a PBX. Obtain the trunk order and turn-up record. | Not verified The reviewed public material does not publish one universal digest realm, credential lifecycle, mutual-certificate procedure or source-address authorization rule. Private access, over-the-top access, Microsoft Teams Direct Routing and Webex SIP trunks are named deployment options, not one shared PBX authentication template. Obtain the current implementation worksheet. | Documented Cox-hosted Asterisk 1.8.7 and Avaya IP Office guides describe digest credentials based on a trunk-group pilot number plus a provider-issued secret. They are old, PBX-specific reference configurations, not a current universal credential contract. Obtain the implementation worksheet and protect the supplied secret; never copy example values. | Not verified The reviewed public product page, welcome kit and service guide do not publish one customer-facing digest credential, mutual-TLS identity or source-address rule for every IP Trunking order. Verizon says configuration data is supplied after its service configuration is complete. Obtain the implementation worksheet and protect credentials and peer addresses; do not infer authentication from use of Verizon access. | Not verified The reviewed public sources do not publish one digest credential, certificate identity or source-address policy for every Rogers Business SIP Trunking order. The schedule refers to confidential access codes or passwords but does not define a universal PBX-facing authentication flow. Obtain the current implementation record and protect credentials and peer addresses. | Documented Fusion Connect says call initiation requires both SIP credentials and a customer-assigned specific IP address. That documents a two-condition provider policy, not certificate-based mutual TLS, universal source ranges or proof that an observed request was authorized. Preserve the issued credential object, accepted source address, NAT or SBC ownership and provider confirmation for the exact trunk. | Not verified The reviewed public product, datasheet, feature and legal pages do not publish one universal digest, source-IP, mutual-TLS or certificate-authentication model. Obtain the implementation record for the exact order and preserve realms, credentials, accepted addresses, SBC ownership and secret-handling policy without exposing secrets. | Documented sipgate describes the entire PBX registering for trunk communication rather than each handset. Treat the trunk's SIP ID, password, registrar realm and authorized caller identities as separate secrets and policies. The reviewed public pages do not establish source-IP authentication as a substitute for registration. | Not verified The reviewed public service schedules define access and management boundaries but do not publish one universal customer authentication profile. Preserve the ordered service version, Site, interconnect, source addresses, credentials or certificates, SBC policy and observed authorization result; do not infer registration or IP authentication from the product name. | Not verified HKT's public product page does not publish a universal registration, credential, certificate or source-address authentication profile. Obtain the implementation record for the ordered circuit and preserve the PBX or SBC object, peer addresses, credentials or certificates and observed authorization exchange. | Documented Gradwell's current guide says a deployment may use IP whitelisting or username and password, while its fraud guide describes IP authentication as a protection. The public pages do not establish which method applies to every product or order. Preserve the issued server, source addresses, identities, credentials and observed challenge or source-address decision for the exact trunk. | Documented VoiceHost's current how-to collection describes supplied authentication IDs or usernames and passwords, registrar and proxy values for specific PBX configurations. Preserve the exact portal-issued realm, identities, secret owner, source-address rules and observed challenge exchange; an old vendor template is not a universal current trunk profile. | Not verified The reviewed public AT&T pages do not define the selected trunk's authentication mode, SIP realm, credential ownership, source-address controls or mutual-authentication behavior. Preserve the signed order, implementation record, provider-issued interface profile and observed challenge or source validation without exposing secrets. | Documented Voipfone’s Asterisk and FreePBX examples use an account number and password at sip.voipfone.net. The account number is not one of the account’s telephone numbers; preserve authentication, number and routing identities separately. | Documented CompanyFlex uses an assigned registration identity and the current trunk credentials and proxy details. 1TR119 defines the interface behavior, but the current Business Service Portal and provider handoff govern the actual values. Preserve the issued registration number, domain, primary and secondary route data, secret owner and observed authorization exchange without copying another account or legacy DeutschlandLAN template. | Not verified Iristel 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. | Not verified The reviewed TELUS pages and R4 terms do not define one account credential or source-address authentication method, digest profile or certificate role. Preserve the current order, handoff, required IP addresses and observed exchange without publishing secrets. | Not verified The reviewed SaskTel product and tariff records do not define one selected trunk credential, source-address authentication method, digest realm, certificate role or allowlist. Preserve the accepted implementation handoff and observed exchange without exposing secrets. | Not verified Cogeco describes private access and a supplied eSBC but does not publish one selected trunk credential, source-address policy, digest realm, certificate role or mutual-authentication method. Preserve the accepted handoff and observed exchange without exposing secrets. | Not verified The reviewed public product page, July 2026 terms and general guide do not define whether the selected trunk authenticates by source address, SIP digest credentials, certificate or a combination, nor do they publish a realm, digest algorithms or allowlist. Obtain the accepted implementation record and map each secret, address and certificate to its PBX, SBC and provider owner without exposing reusable credentials. | Not verified Comcast says the managed service uses two layers of authentication, but the reviewed public records do not define the selected PBX handoff's mechanisms, trusted addresses, credentials, digest parameters, certificate roles or ownership. Obtain the accepted implementation record and map each control to the Comcast equipment, PBX or SBC without exposing reusable values. | Not verified Eastlink'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. | Documented Enabling Hosted Trunking creates authentication information for the selected user. Preserve the account-generated username, authentication username, domain and secret owner; the public example does not establish a universal current digest, rotation, source-address, transport or certificate contract. | Documented sipgate's current Asterisk example uses a personal SIP ID and SIP password for outbound authentication and registration. The example does not establish the production account's digest realm, algorithms, secret-rotation process, source-address restrictions or permitted concurrent registrations. Obtain the current trunk record, keep credentials out of tickets and captures, and validate a sanitized challenge and response. | Documented Webex Calling documents registration-based and certificate-based trunks between the service and the premises local gateway. The registration model gives the local gateway a registration domain, trunk group, line or port and outbound proxy; losing credentials requires regeneration. Do not merge that handoff with a certificate trunk or with the separate Cloud Connected PSTN provider account. Preserve the selected trunk type, gateway, identity, secret or certificate owner and sanitized exchange. | Documented Direct Routing pairs a tenant-configured PSTN gateway with a public SBC FQDN in a verified Microsoft 365 domain and uses a publicly trusted certificate for TLS. That is not a digest username and password, a generic SIP-provider login or proof that the selected carrier authorized the other side of the SBC. Preserve the tenant, gateway object, exact SBC identity, certificate chain and carrier-side trust separately. | Documented Google documents mutual TLS between the certified SBC and SIP Link plus a unique X-Google-Pbx-Trunk-Secret-Key header. The SBC certificate common name must use its fully qualified domain name and a domain matching the Workspace domain; wildcard certificates are not supported. Keep certificate trust, private-key custody and trunk-secret rotation as separate controls. | Documented Internet peering uses mutual TLS between Zoom and the customer SBC. Zoom requires a public certificate from a supported CA, Server Authentication key usage, the complete chain and the SBC FQDN in CN or SAN; the current infrastructure page also says Zoom does not perform expected-hostname peer-name validation on the customer SBC certificate. Keep certificate trust, presented identity, private-key custody, permitted source addresses and carrier-side authentication as distinct controls. | Not verified RingCentral's public service description identifies a customer-owned gateway between the local carrier and RingEX, while the support page says an account manager enables BYOC parameters and adds or changes gateways. The reviewed public pages do not define one universal source-address, digest, certificate, realm or mutual-trust profile. Preserve the approved design, exact gateway, each peer, certificate or secret owner and a sanitized successful exchange without copying another carrier or country configuration. | Documented BYOC Cloud uses an external trunk to a third-party carrier service or device. Source addresses, the region-specific inbound termination identifier and, for TLS, public-CA certificate trust are separate controls. The reviewed material does not establish one universal digest username, realm or secret for every carrier. Preserve the exact trunk type, Voice platform, peer list, access-control policy and certificate behavior rather than copying another organization or region. | Documented The Azure-facing peer is a provisioned, supported SBC identified by a public FQDN and paired with one Communication Services resource. Microsoft requires a publicly trusted certificate with the SBC FQDN in CN or SAN and Server Authentication EKU. This is not a generic digest-registration service. Preserve domain ownership, resource pairing, certificate identity, private-key custody, carrier-facing authentication and application access tokens as separate controls. | Not verified Pure IP publicly describes Internet-based SIP trunking, cloud SIP infrastructure and managed or dedicated SBC options, but the reviewed public pages do not define one universal source-IP, digest, certificate or registration identity for every service. Treat the order, implementation handoff and loaded peer configuration as authoritative; keep a portal login separate from a SIP credential. | Not verified The reviewed public Enterprise pages do not define one universal source-IP, digest, certificate or other SIP identity for every order. Use the selected implementation handoff and loaded peer; keep an account login separate from a SIP credential. | Documented Easybell exposes inbound and outbound identity choices separately. Inbound SIP-password mode uses registration credentials; inbound IP mode ignores credentials and sends calls to stored public static addresses; trusted FQDN uses a DNS-backed domain. Preserve the effective directional mode and actual provider attempt. | Documented Outbound calls can be authorized by one or more approved public PBX addresses, optionally with username and password. Inbound delivery separately identifies requests by the dialled number or a configured trunk username. Preserve direction, portal object, source, delivered identity, challenge and observed result. | Not verified Voiceflex describes connecting a PBX to its SIP service, but the reviewed public pages do not establish one registration, digest-credential or source-IP authentication method for every order. Obtain the current provisioning sheet and record direction, SIP identity, authorization identity, source address or FQDN, challenge and observed response without treating the methods as interchangeable. | Not verified Spitfire describes connecting an existing phone system to its SIP network, but the reviewed public documents do not define one registration, digest-credential or source-IP authentication method for every order. Obtain the current provisioning sheet and record direction, SIP identity, authorization identity, source address or FQDN, challenge and observed response without treating the methods as interchangeable. | Documented 2talk publishes registration credentials for both its Lyra and Plus platforms: the number as login and authorization identity, with a password configured for that number. The security guidance also distinguishes registration from IP peering. Confirm the account platform and ordered trunk before choosing either pattern, and do not expose a PBX or management interface to the public internet merely to make registration work. | Documented peoplefone documents a SIP proxy, SIP username and SIP password for each SIP line, and explicitly separates those credentials from the customer-account login. Record the selected Swiss account, SIP line, proxy, user and challenge without exposing the secret. A portal login or visible line is not evidence that the PBX authenticated. | Documented A&A documents number-based SIP accounts using the full international-format number, a per-number SIP password and voiceless.aa.net.uk. For provider delivery to a customer server, the customer separately supplies the credentials that server expects. Keep outbound registration authentication and inbound server authentication as different directions and do not expose either secret. | Documented Zen documents Digest authentication and says the selected SIP Trunking details are available in its Customer Portal. Record the account, SIP identity, authorization identity, realm, challenge and result without exposing the secret. A visible portal record or configured password is not proof that the PBX authenticated. | Not verified SureVoIP publishes account password obligations and device setup material, but the reviewed current public pages do not define one authentication contract for every outbound trunk or fixed-IP inbound destination. Obtain the selected service welcome pack or portal values and preserve the SIP identity, authorization identity, source policy, challenge and result without exposing secrets. | Documented For MagSIPConnect, Magrathea documents a two-stage hosted-platform validation model using the provider platform IP ranges plus a unique SIP header. That is a product-specific outbound-routing statement, not proof that every Magrathea interconnect uses the same header, credential or source policy. Preserve the selected service, approved ranges, required header name and value, observed request and acceptance result without publishing secrets. | Documented NFON documents PBX-endpoint username and password authentication and an alternative static mode in which the customer supplies a public static address. These are selectable service modes, not cumulative requirements. Preserve the selected PBX-endpoint template, credential or approved address, observed source, challenge and response without publishing secrets. | Documented The service schedule says SIP credential details are issued to the technical contact. Preserve the credential owner, challenge and rotation without publishing secrets; the public documents do not establish every account’s exact digest, source-address or certificate policy. | Documented T38Fax documents both username/password and public source-IP authentication, with credential authentication as the default recommendation. The billing telephone number is the SIP username; the SIP password is distinct from the customer-portal login. Select one trunk mode deliberately, protect the credential and preserve the actual source address or challenge-response evidence without publishing secrets. | Not verified QuestBlue documents creating a SIP connection and associating it with an outbound voice profile, but the reviewed public pages do not define one digest-credential, source-IP or certificate authentication model for every service. Obtain the account-specific connection record and preserve direction, source address, SIP and authorization identities, challenge and response without treating portal access as trunk authentication. | Not verified Broadvoice publishes a distinct SIP-trunking portal and says the service connects an existing PBX or cloud platform, but the reviewed public material does not define one digest-credential, source-IP or certificate authentication model for every order. Obtain the assigned connection record and preserve source addresses, SIP and authorization identities, challenges and responses without treating a portal login as trunk authentication. | Documented SIPcity documents two distinct connection models: number-based username and password for registration, or a stable public source address whitelisted for static-IP peering. Peering leaves authentication fields blank in the reviewed 3CX example. Record the enabled portal mode, issued identity, expected source, transport and observed decision; do not combine credentials and IP trust or treat the account login as a SIP credential. | Not verified Toku publishes carrier voice, PSTN replacement and Microsoft Teams connectivity, but the reviewed public pages do not define a universal customer-facing SIP authentication contract. They do not establish source-IP trust, digest credentials, mutual TLS, a portal-issued identity or how multiple methods interact. Preserve the selected order, interconnect design, signaling source, credential owner and one timestamped provider decision instead of inferring authentication from product availability. | Documented LoopUp documents IP-to-IP SIP trunks with dedicated customer endpoints. Its encrypted AudioCodes and Ribbon examples require a customer public certificate, an approved issuing root and mutual TLS. The reviewed public pages do not define digest credentials or a complete authorization policy for the UDP and TCP variants. Preserve the selected endpoint, public address or FQDN, certificate identity, trust anchors and current order rather than turning reachability into authorization. | Documented Localphone documents a SIP ID and SIP password in the Internet Phone dashboard and distinguishes those credentials from the main account sign-in. Use the issued SIP identity only in the endpoint or PBX profile, keep the account login separate, and retain one redacted credential-rotation record and resulting challenge response. | Not verified The reviewed public pages do not identify whether a selected trunk uses registration credentials, source-address trust, mutual TLS or another account-specific control. Obtain the issued technical handoff and preserve the authentication identity, source policy, challenge behavior and secret owner without exposing credentials. | Not verified The reviewed public pages do not identify whether a selected trunk uses digest registration, source-address trust, certificates or another account control. Obtain the Clearfly handoff for the exact voice group and preserve the authentication identity, source policy, challenge behavior and secret owner without exposing credentials. | Not verified The reviewed current pages do not publish whether a selected service uses registration, source-address trust, certificates or another control. Obtain the order-specific handoff and preserve the identity, allowed source, challenge behavior and secret owner without exposing credentials. | Documented CommPeak documents both password-based and IP-based SIP accounts. The reviewed pages do not establish which method, username, source addresses, challenge behavior, secret rotation or access rules apply to a selected account; preserve the portal-issued account type without publishing credentials. | Documented Direct PBX ingress uses a source-IP allowlist, third-party SIP clients can authenticate as application users, and saved external SIP registrations use provider credentials. These are separate trust paths; preserve the selected model and secret owner. | Documented TelVox documents two separate credentials: an unscoped Bearer API key for server-side REST requests and a generated SIP username and password for each trunk. API keys are shown once and should be separated by service and environment. The trunk connection response can include the SIP password, so neither secret belongs in logs, browser bundles or public configuration. | Documented The current 3CX and FreePBX guides use the account-issued SIP username and password. The 3CX guide calls the model register/account based. Preserve the selected account identity, credential owner, challenge exchange and rotation process without publishing secrets. | Documented Registration is one documented operation mode. Preserve the account-issued server and credential owner, challenge, Contact, expiry and rotation without publishing secrets. | Documented The quick-start documents customer-address IP Match for U.S. and Canadian service, and separately limits mandatory digest credentials and the outbound 401 challenge to U.S. service. Preserve country, service option, static addresses, peer direction and current handoff. | Documented The current portal exposes distinct User ID, Authentication ID, SIP password, proxy and port fields. The selected account and downloaded guideline govern; legacy babyTEL examples are not current credentials. | Not verified Authentication and trust depend on the ordered access architecture and current project documents. The reviewed Patton guide describes certificate-based Internet architecture, but does not establish one universal registration or credential model. | Not verified The current public records do not establish one universal Evolved Voice registration, credential, IP-authentication or certificate model. The selected order, endpoint design and provider-issued parameters govern. | Not verified The public records distinguish provider eSBC, approved customer SBC and application-service-provider SBC variants but do not publish one universal credential, certificate or source-address profile. The selected order and implementation record govern. | Not verified A 2018 trusted-network design uses remote IP peering without username/password. It is dated and not a universal current authentication profile; the current order and implementation worksheet govern. | Not verified The reviewed public records define access, SBC and PBX responsibility but do not publish one universal credential profile. The selected implementation documentation and loaded configuration govern. | Documented Standard Business SIP Trunking supports register-based credentials or direct IP authentication selected in the portal. Record the current mode; do not configure both by assumption. | Documented The reviewed MaxoTel path uses portal-created, register or account-based SIP trunks with a registration username and password. Portal login and SIP credentials remain separate. | Not verified The reviewed public SIP-trunk sources do not publish one universal authentication identity, secret, realm or source-address policy. The selected service handoff governs; BYO VoIP credentials are not transferred. | Not verified The reviewed enterprise sources do not publish one universal identity, secret, realm, certificate or source-address policy. The selected handoff governs. | Not verified The public records do not establish one universal SIP identity, secret, certificate or source-address policy. The current order and confidential design govern. | Not verified Public records do not establish one universal credential, certificate or source-address model. The current application and OM.37683 govern. | Not verified Public records do not establish one universal credential, certificate or source-address model for both services. The selected implementation specification governs. | Not verified The public overview does not establish a universal credential, certificate or source-address model. The current implementation pack governs. | Not verified Product records distinguish registered SIP Trunks from SIP Voice Connect. The current order and implementation pack govern credentials, certificates or source trust. | Not verified The reviewed public records do not establish one registrar, credential or source-trust profile. The service order and implementation record govern. | Documented Enreach Trunk (DE) documents user authentication and distinct user ID, authentication name and password fields. Other offers require their own implementation record. | Not verified The reviewed public records do not establish one universal MetTel registrar, authentication name, password, digest realm, source-IP model or certificate path. The accepted order and provider configuration govern. | Not verified Public records do not establish one universal registrar, credential, source-IP model, peer set, port or certificate contract. The accepted implementation record and provider confirmation govern. | Documented The tenant guide distinguishes registration-based authentication, ESBC and direct peering. The exact trunk checkbox, username reference and network point of presence govern; no universal credential or source-IP model is inferred. | Not verified Reviewed public records do not publish one universal registration, IP-authentication, username, password, source-address or identification model. The account implementation record and loaded edge govern. | Not verified Public records do not publish one universal registration, address-identification, username, password, realm or certificate model. The accepted implementation record and loaded edge govern. | Not verified Public records do not publish one universal registration, address-identification, username, password, realm or certificate model. The accepted order and loaded edge govern. | Not verified Public 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. | Not verified Public 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. | Not verified Public records do not publish one universal registration, source-address, digest, certificate or managed-edge identity model. The accepted order and implementation record govern. |
|---|
| SIP registration | Documented Twilio directs the communications infrastructure not to register for this trunk. Credentialed termination and optional SIP OPTIONS health checks remain distinct from endpoint registration. | Documented Credential Connections use registration. IP and FQDN Connections have different authentication and routing evidence; a binding does not prove number assignment. | Documented PBX registration uses reg.skyetel.com SRV or the two documented regional hosts, UDP port 5060 only, one PBX per credential set, a minimum 100-second refresh and a 300-second expiry. | Documented Credentialed devices register to a selected server. Preserve the registrar hostname, current DNS answer, response source, expiry and Contact; registration alone does not prove a DID route or POP match. | Documented SIP-REG inbound delivery depends on registration at the relevant Flowroute PoP. Host, URI and PSTN-number routes do not use that registration state, and an IP-authenticated PBX may not appear as registered in portal status. | Documented Dynamic Registration uses generated inbound credentials and the current Contact from successful REGISTER requests; the endpoint must refresh before expiry. Static Endpoint delivery does not require registration. Registration history shows successful active intervals, not failed transactions. | Documented Zentrunk does not support SIP REGISTER. Configure outbound authentication and inbound destination URIs instead of waiting for a registration state. | Documented The credential has a Space-specific SIP address and password. Reconcile project profile defaults, credential values and the loaded PBX registration; a current binding does not prove number routing or call handling. | Documented Bandwidth documents an optional Registrar for activated accounts and registered devices. Build realms and credentials do not establish that every trunk must REGISTER. | Documented The current Voice API static-trunk reference documents regional FQDN termination and configured SIP forwarding rather than a customer REGISTER workflow. Do not apply older Elastic SIP Trunking registered-endpoint evidence to this path without current account documentation. | Not verified The reviewed trunk workflow uses a Vonage-created regional domain, digest or ACL authorization and configured SIP URIs. It does not establish a REGISTER requirement; confirm the selected trunk and PBX guide before treating registration state as a health signal. | Documented Credential mode exposes REGISTER status, Contact, observed source alias, gateway and expiry. IP-authenticated mode shows an IP Auth label rather than normal registration state. Preserve the effective mode and actual inbound target before diagnosing a missing registration row. | Documented Registrar uses SIP REGISTER to learn the current Contact for inbound calls. Customer IP delivery does not require that indicator, and a successful binding does not prove that a DID is assigned to a route profile using it. | Not verified The reviewed Voice Connector workflow directs a PBX or SBC to the connector outbound hostname and documents source allowlists plus termination credentials. It does not establish a universal SIP REGISTER requirement, so use the configured INVITE authentication and OPTIONS evidence rather than inventing a registration health check. | Documented Anveo Direct states that SIP REGISTER is not supported. Outbound service uses IP authentication and inbound calls are delivered to configured SIP URIs; an absent registration status is expected, not a health verdict. | Documented Digest uses SIP REGISTER and can deliver to the current SIP-account Contact. IP authentication does not require registration and instead needs an explicit SIP URI for inbound delivery; a missing registration indicator is not proof that model failed. | Documented Credential workflows can use registration against sip.bulkvs.com, while IP-authenticated paths do not use REGISTER as their health signal. The current registration guide notes that some accounts can require active registration before digest INVITEs are accepted; verify REGISTER, challenge and call independently. | Documented The current public outbound workflow documents source-IP authorization rather than SIP REGISTER. A legacy Voxbeam Asterisk peer example contains username and secret fields but does not establish a current registration or digest-authentication contract. Verify the live account method before using registration as health evidence. | Documented Callcentric publishes a 1777 username and Auth ID, SIP password and sip.callcentric.net registrar. Preserve the exact extension binding and Contact; registration does not prove that a particular DID routes to it. | Documented AVOXI's current FreePBX guide states that SIP registration is not supported and configures Registration as None. Monitor the configured outbound identity and reachability rather than treating an absent REGISTER binding as a fault. | Not verified Legacy first-party pages list regional registrars and UDP SRV names and recommend multiple regions. Another legacy section constrains Primary Location and SubLocation server use. Preserve registrar, DNS, Contact and Location identity, but confirm the current topology in the replacement documentation and current portal. | Not verified The reviewed sources do not establish REGISTER, a registrar, Contact expiry or static delivery as universal. A missing registration indicator is not a fault until the account model is known. | Documented The credential path uses REGISTER, 401 challenge, authorized REGISTER and 200 response. Portal status separately shows the Contact address, observed source alias, selected gateway and expiry. Successful registration does not prove that Contact is reachable for inbound calls. | Not verified The reviewed quick starts configure endpoints, System Gateway sources, DID assignments and per-request authorization; they do not establish SIP REGISTER as the inbound binding. Confirm the effective account model before adding registration health checks. | Not verified The reviewed outbound path is source-IP authorized and does not establish REGISTER as a universal requirement. SIP URI is an inbound destination type, not proof of a provider binding. | Documented Sangoma states that the PBX must register to receive inbound calls. Its FreePBX integration creates primary and secondary connections, while a separate PJSIP procedure converts module-created trunks on applicable versions. Confirm the loaded channel driver and generated objects on the exact FreePBX release; the manual chan_sip article is explicitly limited to version 16 and older. | Documented The 3CX digest workflow uses a regional proxy and registration, while the IP Authentication workflow uses an approved source address. Registration state is relevant only to the configured model and does not prove call routing. | Documented Registered trunks use a PBX or SBC registration and expose REGISTERED or UNREGISTERED status; static trunks use configured addresses instead. Infobip says disabling a registered trunk forces deregistration. Preserve administrative, registration and action status separately rather than treating one green state as call readiness. | Documented Registration belongs to the login-and-password path. The IP-authorized trunk instead accepts outbound traffic from confirmed source addresses; its selected login no longer registers or receives inbound calls. Registration, source confirmation, number routing and call completion remain separate evidence. | Documented Registration belongs to the activated SIP-account path and can expose a green portal indicator. An IP-authorized path instead relies on the approved source record. Registration, source authorization, DID routing and call completion remain separate evidence. | Documented ThinkTel documents OPTIONS-based binding health and says this removes the need for REGISTER, which should be disabled whenever possible. A missing registration indicator is not a failure for a static binding; preserve the ordered handoff, Contact IP and OPTIONS state. | Documented The current FreePBX setup sets both Authentication and Registration to None for the documented source-IP trunk. A configured endpoint group, accepted source address and successful call remain separate evidence states; do not troubleshoot this path by adding REGISTER unless the account owner supplies a different interop procedure. | Documented For a dynamic-address endpoint, GoTrunk says inbound calls follow the address in the most recent registration. Static-address delivery does not require inbound registration. Preserve Contact, expiry, last successful refresh and provider attempt; registration does not prove number assignment or a loaded PBX route. | Not verified The reviewed public pages do not say that every customer trunk uses REGISTER or that registration is forbidden. A service ID, trunk group and CURRENT route-plan status are administrative states, not proof of a loaded PBX registration or completed call. Obtain the account-specific interop guide before selecting an Asterisk or FreePBX registration model. | Documented The guide requires registration for dynamic public addresses and gives bounded expiry guidance, but says a static public address should not register for inbound delivery. A successful REGISTER, portal Active status and completed inbound or outbound call remain different evidence states. Confirm the current account worksheet and registrar before using the historical nexVortex hostnames in the guide. | Documented The general guide documents credential registration with a 60-to-300-second interval. Registration proves a current binding, not outbound authorization, inbound number routing or a completed call. The resources page shows a generic sip.ipcomms.net reference while the configuration guide uses an assigned yourdomain.s1.ipcomms.net host; use the account-specific portal value and record the resolved addresses. | Documented Hosted documentation shows REGISTER, challenge and authenticated REGISTER. The Contact user can shape the inbound Request-URI user. Preserve the assigned server, transport, accepted expiry, Contact and provider-observed binding; a working outbound call is not inbound registration evidence. | Not verified No reviewed public record establishes that every ordered AireSpring trunk registers or publishes a universal registrar, username, expiry or Contact behavior. Preserve the exact product, peer set, trust method and account confirmation instead of manufacturing registration credentials. | Documented The external technical guide explicitly says REGISTER and registration mode are not supported for VoIP Access; the trunk uses fixed source and destination IP addresses. Do not wait for a registration indicator, create a registrar object or copy credentials from another Colt service. Prove reachability, authorized source identity and call completion separately. | Not verified The reviewed public material does not say every ordered trunk registers or publish registrar, username, expiry or Contact behavior. Do not create credentials or wait for registration state without the current implementation record. | Documented The interface specification explicitly says there is no registrar and REGISTER is not supported. This is a fixed-interface trunk, not a phone-style registration workflow. Do not treat an absent registration indicator as a fault or transfer that statement to a different 8x8 product; confirm the ordered X Series trunk and current handover record. | Not verified The public material reviewed does not establish whether a given Bell SIP Trunking order uses SIP REGISTER, fixed peers or another managed handoff. Do not configure phone-style registration or interpret its absence as a fault until the current order and Bell implementation record identify the expected model. | Documented Current India TCP and TLS documentation says SIP registration is not supported. Digest authenticates SIP requests and does not create a REGISTER binding; an absent registration indicator is not a trunk fault. | Documented The reviewed setup material describes a PBX registration and says Nextiva can validate that registration. Registration success does not establish inbound or outbound route configuration, which Nextiva explicitly leaves with the customer PBX administrator. | Not verified Intermedia's broad service port table covers hosted-platform SIP registration, but that does not establish REGISTER behavior for a SIP Trunking order. Confirm the trunk-specific target, transport, identity, refresh and health signal before interpreting registration state. | Documented Peerless advertises static trunks, registered trunks or a combination. The reviewed sources do not publish the registrar, username realm, refresh behavior, Contact handling, transport or inbound-binding rules for one account, so preserve those values from the order before interpreting REGISTER state. | Not verified The 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. | Not verified The reviewed product, brochure and service-schedule sources describe centralized trunks, access options and customer equipment without establishing SIP REGISTER as the binding mechanism. Confirm whether the ordered trunk uses fixed peers, registration or another managed boundary; an absent registration indicator is not by itself a failure. | Documented Spectrum labels the PBX interface registration model as static with optional authentication. Do not substitute a generic dynamic REGISTER template without the implementation worksheet. Gateway reachability, PBX configuration, accepted SIP identity and completed calls remain different evidence states. | Not verified The public API defines inbound trunk groups as PoP plus IPv4 switch targets and does not establish a universal REGISTER workflow. It also does not define every account's outbound peer model. Use the production turn-up record rather than inventing a registrar, realm or template. | Not verified The reviewed first-party pages establish ordered trunks and routing policies but do not state that every trunk uses REGISTER, a fixed peer or one registrar. Record the exact ordered interconnection point, transport, addresses, registration requirement and contact ownership rather than importing a generic PBX template. | Not verified The reviewed product and overview pages do not establish whether every Zayo SIP order uses REGISTER, fixed peers, an SBC handoff or another binding model. Record the exact ordered service, peer addresses, transport, registration requirement, contact ownership and source restrictions rather than importing a generic configuration. | Documented Cox-hosted 2011–2012 PBX-specific guides use a trunk-group pilot or billing telephone number plus a provider-issued secret for REGISTER through a local E-SBC. That is historical reference evidence, not a current universal interface contract. Preserve the current worksheet, challenge, final response, Contact and expiry. | Not verified The public welcome kit identifies a standards-based SIP trunk delivered to an IP PBX but does not establish whether every order uses REGISTER, static IP peering or another account-specific method. Preserve the ordered service type, managed-edge or direct handoff, CPE role, peer addresses, transport and refresh behavior from the implementation record. | Not verified The public overview and April 2021 schedule establish a PBX-facing SIP service delivered at a Site, but not whether the current order uses REGISTER, static peering or another method. Preserve the ordered access type, demarcation, peer addresses, transport, CPE role and refresh behavior from Rogers' current implementation documents. | Not verified The product page says company registration is locked to a specific IP address, but the reviewed public materials do not define one REGISTER, static-peer, refresh, realm, outbound-proxy or failover-registration workflow for every order. Use the provider-issued implementation record rather than converting marketing wording into a universal SIP configuration. | Not verified The public materials establish a service for an existing PBX but do not define one REGISTER, static-peer, refresh, proxy, DNS or failover-registration workflow for every deployment. Use the provider-issued turn-up document and observed signaling for the ordered site rather than importing a recipe from another Momentum service. | Documented The current overview says the PBX registers as a whole. Preserve the exact registrar, resolved addresses, Contact, refresh interval, granted expiration, NAT path and response from the provisioned account. A successful REGISTER does not establish inbound number assignment, outbound identity acceptance or media reachability. | Not verified The public contract set does not establish REGISTER as the universal interconnect model or publish one registrar, realm, Contact policy or expiry. Obtain the order and implementation worksheet, then retain the actual connection method and signaling evidence. A commissioned access circuit or accepted service does not by itself prove a PBX registration. | Not verified The reviewed public material does not establish SIP REGISTER as the connection model or publish a registrar, realm, Contact policy or expiry. Do not infer registration from the SIP Trunk name; retain the provider handoff and observed signaling for the installed service. | Not verified The reviewed public pages do not define REGISTER as the universal connection model or publish one registrar, realm, Contact policy, expiry or refresh behavior. Obtain the implementation record for the selected standard, 3CX, Direct Routing or high-volume product and keep its signaling evidence separate from general setup guidance. | Documented The reviewed Avaya, Samsung and other guides describe register-based trunks using provider-issued credentials and registrar details. The current order and portal record must establish Contact, expiry, refresh, concurrent-registration and source-address behavior for the selected PBX rather than inheriting a legacy template. | Not verified The public product and implementation pages do not establish whether a selected design registers, uses static peers or combines mechanisms. Do not infer a registrar from the SIP-trunk label. Record the ordered signaling peers, transport, Contact behavior, expiry and refresh policy, qualification and source-address requirements from the implementation package and loaded PBX or SBC state. | Documented The published examples show account-number registration at sip.voipfone.net. They are chan_sip-era starting points, not a current PJSIP profile or proof of the expiry, Contact, concurrent-registration or source policy active on one account. | Documented 1TR119 specifies CompanyFlex registration and Contact requirements for the SIP-PBX interface. A successful REGISTER is not proof that identity headers, inbound routing, media security or failover are correct. Retain the current assigned registration number, resolved targets, transport, Contact, expiry, refresh, response and loaded PBX state for the exact trunk. | Not verified The 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. | Not verified The reviewed public material does not establish whether an ordered trunk registers or uses static IP peering. Required-IP routability and the CIU demarcation are not registration proof; preserve peers, transport, Contact behavior and source controls from the exact handoff. | Not verified The public records establish SIP trunks to customer equipment but do not say whether the selected service uses REGISTER, static peering or another handoff. Preserve peers, transport, Contact behavior, expiry, qualification and source controls from the accepted handoff. | Not verified The reviewed public records do not establish whether the selected Cogeco service uses REGISTER, static peering or another handoff. Preserve peers, transport, Contact handling, expiry, qualification, DNS dependencies and source controls from the accepted design. | Not verified The public records do not establish whether one account uses REGISTER, static peering or another handoff. Record the registrar or peer addresses, transport, proxy, Contact behavior, expiration, qualification, DNS dependencies and source-address rules from the provider-approved implementation record rather than inferring them from a generic PBX compatibility claim. | Not verified The reviewed public product, support and contractual records do not establish a generic customer REGISTER workflow. They describe a dedicated connection, Comcast equipment and a SIP gateway with Session Border Control, but do not publish one universal registrar, proxy, Contact, expiry, qualification or source-address rule. Use only the selected order and implementation handoff. | Not verified The 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. | Documented OnSIP stores the trunking flag with registration and says re-registration is needed to clear it. Its Asterisk example uses legacy chan_sip; Asterisk removed chan_sip in version 21. Translate the assigned handoff to the loaded current driver and validate a sanitized REGISTER and response. | Documented sipgate says the PBX is registered as a whole rather than every phone. Its Asterisk example uses sipconnect.sipgate.de for server and client URIs and states that incoming calls require the Asterisk system to register. Treat that example as a starting point, not a complete template for another PBX, transport, DNS policy, Contact lifetime, qualification interval or retry strategy. | Documented For a registration-based trunk, Cisco says the local gateway performs SIP registration and must keep it active. Certificate-based trunks use a different trust and reachability model. An active registration establishes that trunk connection only; it does not prove a Route List number, route group, dial plan, Cloud Connected PSTN provider or completed off-net call. | Documented Microsoft documents a paired SBC, TLS connectivity and SIP OPTIONS health rather than a customer endpoint REGISTER flow. The dashboard can show an enrolled gateway that never connected as unhealthy. A healthy pairing or recent OPTIONS proves only the Microsoft-to-SBC control boundary; it does not prove carrier-trunk state, user assignment, number routing or a completed call. | Not verified The reviewed documentation establishes a mutually authenticated trunk and secret header, but it does not establish a PBX-style user SIP REGISTER workflow. Confirm the selected carrier and certified-SBC integration, then preserve trunk status, SIP OPTIONS where used and an actual call independently; do not translate a certificate handshake into registration success. | Not verified The reviewed BYOC-P documents describe provisioned SBCs, Route Groups and SIP Groups rather than a phone-style REGISTER workflow. Do not invent a registrar, Contact expiry or registration indicator. Confirm the current account's provisioned peers, certificate state, OPTIONS or other health evidence where configured, and an actual authorized transaction independently. | Not verified The reviewed BYOC pages do not establish whether the RingCentral-facing or carrier-facing leg uses REGISTER, static peering, a certified SBC profile or another method for the selected deployment. Do not invent a registrar, Contact lifetime, qualification timer or connected indicator. Record each leg independently and distinguish a configured gateway from a reachable peer and an accepted call. | Not verified The reviewed BYOC Cloud workflow describes provisioned BYOC Carrier or BYOC PBX trunks, outbound SIP destinations, source controls and inbound identifiers rather than a universal REGISTER workflow. Do not invent a registrar, Contact expiry or registration lamp. Confirm the selected carrier's current handoff, OPTIONS behavior, accepted transaction and call outcome separately. | Not verified The reviewed Direct Routing workflow describes SBC pairing, TLS and SBC-originated SIP OPTIONS rather than a universal SIP REGISTER transaction. Do not invent a registrar, Contact expiry or registration indicator. Confirm portal pairing, current TLS and OPTIONS status, the carrier-side trunk state and an accepted authorized call independently. | Not verified The reviewed public material does not establish that every Pure IP trunk uses REGISTER, a common registrar, a shared expiry or one health indicator. Do not invent those values. Record whether the selected service is static peering, registration-based or platform-connected, then prove the configured peer, current transaction and authorized call independently. | Not verified The reviewed public material does not establish that every Ooma Enterprise trunk uses REGISTER, a common registrar, one expiry or one health indicator. Record the ordered static or registration model and prove the loaded transaction independently. | Documented The general guide documents credential registration to voip.easybell.de. A successful REGISTER proves that credential path and Contact at that time, not inbound delivery when Trusted IP or trusted FQDN is selected. Portal mode, challenge, Contact, stored target and provider attempt remain separate. | Documented The general workflow documents source-IP outbound authorization without a REGISTER dependency and optional credentials, while the public FreePBX example also shows a registered credential path at talk.yay.com. Determine the selected account mode and keep REGISTER, challenge, INVITE and completed call as separate evidence. | Not verified The failover page says Voiceflex can monitor whether a PBX responds or regularly registers, which shows that registration may be relevant to a configured service but does not make REGISTER mandatory for every trunk. Confirm the ordered mode, registrar, proxy, transport, Contact, expiry, refresh and response from the account-specific technical pack. | Not verified The reviewed public pages do not establish whether REGISTER is required, optional or absent on the selected trunk, nor do they publish a registrar, proxy, Contact policy, expiry or refresh interval. Bind those values to the account-specific technical pack and observed responses. | Documented The Lyra and Plus generic-device guides describe REGISTER with a 600-second expiry and 60-second NAT keep-alive, but use different realms and proxies. Those values document generic registration examples, not an observed account or a universal IP-peering contract. Verify the platform shown in the portal and retain the actual challenge, Contact, expiry and response. | Documented The reviewed guidance uses registration and recommends a 180–300 second re-registration interval during connection troubleshooting. It says as many as five devices can register to one SIP line but recommends one device per line. Those are service inputs, not proof of the selected line contact set, expiry, reachability or completed calls. | Documented A PBX can register like a SIP phone, while an inbound “SIP to your Server” target does not require registration. If both are configured, A&A says it may send INVITEs to the registered device and the configured server. Record DNS and SRV resolution, all contacts, expiry and the chosen inbound target instead of assuming one universal trunk mode. | Documented Zen publishes voip.zen.co.uk through a proxy on UDP 5060, no STUN, and a provider re-registration interval of up to 900 seconds. Preserve DNS results, source and destination, Contact, expiry, challenge and response for the selected account. Do not treat registration as proof of inbound, outbound or media success. | Not verified The reviewed public material does not establish whether the selected trunk must register, uses an authenticated proxy, or authorizes a source address. Inbound number delivery can target a customer FQDN or IP address, but that does not establish the outbound signaling model. Record DNS, transport, source, destination, Contact, expiry and any challenge from the actual order. | Not verified The reviewed public pages do not define a REGISTER requirement, registrar, expiry, Contact policy or digest challenge for the selected service. MagSIPConnect describes source-range and header validation, while SIP Resilience describes nominated delivery IPs; neither statement establishes a universal registration model. Obtain current order-specific signaling details and retain DNS, transport, source, destination, Contact and response evidence. | Documented The July 2024 manual describes each trunk as a SIP user, supplies an endpoint username and password, and gives the service FQDN for registrar and proxy configuration. Static authentication is a separate mode. Confirm the current portal template, transport, resolver results, registration contact, expiry and response for the selected endpoint rather than copying example credentials or fixed addresses. | Documented The service schedule defines a SIP trunk as one registration with one or more channels and describes the standard single registered account for a headline number and aliased DDIs. Preserve the issued registrar, Contact, expiry and response; registration does not prove number routing or calls. | Documented The registration-authenticated workflow relies on an active SIP registration for bidirectional signaling through typical NAT, while IP-authenticated trunks require explicit inbound reachability. Record registrar or proxy, transport, local and remote port, contact, expiry, observed address and response; a portal object or reachable socket is not a successful registration. | Not verified The reviewed public pages do not establish REGISTER as required or unsupported, or publish a universal registrar, realm, Contact policy, expiry, refresh or transport. Determine the selected connection type from the current provisioning record before choosing a PBX template, and retain the actual registration exchange if registration applies. | Not verified The reviewed public pages do not establish whether REGISTER is required, optional or unsupported, or publish a universal registrar, realm, Contact policy, expiry, refresh or transport. Select a PBX template only after reconciling the current order and provider-issued configuration, then retain the actual registration exchange if registration applies. | Documented The generic record uses call.sipcity.com.au, the SIPcity number as username and authentication ID, registration enabled and calls without registration disabled. It publishes TLS 5061, while the broader methods page also lists UDP 5060 and a 180-second server expiry. A separate 3CX example says sip.sipcity.com.au or the hostname provided with the order. Preserve the account-issued host and loaded PBX state instead of silently normalizing these examples. | Not verified The reviewed public material does not publish one registrar, proxy, realm, expiry, transport or REGISTER requirement for Toku carrier voice. The Teams page identifies a separate Toku-to-Microsoft integration, not a generic PBX registration template. Use the issued implementation record and observed SIP exchange; do not copy a country-number page or Teams claim into a PBX configuration. | Documented The August 2026 setup guide says SIP registration is not supported. This is an IP-to-IP trunk using dedicated, globally unique endpoint-and-port combinations. Do not configure a registrar, expiry, contact refresh or digest registration from a generic PBX template; retain the issued regional targets and customer endpoint instead. | Documented The reviewed device guides use registration to localphone.com with the issued SIP ID and password. The Asterisk page is an older chan_sip example, not a current PJSIP template or compatibility statement. Preserve the dashboard-issued details, loaded PBX object, resolver result, Contact, expiry, challenge and response rather than translating the example silently. | Not verified No public registrar, proxy, expiry, Contact policy or registration failover sequence was verified. Do not invent an address from the provider domain or copy another customer profile. Record the supplied targets, DNS answers, loaded PBX objects and observed transaction for the exact order. | Not verified Clearfly says its portal can expose voice-group information and registrations, but the public material does not publish one registrar, proxy, expiry, Contact policy or failover sequence. Treat portal state, loaded PBX configuration, a SIP transaction and completed call as separate evidence. | Not verified No current registrar, outbound proxy, DNS record, expiry, Contact policy or target order was verified. A legacy public service definition describes provider edge session border controllers as a demarcation, but that historical design is not evidence of a current customer handoff. | Documented The current FreePBX and Asterisk guides identify sip.commpeak.com as the SIP domain for their examples. They do not document one universal DNS record set, target order, proxy policy, registration interval or Contact behavior for every account, so retain the portal-issued settings and observed DNS and registration state. | Documented Saved registrations specify proxy, username and password, with optional authentication user and outbound proxy. Status can be Successful, In progress or Failed; persistent and user-login-dependent non-persistent modes have different lifecycle behavior. | Documented The connection object supplies the account-specific SIP domain, port, transport, username and password. Documented transports are TCP, TLS, UDP and WSS, but transport is fixed after creation. A new trunk is pending until TelVox marks it active; suspended and revoked are separate states. A successful API create is therefore not proof that SIP registration or calls work. | Documented PBX guides say to use the SIP server address supplied with the account; the reviewed sources do not establish one universal public registrar, realm, DNS set or proxy path. Retain the issued value, resolver answers, transport, Contact and server-directed expiry. | Documented Registration, SIP URI diversion and Microsoft Teams gateway are distinct modes, while public-internet and ordered private-IP delivery are separate interconnect boundaries. For registration, preserve the issued registrar, Contact, expiry and complete response sequence; a successful binding does not prove number routing, outbound authorization or media. | Documented Registration with Digest Authentication is documented as mandatory for the U.S. path, while IP Match applies in the U.S. and Canada. OPTIONS, portal login, registration, IP match and accepted calls remain different states. | Documented Cloudli directs customers to Device Configuration → SIP parameters and publishes firewall guidance about stable NAT mappings across REGISTER messages. Registration, inbound routing, answer and media remain different states. | Not verified The reviewed current public records do not establish REGISTER as the service model for every Business Talk or BTIP site. Keep site activation, edge reachability, OPTIONS probing, endpoint identification and accepted calls separate. | Not verified No selected Evolved Voice REGISTER model or observed registration was established. Keep activation, endpoint reachability, OPTIONS, registration, number routing, answer and media separate. | Not verified No universal REGISTER model, registrar, realm, Contact policy or expiry was established for Enterprise SIP. Keep order activation, access, SBC reachability, peer authorization, number routing, answer and media separate. | Not verified The 2018 example says no registrar. Do not transfer that model to another package or access path without matching current Sunrise design evidence. | Not verified The service description discusses cloud SBC voice and optional device registrations for named flavours. It does not establish one registration model for every Business Trunking order. | Documented Register-based trunks use username, password and SIP domain. Live Registrations and Registration Logs expose current observations; an IP-auth trunk is not expected to register. | Documented The 3CX example uses the portal-issued proxy, username, password, a 120-second re-registration timeout and UDP. Loaded fields, REGISTER response and continued reachability remain separate. | Not verified A universal REGISTER requirement, registrar, proxy, expiry, refresh and Contact policy were not established publicly for the selected trunk. Preserve the provider handoff and observed exchange. | Not verified A universal REGISTER requirement, registrar, proxy, expiry, refresh and Contact policy were not established for Enterprise SIP Trunking. | Not verified A universal REGISTER requirement, registrar, proxy, expiry, refresh or Contact policy was not established for every SIP Connect design. | Not verified A universal REGISTER requirement, registrar, proxy, expiry or Contact policy was not established for every Evolve Voice design. | Not verified A universal REGISTER requirement, registrar, proxy, expiry or Contact policy was not established for every One NZ SIP design. | Not verified A universal REGISTER requirement, registrar, proxy, expiry or Contact policy was not established. | Documented The product overview describes SIP Trunks as registered and SIP Voice Connect as a SIP gateway. Account registrar, expiry, Contact policy and loaded state remain unverified. | Not verified Registration, OPTIONS, source identification, expiry and Contact behavior are not published as one universal Superloop SIP Trunk profile. | Documented Current Swyx documentation supports provider-defined registration, while the Enreach Trunk (DE) profile supplies named account parameters. One loaded account state remains unverified. | Not verified The product sheet establishes SIP Trunking for an IP PBX but does not establish whether one order registers, uses source-address identification or another handoff. Loaded state and an accepted transaction remain unverified. | Not verified The product connects premise systems but does not establish whether one order registers, trusts source addresses or uses another handoff. Loaded state and an accepted transaction remain unverified. | Documented The portal can indicate that the PBX sends SIP registration. A checkbox, username or configured object does not prove a current accepted registration or completed call. | Not verified A native SIP handoff is documented, but the public sources do not establish whether one order registers, peers by address or uses a provider-managed gateway. | Not verified Cloud SIP is documented, but the public sources do not establish whether one order registers, peers by address or uses provider-managed edge equipment. | Not verified Enterprise 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. | Not verified Dynamic IP SIP Trunkgroup is documented, but public records do not establish whether one order registers, peers by address, uses a managed gateway or combines those controls. | Not verified SIP 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. | Not verified Reviewed public records do not establish whether one order registers, peers by address, uses provider equipment or combines controls. |
|---|
| Inbound delivery | Documented Associate numbers with the trunk and configure enabled OriginationUrl resources with explicit `sip:` URI, priority and weight. The current API page presents conflicting default markers, so preserve stored values rather than relying on defaults. | Documented Assign each number to a SIP Connection, select the applicable inbound SIP region and configure routes for that Connection. Current network data, DNS answers and observed source addresses must be reconciled for the incident date. | Documented A number routes to an IP group or to one SIP credential set. An IP group contains one or more public IP endpoints; a custom endpoint port affects inbound delivery only, while outbound IP-authenticated SIP is sent to provider port 5060. | Documented Each DID has a primary route, POP and inbound dialing mode. The POP must match the server or proxy used by the intended device; preserve delivered NANPA or E.164 form and the PBX match separately. | Documented Flowroute route objects and the DID primary or failover relationships that reference them are separate records. Documented types are host, number, uri and sip-reg; administrative creation or assignment success does not prove live delivery. | Documented Static Endpoint constructs the Request-URI from configured user part, host and optional port; leaving port empty invokes DNS SRV. Dynamic Registration uses the active Contact and can replace its user part with the called DID through Use DID in R-URI. | Documented Link Plivo numbers to a separate enabled inbound trunk and configure a primary customer FQDN or IP address plus optional URI authentication. Preserve the number link, trunk ID, URI and PBX match as distinct evidence. | Documented A purchased phone number can be assigned to a SIP endpoint resource. A Resource SIP Address is a separate inbound path to resource logic. Confirm the exact resource and PBX route for the selected call. | Documented Build numbers use prioritized routes containing weighted endpoints. Number voice mode, route priority, endpoint weight, provider attempt and PBX match remain separate. | Documented Voice API origination sends Sinch calls to the customer through SIP forwarding or Callback API ConnectSIP control. Static configuration uses a separate origination application with assigned numbers and a SIP URI; `{number}` can be replaced by the inbound number. | Documented Link each Vonage number to the intended SIP trunk, then preserve trunk type, inbound region, customer SIP URI, priority, timeout, transport and PBX match as distinct evidence. Linking can replace an earlier application or domain association. | Documented A DID is assigned to a primary trunk and can have a separately configured secondary trunk. Credential mode sends inbound calls to the active Contact; IP authentication sends them to the stored public address. PSTN Forward, PSTN Backup and PBX routing remain separate DID controls. | Documented A DID selects a route profile whose prioritized destinations can be Registered PBX, Customer IP, Transfer, Voice API or eFax. DID assignment, destination order, provider attempt and PBX match remain separate evidence. | Documented A phone number can be assigned to a Voice Connector or group. Group priority selects among member connectors first; the selected connector then evaluates origination-host priority before relative weight among equal-priority hosts. Preserve both layers and the actual AWS attempt. | Documented Inbound DIDs target SIP URIs. The FAQ publishes signaling sources, while Anveo Direct says it does not proxy RTP and underlying carriers send media directly; signaling trust and media policy require separate evidence. | Documented A purchased number can target a SIP account, Webphone, SIP URI or external number and can use sequence or hunt-group destinations. Preserve the saved type, target and order; outbound success does not establish any of them. | Documented A DID is assigned to an inbound trunk group and IP delivery targets the configured customer address or supported hostname. The provider documents 11-digit request-URI delivery by default. DID assignment, destination reachability, PBX identification, route match and media remain separate evidence. | Documented A trunk-level IP or SIP URI is the default inbound destination, while a populated per-DID SIP Endpoint URI overrides it; an empty DID field falls back to the trunk default. Preserve DID ownership, both values, provider attempt, current source, Request-URI and first PBX route. | Documented A direct DID Forward can target a PSTN number, Callcentric account, SIP URI, IP address or fax reception and expressly takes higher priority than Call Treatments. Export that rule before diagnosing the PBX. | Documented An inbound number uses an enabled routing rule whose target is a named SIP URI with caller-ID format, destination, port and protocol. Editing a shared SIP URI changes its settings for all applicable numbers, so number mapping and URI configuration require separate evidence and rollback. | Not verified Legacy portal documentation says a number defaults to its Primary Location and can use linear or random Smart Routing across Primary and SubLocations. It also documents ten-digit, eleven-digit or trunk-username identity forms. Confirm every number owner, destination and delivered identity in the current portal before changing PBX routes. | Documented A local DID can route to a phone system or call forward to another destination. Preserve the selected mode, exact redacted destination and observed provider attempt. | Documented For registered service, SIPTRUNK attempts inbound traffic toward the Contact supplied by the PBX. Default inbound documentation shows a ten-digit From user and eleven-digit To user. Preserve DID assignment, provider attempt, Contact, endpoint identification, context and loaded number match separately. | Documented A rented DID targets a trunk group, which selects a trunk and its third-party endpoint. Preserve the number, group, routing type, selected trunk, endpoint, provider attempt, customer-edge receipt and PBX match separately. | Documented An active number references an inbound routing preference with up to three ordered IP, DNS, PSTN or SIP URI destinations. | Documented SIPStation normally attempts its primary gateway and then the secondary gateway; inbound DIDs are delivered as ten digits according to the troubleshooting guide. The FreePBX module can create basic inbound routes, but generated routing still requires review for DID matching, destination ownership and overlap with existing routes. | Documented A phone-number record includes status and inbound destinations; Wavix also documents routing to a SIP-capable PBX or forwarding externally. Preserve the exact destination type, redacted target and observed attempt. | Documented Infobip documents renting a Voice number, assigning an inbound route and forwarding it through Call Routing to a selected SIP trunk. A static trunk also requires at least one customer destination IP or FQDN. Keep the number, route, destination order and delivered identity distinct from outbound trunk authentication. | Documented Inbound numbers can target another registered SIP login or an external-server SIP URI without registration. Preserve number ownership, the selected destination, current provider source addresses, delivered called identity and first loaded PBX route independently. | Documented DIDforSale publishes multiple inbound gateway sources and says rejecting only some is a common cause of split failures. Reconcile the current list, then preserve provider selection, customer-edge receipt, delivered DID format and first PBX route separately. | Documented ThinkTel assigns a pilot to the trunk and can attach DIDs from other rate centres. Up to eight IP addresses may be associated, with each IP and port pair forming a binding. Pilot inventory, DID assignment, selected binding, edge receipt and PBX route remain separate evidence. | Documented DIDs route to an Endpoint Group containing customer IP destinations. Sangoma documents E.164 delivery by default in the FreePBX workflow. Preserve the exact DID assignment, endpoint group, destination address and port, provider source set, delivered called-party format and PBX context; a working outbound call does not prove inbound routing. | Documented Quick Start adds an inbound number after the SIP endpoint, and the FreePBX guide maps each number to an inbound route and destination. Preserve number state, endpoint assignment, provider attempt, delivered called identity, loaded route and final destination independently. | Documented For the documented SONUS-based service, a phone number can be assigned to a route plan that controls inbound delivery across one or more trunks. Preserve service family, service ID, number assignment, route-plan status, hunt type, selected trunk, customer-edge receipt and PBX route separately. | Documented Number Routing selects static-address or dynamic-registration delivery for each DID or toll-free number and can translate the inbound Request-URI user. Preserve the number, term type, selected address or Contact, translation, delivered identity, edge receipt and PBX result separately. | Not verified The reviewed public pages establish account credentials and number service but do not document a complete generic number-to-contact or Request-URI workflow. Obtain the assigned DID route, expected called identity, source scope and contact behavior from the portal or support, then correlate one authorized inbound call from provider identifier to PBX destination. | Documented The Hosted interop guide distinguishes a Contact-derived Request-URI user from the called number in To. Preserve both values, the provider attempt, source, PJSIP identification, context and first loaded route match before normalizing a dialed identity. | Documented Local service uses AireSpring-supplied or ported numbers and SIP delivery to the customer gateway or IP-PBX. Preserve number and port state, active account route, provider attempt, Request-URI or called identity, edge receipt and PBX destination separately. | Documented Colt documents configurable inbound A- and B-number formats, including national, international or extension digits, over the static trunk. Record the assigned DDI range, selected number format, Request-URI, asserted identities, source SBC and final PBX match. A working trunk does not prove that every number block or PBX route is correct. | Documented SIP Trunk Call Manager can terminate subscribed 01, 02, 03 and 08 numbers on Gamma SIP Trunks. Number assignment, selected cloud rule, provider attempt, customer-edge receipt and PBX destination remain separate. | Documented The X Series FAQ says an Admin Console claimed number is assigned to the SIP trunk by Technical Support. That administrative assignment does not establish the source peer, Request-URI, presented number format, PBX match or final destination. Preserve the claimed-number record, support change and one authorized inbound trace through the intended route. | Documented Bell documents per-number Remote Call Forwarding for all calls, scheduled calls and out-of-service conditions. Preserve the exact number, entitlement, rule, schedule and timezone, provider attempt, delivered identity, customer-edge receipt and PBX route separately. | Documented Classic inbound delivery requires a phone number mapped in pstn mode, a published Flow whose Connect applet dials sip:<trunk_sid>, and a destination URI. Voice AI or StreamKit journeys use flow mode. Each object must be verified independently. | Documented Numbers are assigned to the SIP trunk through Nextiva support, while the customer PBX owns the inbound route and final destination. Portal number state, an arriving INVITE, PBX route selection and user-visible ringing remain separate evidence stages. | Documented HostPilot organizes trunks by PBX location and assigned phone numbers. Keep location, number assignment, arriving INVITE, PBX route and final destination separate; a portal number is not evidence of accepted delivery. | Documented The Peerless Portal can order telephone numbers and channels and manage services, routing, configuration and inventory. Keep number inventory, assignment, configured destination, arriving INVITE, PBX acceptance and final extension delivery as separate evidence; portal visibility is not proof of a completed call. | Documented GTT 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. | Documented Global SIP Connect includes Global Inbound Off-net Voice Service and country-dependent Domestic Voice Service over the selected private, dedicated-IP or public-IP trunk. Tata also advertises DID, toll-free and local-number services. Keep the ordered number, country, access type, customer peer and delivered identity separate. | Documented Spectrum manages voice from the public telephone network to its on-premises Enterprise SIP Gateway, which can connect directly to the IP PBX or through a switch, router or customer SBC. The ESG is the provider demarcation; the customer retains the LAN and PBX-side configuration. Keep the assigned number, ESG, delivered identity, PBX route and destination separate. | Documented Each active DID is assigned to a trunk group. New DIDs begin on the default group, explicit assignment can move them, deleted groups move their DIDs to the default, and the default can be used as a fallback. Ring type, PoP, switch targets, source admission, PBX match and media remain separate evidence. | Documented Numbers belong to packages and follow that package's routing policy. Bundle packages use a primary and optional redundant trunk; usage packages use Round Robin, Sequential or Proportional profiles. Package membership, profile type, selected trunk, number translation, edge receipt and PBX result remain separate evidence. | Documented Zayo describes SIP Solutions as connecting an on-premises or cloud PBX to the PSTN and offers private, over-the-top, Teams Direct Routing and Webex SIP-trunk deployment options. The public pages do not expose a universal number-to-destination workflow; preserve the assigned number, access model, ingress peer, delivered identity, PBX match and final route separately. | Documented Pilot or BTN registration and DID delivery are separate. The old Avaya guide creates an incoming call route for each DID and uses To-header indexing in that release. Preserve current assignment, Request-URI, To, source E-SBC, PBX identification, normalization and first loaded route. | Documented Verizon activates the ordered service with native or test DIDs before a later port or migration may complete. Preserve the authorized and final number inventory, cutover record, provider attempt, delivered identity, customer-edge receipt and PBX route separately; selected successful tests do not prove every number. | Documented Rogers documents purchased DIDs and provider-side delivery, but public material does not define one current Request-URI or identity pattern for every order. Preserve DID inventory, port state, provider-selected peer, edge receipt and PBX route separately. | Documented Fusion Connect describes a PBX-facing PSTN service, unlimited DID support and a Business Telephone Number included with each order. That establishes service and ordering roles, not unlimited assigned inventory or one Request-URI, P-Asserted-Identity, Diversion, number-format or PBX-destination rule. Capture the provisioned numbers and delivered identifiers for the actual order. | Documented Momentum advertises global number coverage, local and toll-free number portability, inbound and outbound service, DIDs and custom routing. These are portfolio and ordering capabilities, not proof of number availability, port acceptance, one delivered identifier format or one PBX destination rule. Preserve the exact number inventory, port state and delivered headers. | Documented The account assigns one or more numbers or number blocks to a trunk. The FreePBX guide distinguishes account-side number assignment from PBX inbound routes. Preserve the ordered inventory, port state, delivered Request-URI and headers, selected trunk and final dialplan destination; the product page does not establish number availability or port acceptance. | Documented The September 2025 terms separate full PSTN replacement, which may include inbound and outbound calling, from outbound-only service. Part B makes geographic numbers and number presentation order-dependent and allows public or private dial plans. Preserve the Site's ordered service version, number inventory, port state, delivered identity and selected PBX route. | Not verified The product is presented for enterprise calling, but the reviewed page does not publish one inbound number format, Request-URI rule, asserted identity policy or porting workflow. Capture the ordered number inventory, activated state, delivered identities and the exact PBX route that matched each acceptance call. | Documented Gradwell advertises DIDs, flexible number presentation and inbound and outbound channels. Those portfolio claims do not define the delivered Request-URI, asserted identity, number normalization or route for one order. Retain the assigned inventory, port state, delivered identifiers and the PBX destination that matched each accepted test. | Documented VoiceHost's PBX guides use assigned DDI inventory, E.164-style numbers and configurable plus-sign handling. Those examples do not establish the Request-URI, asserted identity or normalization for every account. Retain the assigned inventory, port state, delivered identifiers and matched PBX destination for each authorized acceptance call. | Documented A group contains assigned numbers and users; a group trunk group is the path between AT&T IP Flexible Reach and the PBX. A trunk call routing scheme can bundle multiple group trunk groups. Preserve group and number inventory, scheme membership, provider-selected group trunk group, customer-edge receipt and PBX route separately. | Documented The control panel routes individual telephone numbers to destinations including extensions, voicemail, mobiles, queues, groups and IVRs. Provider delivery and the PBX’s first matching inbound rule remain separate evidence. | Documented CompanyFlex supports individual and DDI number ranges and lets multiple sites share contracted parallel calls. That commercial scope does not establish a particular delivered Request-URI, P-Asserted-Identity, number normalization or PBX route. Preserve the assigned inventory, port state, exact inbound identities and matched destination for each authorized acceptance call. | Documented Espresso 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. | Documented TELUS describes inbound and outbound service and DIDs that may be added or ported. Number inventory, port state, trunk-group selection, provider attempt, customer-edge receipt, Request-URI and PBX normalization remain separate evidence. | Documented SaskTel lists calling-line and calling-name identification, one primary number in the tariff description and optional DIDs. Number inventory, port state, RTM scope, overflow selection, provider attempt, Request-URI and PBX normalization remain separate evidence. | Documented Cogeco advertises local numbers for distant locations and inbound delivery to an active trunk under geo-redundancy. Number inventory, port state, provider selection, eSBC receipt, Request-URI, asserted identity and PBX normalization remain separate evidence. | Documented net2phone says its portal manages call routing, caller ID, location addresses and associated phone numbers and markets virtual numbers in more than 50 countries and 300 cities. Those statements do not establish one account's assigned inventory, completed port, delivered Request-URI, asserted identity, normalization or route priority. Preserve the order, number record and authorized traces for every accepted inbound pattern. | Documented The portal number list, DID, DNIS, ANI, calling-name and Caller ID features are different evidence. Preserve account and location inventory, Request-URI, To, asserted identity, source group, customer-edge receipt, PBX normalization and the first loaded route. | Not verified Eastlink 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. | Documented Transferred PSTN Gateway numbers begin ringing the new OnSIP PBX immediately. Preserve number and transfer state, timestamp, provider attempt, called identity, edge receipt, current PBX context and destination rather than treating account inventory as proof of routing. | Documented The current help page distinguishes trunk in, where inbound and outbound calls use sipgate after numbers are ported, from trunk out, where inbound calls stay on the existing fixed-network connection. The Asterisk example says inbound calls present the complete dialed E.164 number in the Request-URI. Confirm the ordered mode, assigned or ported number block, delivered identity and PBX normalization for each route. | Documented The hybrid PSTN guide says an external call is routed through a trunk in the Route Group when the dialed number matches a number configured in the Route List. Route Lists are location-bound. Preserve the provider-assigned number, Control Hub number state, Route List membership, Route Group, inbound PBX identity and destination instead of treating tenant-wide number inventory as one route. | Documented Inbound calls use Reverse Number Lookup after any SBC-profile inbound number translation. The normalized called number must match a number assigned to a Teams user or resource account. Carrier assignment, SBC receipt, translation-rule order, tenant number assignment, RNL result and destination answer remain separate evidence states. | Documented A carrier-owned number must be added to the SIP Link trunk, verified and assigned to a user, auto attendant or ring group. Google's troubleshooting guide says an unassigned number can produce 404 or 604 and requires a P-Asserted-Identity in E.164 form. Carrier activation, Google assignment, identity acceptance and final destination remain separate checkpoints. | Documented Inbound PSTN calls traverse the selected carrier and customer SBC, then the BYOC-P Route Group and SIP Group to a Zoom destination mapped by DID or extension. BYOC-P requires the Request-URI user to contain the destination E.164 number. Carrier activation, Zoom number inventory, SIP Group mapping, identity acceptance and final user or service outcome remain separate checkpoints. | Documented RingCentral says all PSTN calls travel over the customer's local carrier through a customer-purchased and customer-owned gateway, and its support workflow lets the account manager add or change carrier phone numbers. That establishes the ownership path, not a delivered Request-URI, asserted identity, normalization, port state or destination. Retain the carrier order, RingEX assignment, gateway trace and answered destination as separate evidence. | Documented An inbound INVITE needs a regionally unique Inbound SIP Termination Identifier so Genesys Cloud can associate the call with the correct organization. Genesys documents FQDN, TGRP and DNIS methods, with a custom header only when standard methods are unavailable. Identification, Number Plan Site transformation, destination routing, number ownership and final answer remain distinct checkpoints. | Documented Inbound Direct Routing calls reach the Communication Services resource through the paired SBC and must then be handled by the intended Calling SDK or Call Automation application. Trunk delivery, application event delivery, reachable endpoint, application answer and media remain distinct states. Preserve the carrier DID, SBC normalization, Azure resource and application ownership rather than treating an online trunk as a completed destination. | Documented Pure IP describes PSTN replacement over SIP and number porting as part of migration. That establishes a service category, not the selected DID, ingress peer, called-number format, route or destination. Preserve one trace from carrier port state through the received INVITE and PBX match to final answer before retiring the former path. | Documented Ooma describes a two-way PBX-to-PSTN trunking service. That establishes the category, not the selected DID, ingress peer, called-number format, route or final destination. Preserve those account and call observations separately. | Documented Inbound IP authentication can store up to four public static addresses used sequentially; changing to this mode means a credentials-only PBX outside that list no longer receives calls. FQDN mode instead uses the configured domain and current DNS answer. Preserve number format, target, attempt, edge receipt and PBX match. | Documented A Yay.com number must be assigned to the selected trunk. Inbound delivery targets a public address or FQDN, port and UDP, TCP or TLS transport and can present the dialled number or configured username using E.164 or GB national format. Preserve assignment, DNS, Request-URI, identity and PBX match. | Not verified Voiceflex documents UK and international number supply, porting and inbound PBX connectivity. The reviewed pages do not publish a universal Request-URI, number format, source range, destination port or identity-header contract. Retain the assigned number, port result, delivery target and observed SIP message for every route. | Not verified Spitfire advertises UK and international numbers and porting, but the reviewed pages do not publish a universal Request-URI, number format, source range, destination port or identity-header contract. Retain the assigned number, port result, delivery target and an observed SIP message for every route. | Not verified 2talk says customers can add and port numbers and connect an existing gateway or IP PBX, but the reviewed public pages do not define one Request-URI, called-number format, identity-header or inbound-routing contract for every trunk. Preserve the assigned number, portal route, observed INVITE, PBX match and final destination. | Documented The Swiss support page says the SIP-TRUNK line type must be enabled for PBX-oriented inbound SIP information and supports international E.164 and national Swiss number forms. Number blocks or individual numbers can be assigned to SIP lines. Preserve the actual Request-URI, identity headers, portal assignment, PBX match and final destination. | Documented Control Pages can route a number to a registration, another number or a customer SIP server. Number blocks can inherit the base number target while individual numbers retain separate management and billing. Preserve the called DDI, base or group relationship, selected target, Request-URI and PBX match for each call. | Not verified Zen says customers can keep existing numbers and describes UK-wide number flexibility, but the reviewed current public pages do not define one Request-URI, called-number format or identity-header contract for every trunk. Preserve the assigned or ported number, portal route, observed INVITE, PBX match and final destination. | Documented SureVoIP documents number delivery to a fixed IP address as SIP. In the portal, a SIP destination accepts an FQDN or IP address and an optional port that defaults to 5060. UK numbers are displayed in international format with 44 replacing the leading zero. Preserve the selected number, portal destination, observed Request-URI and identity headers, PBX match and final route. | Documented Magrathea offers UK and Irish numbers with IP or PSTN termination to client servers, and its SIP Resilience service sends incoming calls to a nominated pool of IP addresses. The reviewed pages do not publish the exact Request-URI, identity headers, port or number format for a selected order. Preserve the assigned number, destination pool, actual INVITE and PBX match. | Documented NFON number routing assigns incoming PSTN calls to a trunk set by longest matching prefix. The endpoint template controls international or national number presentation and whether the inbound URI uses an E.164 number or the endpoint identifier. Preserve the called number, current routing object, selected trunk set, actual Request-URI and PBX match. | Documented The standard arrangement aliases DDIs to a headline number for delivery through one registered account; separately rerouted DDIs require a separate headline number. Preserve assignment, port completion, delivered identity and PBX match. | Documented The service supports assigned or ported fax numbers and inbound caller identity. Preserve the exact DID, Request-URI, source, receiving trunk, fax endpoint and provider call record for one inbound attempt. A port order, forwarded temporary number and completed native port are different routing states. | Not verified QuestBlue says numbers can be ordered or ported and that a SIP connection is created in the portal. The reviewed pages do not publish one inbound target, Request-URI format, identity-header policy, source range or destination-port contract. Retain the assigned number, current route object, delivered identifiers, source and first PBX match for each accepted test. | Not verified Broadvoice documents DID management, local and international numbers, routing controls and use with an existing PBX. The reviewed pages do not publish one inbound target, Request-URI format, identity-header policy, source range or destination port for every deployment. Retain the assigned number, route object, delivered identifiers, source and first PBX match for each accepted inbound test. | Documented SIPcity says ordered or ported numbers can be routed in its portal. Its 3CX peering example adds DIDs exactly as issued, while the porting page says an active registered PBX or SIP peer receives incoming calls automatically at cutover. Those pages do not prove the selected number, Request-URI, identity headers or final PBX match. Retain the number order or port record and one timestamped authorized inbound trace. | Documented Toku documents national, local and toll-free resources, bulk porting and country-specific reachability. Its Singapore, Malaysia and Indonesia pages require E.164 presentation to Toku switching infrastructure and distinguish number types, inbound reachability and local caller-identity behavior. Those pages do not prove the selected DID, Request-URI, identity headers, assigned route or PBX match. Retain the exact number order and an authorized inbound trace. | Documented Numbers are assigned to a trunk in the LoopUp portal. The trunk region must match the region of the numbers, and LoopUp requires E.164 presentation. The public guide does not establish one account's assigned numbers, inbound Request-URI, asserted identity, diversion history or PBX destination. Preserve an authorized INVITE and first matching PBX rule before normalizing digits. | Documented Localphone documents incoming numbers that can be routed to an Internet Phone SIP ID or voicemail. It also says the number is assigned rather than selected from a public list and that sequential requests may require support. Those pages do not establish current inventory, the delivered Request-URI or identity headers, portability, or the first PBX match. Preserve the order, dashboard route and one authorized inbound trace. | Documented IP Telecom describes SIP trunk connectivity to the public network and support for porting geographic, non-geographic, DDI and freephone numbers. Those statements do not establish current inventory, port eligibility, delivered Request-URI, identity headers, primary target or alternate delivery for a selected order. Preserve the port and routing handoff plus one authorized inbound trace. | Documented Clearfly describes local and long-distance numbers, toll-free calling, personalized DID forwarding and virtual-attendant options. It does not publicly establish current number inventory, port eligibility, delivered Request-URI, identity headers or primary and alternate SIP destinations for a selected order. Preserve the order, port record and one authorized inbound trace. | Documented The current modernisation page includes number migration and management, call-flow design and cutover planning within possible project scope. It does not establish inventory, portability, port timing, delivered Request-URI or identity, or primary and alternate targets for a selected order. | Not verified CommPeak publishes DID numbers as a separate network product, but the reviewed trunk pages do not establish inbound service, inventory, portability, delivered Request-URI or identity, or primary and alternate targets for a selected account. Treat inbound numbers and routing as separately accepted scope. | Documented Direct PBX calls use an application address and destination-matching routing rules. Calls received through a saved registration require an application and rule binding; the registration-bound rule handles those calls without a pattern. | Documented A trunk can send arriving calls to a voice webhook, whose returned markup controls the call. TelVox also documents DIDs claimed from a dashboard pool, with no numbers API. Pool inventory, country coverage, portability, delivered SIP identity, webhook reachability and application behavior remain separate evidence for the selected account. | Documented The product page offers number add-ons and the UniFi Talk guide imports subscribed numbers, but selected inventory, portability, delivered identity, primary target and alternate treatment remain account specific. Registration does not prove a DID route. | Documented Numbers can be activated or ported and mapped into call flow, but selected inventory, completion, delivered identity, target and fallback remain account specific. | Documented The quick-start lists extended DIDs and P-Asserted-Identity behavior; portal pages expose group- and individual-DID controls. Number inventory, port completion, provider selection, delivered identity, edge receipt and PBX route remain separate. | Not verified Current product material describes retaining or selecting numbers, while continuity can be set per independently routed number. Number assignment, port completion, provider attempt, delivered identity, edge receipt and PBX route remain separate. | Documented Orange site management exposes call configuration and local site address, while the guide documents number formats and identity headers for its named architecture. Number inventory, port completion, provider attempt, delivered identity and PBX route remain separate. | Documented Vodafone says customers may retain existing numbers or obtain new ones, while the older Converged terms describe order-governed elements and a porting-authority process. Assignment, port completion, provider attempt, delivered identity and PBX route remain separate. | Documented Swisscom documents number portability, caller display, forwarding scenarios, number-block administration and PBX-based call allocation. Assignment, port completion, delivered identity, SBC receipt and PBX route remain separate. | Documented The current page lists number porting and the portal. Request, port completion, assignment, delivered identity, provider attempt and PBX route remain separate. | Documented Business Trunking provides fixed numbers and public telephony access. Allocation, implementation, acceptance, routing, provider attempt, delivered identity and completed call remain separate. | Documented The product page describes inbound numbers, porting, caller-ID controls and delivery by registration or direct IP. Ownership, port completion, assignment, provider attempt, PBX receipt and completed call remain separate. | Documented MaxoTel documents a portal option to send DID information to Asterisk or 3CX. Number assignment, provider attempt, delivered called number, PBX match and completed call remain unverified. | Documented The product supports transferred business numbers in most cases. Port completion, assignment, provider attempt, delivered number, PBX match and completed inbound call remain unverified. | Documented Symbio documents number allocation and porting across regional and Connect surfaces. Reservation, lease, port completion, provider attempt, PBX match and completed inbound call remain unverified. | Documented Customer terms document number blocks, working services, sharing constraints and portability. Allocation, programming, port completion, provider attempt, PBX match and completed call remain separate. | Documented Wholesale and current terms document Australian geographic DIDs, number provisioning and local number portability. Provider programming, PBX match and completed calls remain unverified. | Documented Smart SIP documents DDIs, local-number porting and per-DDI emergency locations. Allocation, activation, delivered number, PBX match and completed calls remain unverified. | Not verified The reviewed public record does not establish DDI allocation, port state, delivered format or routing for one account. | Documented Current schedules cover geographic numbers, service addresses, IPND and porting boundaries. One account number state, delivered format and completed route remain unverified. | Documented The schedule covers DID porting and configuration and warns of possible inbound interruption. One number state, delivered identity and completed route remain unverified. | Documented The Enreach Trunk (DE) record documents a number-block SIP URI example. Allocation, activation, delivered value and completed routing remain unverified. | Documented The product sheet lists directory services, calling-name handling and optional additional DIDs. Assignment, activation, delivered called-number format, route match and completed call remain unverified. | Documented NUSO documents local, toll-free, number inventory, activation and port tracking. Assignment, activation, delivered called value, route match and completed call remain unverified. | Documented The portal exposes trunk DIDs, ranges and a main or pilot number. Assignment, activation, delivered called value, forwarding state, PBX route and final answer remain unverified. | Documented Nationwide numbers, DID features and several forwarding controls are documented. Assignment, activation, provider attempt, delivered called value, PBX route and answer remain unverified. | Documented PSTN origination and add-on DIDs are documented. Number order, port, activation, provider attempt, delivered called value, PBX route and answer remain unverified. | Documented Telephone numbers and inbound calling are documented. Order, port, assignment, provider attempt, delivered value, PBX route and answer remain unverified. | Documented Telephone-number assignment, port preparation and DTO are documented. Order, port, provider attempt, delivered value, PBX route and answer remain unverified. | Documented SIP trunking, toll-free and call-path features are documented. Number order, port, provider attempt, delivered value, PBX route and answer remain unverified. | Documented DID numbers and existing-number retention are described. Order, port, storage, provider attempt, delivered value, PBX route and answer remain unverified. |
|---|
| Inbound failover | Documented Lower numeric priority is more important and weight distributes only among same-priority URLs. Current documentation lists response classes that stop advancement and a four-second no-response boundary; a Disaster Recovery URL is a later TwiML path after the SIP URLs do not succeed. | Documented IP and FQDN routes have documented sequential or round-robin routing and response-specific advancement; credential Connections use a separate registered-instance path. Preserve the actual attempts and results. | Documented IP-group priorities or round robin, number-level failover forwarding and post-route failure handling are distinct controls. Registration inbound calls are round-robin delivered from two registration regions; this is not established-call survival. | Documented Busy, Unreachable, No Answer and Max Capacity are distinct DID states. The reviewed pages do not publish one complete response-code, retry, precedence or restoration contract for every path. | Documented For Host and URI routes, Edge Strategy selects the first provider PoP and other PoPs may follow. That sequence is separate from the DID failover relationship, which selects another route object; public documentation does not publish one universal advancement matrix. | Documented DNS SRV supplies destinations inside one Static Endpoint attempt and one CDR. Trunk Groups can create separate attempt records and reroute only for configured outcomes, timeouts and available capacity; neither moves an established call. | Documented An inbound trunk can use one primary and one fallback URI. Plivo documents forwarding to fallback when the primary is unresponsive; the reviewed public pages do not promise advancement after every final SIP rejection. | Not verified The reviewed documentation does not establish a redundant PBX destination, qualifying response set, retry sequence or active-call survival. Confirm a supported design before calling a second resource automatic failover. | Documented Secondary and tertiary Build routes can act as failover, while Final Destination URI and call forwarding are separate controls. The public material does not publish one complete trigger, timer or restoration table. | Documented Regional termination FQDNs resolve to several Sinch public edges distributed across Availability Zones. The reviewed public reference does not establish a universal customer-destination retry matrix, callback retry policy, timer, restoration interval or established-call survival result. | Documented Customer SIP URIs accept unique priorities from 0 to 100, where 0 is highest, and timeouts from 2,000 to 20,000 ms; an empty timeout uses 5,000 ms. Equal priorities do not guarantee order. The reviewed public pages do not publish one universal SIP-response advancement matrix. | Documented Current gateway redundancy uses DNS SRV or gw4/gw5 proxies. Secondary trunk routing requires two trunks and a DID assignment. PSTN Forward bypasses the PBX and prevents PSTN Backup from engaging; Backup is conditional on no response or no active registration. The reviewed pages do not establish one universal timer, response matrix or active-call survival result. | Documented Voxtelesys documents prioritized destinations and a later Transfer using an outbound trunk group. The reviewed pages do not publish one complete response-code, timer, retry or restoration contract for every destination type. | Documented Voice Connector groups provide inbound PSTN routing across connectors, including different AWS Regions, while origination routes provide ordered and weighted customer-host delivery. AWS does not document these controls as established-call survival or customer-network independence. | Documented A Failover Add-on can send an inbound DID to a backup SIP URI when the main server is down. The reviewed public pages do not publish one universal trigger, response-code matrix, timer, retry count or restoration interval. | Documented Sequence and hunt-group destinations can provide later routing choices, but the reviewed pages do not publish one complete response-code, timeout, retry or restoration matrix. Verify actual attempts and caller treatment. | Not verified Bulk Solutions recommends its service hostname and publishes provider-network redundancy claims, but the reviewed setup material does not establish multiple customer inbound destinations, their priority or advance triggers. Provider infrastructure diversity is not PBX, access-circuit or active-call failover. | Not verified Voxbeam publishes provider-network redundancy and hot-standby claims, but the reviewed pages do not establish an ordered set of customer SIP destinations or its failure triggers. Provider infrastructure claims do not prove customer PBX, access-circuit, DNS or active-call failover. | Documented Network Down Forward is configured with Call Treatments, below any direct DID Forward. The public page does not define one universal health signal, response-code matrix, timer, retry count or restoration interval; verify the actual provider decision. | Documented A SIP URI can list optional terminal 400–699 response codes that end the call. The reviewed page does not publish one universal retry, alternate-target, timeout or restoration matrix for outcomes outside the effective list; preserve each attempt and decision. | Not verified The legacy portal reference gives a per-number failover precedence over a Location rule and documents DID, SIP URI or another Location with immediate or unreachable triggers. The current product page continues to advertise failover, but exact triggers, timers, responses, destinations and restoration require current documentation and observed tests. | Not verified Call forwarding is a selectable route, not documented failure-triggered advancement. Timeout, response handling, restoration and active-call survival require account instructions and controlled tests. | Documented DNS SRV or multiple proxies address SIPTRUNK gateway selection. Primary or Secondary Trunk assignment, PSTN Backup, unconditional PSTN Forward and voicemail are separate destination treatments. Current public material does not prove one recovery time or established-call survival result. | Documented Failover follows ascending trunk priority; round-robin distributes by each trunk weight. Soft failures do not mark a trunk dead, while hard codes are thresholded over an interval and invoke cooldown. SIP OPTIONS monitoring and all-dead last-resort behavior are separate controls. | Documented Commio documents ordered destination advancement, approximate no-response timers and response-specific handling. Preserve each attempt and recovery observation. | Documented SIPStation documents primary and secondary service gateways plus global or per-DID failover to an alternate ten- or eleven-digit PSTN number. This protects new inbound attempts under documented conditions; it does not establish active-call preservation. Test the intended outage, selected target, caller presentation, delay and restoration before relying on it. | Not verified Product material advertises redundant trunking and multiple fail-over options, but the reviewed sources do not establish one universal destination order, response matrix, timer, restoration rule or established-call survival result. | Documented Infobip Call Routing can try one to ten destinations in priority order, distribute entries at the same priority by weight and skip entries that are ineligible, Administrative Down or already out of service through OPTIONS polling. Connection behavior and the reachable-destination answer timeout remain separate. Preserve every route entry and per-leg result. | Not verified Zadarma permits several confirmed source IP addresses for outbound authorization, including main and reserve customer links, but that does not document inbound destination order, failure detection, retry rules or established-call survival. The reviewed public pages do not establish a customer-controlled inbound failover policy. Obtain the exact number-route behavior and test every approved fault and restoration path. | Not verified Multiple provider gateways support load balance and uptime, but the public pages do not define customer destination priority, retry timer, restoration or established-call survival. Accepting current provider sources is an ingress requirement, not proof of observed failover. | Documented ThinkTel separates Round Robin and Lowest Available binding selection from SureCall unavailable forwarding. SureCall can act when all bindings are down or when the PBX returns a documented trigger code. Preserve binding health, selection policy, response code, forward scope and destination. | Documented Endpoint Groups support top-down or round-robin selection and advance on non-response or documented SIP rejections. Per-DID off-net failover is a later, separately billed path after customer addresses are exhausted; Sangoma warns that groups with more than four addresses may consume the call timeout before DID failover. This is new-call routing, not established-dialog survival. | Not verified GoTrunk's network guide says its own data-centre failover can redirect traffic and tells customers to allow every listed signaling and media address. The reviewed pages do not establish ordered customer destinations, response-code triggers, timers, off-net forwarding or established-call survival. Separate provider-site continuity from customer PBX and access-path resilience, then obtain the exact account behavior before testing. | Documented Sequential hunting, percentage allocation, pooled sessions and the product sheet's built-in failover statement are different evidence. Preserve the configured plan, ordered trunks or percentages and each observed new-call leg without inventing one universal trigger, timer, SIP-code matrix, restoration sequence or established-call result. | Documented Provider-side DNS SRV or primary/backup proxy behavior and per-number Disaster-Recovery Routing are distinct. The latter can use as many as three alternate telephone-number or IP destinations. The public guide does not establish one universal timer, response-code matrix, restoration sequence or established-call guarantee. | Not verified Specialized BYOC pages describe two US points of presence and SIP OPTIONS monitoring, but the reviewed generic trunk pages do not establish customer destination priority, failure triggers, detection intervals or established-call survival for every account. Confirm those controls for the exact service and test only bounded new-call cases with a rollback path. | Documented The current product page lists time-of-day routing, ring timeouts, failover options and forwarding. Public sources reviewed do not establish one universal trigger matrix, timer, destination order, restoration interval or established-call survival result. | Not verified The dated data sheet describes AireCare manual, percentage and time-of-day rerouting; the dated infographic and current Long-Distance page describe DTO. The current order must establish which controls apply, their destinations, triggers and restoration behavior. | Documented The guide documents single- and multi-POP resilient trunks, active/standby, load-share and proportional inbound routing, timer- or OPTIONS-based recovery and optional inbound call rerouting after all trunks are unreachable. These are ordered configuration choices, not universal defaults or proof of established-call survival. Record peers, distribution mode, timers, diversion numbers and recovery criteria, then test bounded new-call failure cases with rollback. | Documented Gamma describes site-to-site trunk rerouting, SIP Trunk Call Manager destinations and a separate Gamma Inbound service. The public material does not prove the ordered trigger, first-call delay, recovery rule or established-call survival. | Not verified The reviewed public specification and X Series FAQ do not establish ordered customer destinations, failure triggers, retry responses, recovery behavior or established-call survival. A provider platform being available and a customer PBX having multiple addresses are not a failover contract. Obtain the current topology and run only provider-approved bounded new-call tests with rollback. | Documented Bell advertises dual virtual connections and automatic overflow or rerouting, while its portal guides document per-number Remote Call Forwarding. These are separate controls; the public material does not establish one universal trigger, SIP-code matrix, timer, precedence rule or established-call result. | Documented Exotel publishes primary and secondary outbound proxy FQDNs and allows FQDN or ordered inbound destinations. Those are new-call routing inputs, not proof of health-aware recovery, retry timing, provider diversity or established-call survival. | Documented Nextiva documents portal forwarding fail-overs and automatic redirection when a PBX is offline. The reviewed pages do not define every qualifying SIP response, timeout, retry interval or the behavior of an established call, so those controls require account-specific confirmation and bounded testing. | Documented Intermedia documents per-number failover to an alternate ten-digit destination when a location is detected as unavailable, with continued monitoring and restoration to the original route. The public pages do not enumerate the complete probe, response, timer or established-call contract, so perform a bounded account-specific test. | Documented The one-sheet advertises PSTN failsafe routing, traffic distribution through multiple IP addresses, geo-redundant routing, multiple SBCs and customer redundancy through multiple SIP or PRI trunks. It does not establish one account's triggers, priority, timers, response handling, restoration or established-call survival. Treat each mechanism as a separate new-call control until an authorized test proves its scope. | Documented GTT 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. | Documented Tata describes a geo-redundant centralized architecture and automatic IP routing during network problems. Those service-level statements do not define the customer-edge peers, failure codes, timers, route order, independence or established-call behavior. Require the account design and an authorized new-call recovery test before treating the service as resilient end to end. | Documented Spectrum documents Alternate Routing to a different destination when a location is unavailable and Trunk Overflow for peak volume. Those are distinct continuity controls and do not establish every trigger, destination, timer, restoration rule, customer-access dependency or established-call outcome. Confirm the ordered options and test approved new-call cases separately. | Not verified For a trunk group, simultaneous sends to every switch and selects the first answer; sequential begins with the first ordered switch and rolls only when it is unreachable. Multiple stored targets do not prove the trigger, cancellation behavior, recovery or established-call survival. | Documented Package-level redundant trunks, usage-profile selection and switched-number translations are distinct. Forward is unconditional; number Failover applies when the trunk is not responding to INVITEs and can take five to ten minutes after submission. The public material does not define one universal timer, retry-code or established-call contract. | Documented Zayo markets an owned network, geo-redundancy, disaster-recovery options and portal reroutes. Those statements do not establish the account's route order, retryable SIP responses, timers, destination health check, restoration sequence, access-path independence or survival of established calls. Convert the contracted design into coordinated new-call tests. | Documented Older guides distinguish Call Forward Always, Call Forward Not Reachable, Route Exhaustion and geo-redundant PBX routing; provider-core diversity is another layer. The current page does not publish one universal trigger, timer, retry-code matrix, precedence or restoration sequence. | Documented The online service document describes optional VARRS mirrored capacity on a secondary Verizon SBC HA pair. The rates page separately lists PBX Group Unreachable or Call Forward Unreachable redirection. These mechanisms, customer access diversity and PBX recovery remain separate evidence without a universal trigger or timer. | Documented Rogers separately documents SIP Peer Failover, Peer Load Balancing, Peer Overflow and Emergency Redirect; a branded sheet also uses Access Failover, Enterprise Failover and DID Number Re-route labels. Map the signed order instead of assuming equivalence, inclusion, triggers, timers or precedence. | Documented Optional hosted Auto Attendant, Voicemail and Call Forwarding are advertised for continuity when the PBX or office is unavailable. The service guarantee applies to underlying infrastructure, and neither statement proves that one order includes an alternate destination, diverse customer access or established-call survival. Confirm signed options and test approved new-call failures separately. | Documented The current materials advertise geo-redundant infrastructure, multi-site deployments, custom routing and redundant solution options. They do not establish that a particular order includes diverse customer access, automatic alternate destinations, retryable responses, a restoration sequence or established-call survival. Capture signed routing policy and run an approved new-call failure test. | Not verified The reviewed trunking pages do not establish one automatic PBX failover, alternate destination, DNS failover, response-code retry or established-call survival design. Obtain the account's current routing and continuity controls and run an approved new-call test; do not import sipgate business-user routing features into the trunk record. | Documented Part B describes optional network overflow through up to three defined destinations, while the product page discusses centralized service and resilience. Overflow policy, access diversity, alternate Site, PBX failover, new-call recovery and established-call survival remain separate. Record the ordered option and run an approved failure exercise before claiming resilience. | Documented HKT describes built-in redundancy and disaster recovery. The public page does not define the topology, trigger, recovery objective, established-call behavior or customer-side dependency, so treat those as design and test questions. Record the ordered architecture and run an approved failure exercise before making a continuity claim. | Documented Gradwell describes cloud deployment, multiple carriers, network resilience, monitoring and forwarding flexibility. The public pages do not publish one failover topology, trigger, retry response, restoration sequence, customer-access dependency or established-call behavior. Convert the ordered design into a bounded new-call failure test before making a continuity claim. | Documented VoiceHost advertises a resilient network and multiple data-centre and interconnection relationships, but the reviewed pages do not define one trunk failover trigger, retry sequence, restoration order, customer-access dependency or established-call outcome. Bind continuity to the ordered design and a provider-approved new-call failure exercise. | Documented The dated administrator guide documents Linear, Round Robin, % Allocation and Most Idle routing plus separate Unreachable Destination and Forward Always controls. Preserve effective account configuration and observed new-call legs without inventing a universal probe, SIP-code matrix, timer, precedence rule, restoration sequence or established-call result. | Documented Voipfone documents Always, closed, busy, no-answer and PSTN-failover controls. The reviewed pages do not publish one complete trigger, timer, retry, precedence or restoration contract for every account. | Documented Telekom describes mobile access backup, a second access path and separately configured redundant SIP-trunk service options. These are different continuity layers. None establishes the ordered DNS or proxy sequence, trigger, customer-LAN dependency, restoration order or established-call outcome. Bind the current design to a provider-approved new-call failure exercise. | Documented Iristel 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. | Documented TELUS service terms distinguish additional trunk groups for connectivity resiliency, customer-equipment resiliency and carrier SBC geo-redundancy. The public pages do not establish one trigger, timer, selection rule, restoration sequence or active-call result. | Documented Item 500.23 describes RTM overflow within the same serving central-office switch and separately describes customer-requested Emergency Call Redirection to a predetermined alternate business location. Neither establishes automatic access failover, universal triggers, active-call survival or restoration. | Documented Cogeco advertises physical SIP geo-redundancy and automatic failover or reroute for inbound and outbound voice traffic. The public page does not publish one account’s triggers, timers, route order, established-call behavior or restoration sequence. | Not verified The product page describes global infrastructure and a fully redundant network, while a separate public status page exposes platform-level operational reporting. Neither source defines one trunk's ingress or egress peers, route priority, failure responses, timers, customer-access diversity, alternate destination, established-call behavior or recovery order. Bind resilience to the order and implementation handoff, then validate new-call behavior under an approved exercise. | Documented Failover/Overflow, Load Balancing, Bursting, Unreachable Destination and optional Call Forward Not Reachable are distinct controls. Preserve entitlement, trigger, source group or number, target group or ten-digit destination, capacity state and observed new-call result without inventing one universal timer or SIP-code matrix. | Not verified The 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. | Documented OnSIP documents rerouting an inbound call to a selected external number after a configured ring time and warns that PBX inbound rules may conflict or pre-empt it. Preserve provider timer, PBX response, local forwarding, external attempt and loop prevention separately. | Not verified The reviewed pages do not publish one automatic trunk failover, alternate registrar, DNS priority, PSTN reroute or established-call survival design for the selected order. The portal's fallback number is a caller-ID value used when the PBX sends no acceptable calling number; it is not a call-delivery failover destination. Record resilience, triggers, timers, route order and restoration separately and test an approved new-call failure case. | Documented Webex Calling route groups can contain one to ten trunks. Equal-priority trunks are load balanced, and an unavailable higher-priority set can fall through to a lower priority. That policy does not prove diverse access, gateway, site, certificate, Cloud Connected PSTN provider or power, and it does not establish survival of an active call. Record the actual trunks, priorities, health evidence, failure trigger and restoration order. | Documented Voice routes can include several SBCs, and Direct Routing considers SIP OPTIONS health. Microsoft describes demoting a gateway that has not sent OPTIONS within the expected three-minute window; equal healthy gateways can be distributed. Demotion is route selection, not proof of diverse carriers, sites, certificates, power or access, and it does not establish survival of an active call. | Not verified Google lets an administrator add multiple SBCs and identify the active hostname for a high-availability pair. The reviewed pages do not establish generic load sharing, failure timers, access diversity, carrier rerouting, DNS behavior or survival of established calls. Record the certified design, active and standby roles, failure trigger, observable route and restoration sequence. | Documented Zoom supports regional trunks to customer SBCs and Internet or private-circuit connectivity. Internet calls may route to an alternate Zoom data center within the region. Those platform choices do not establish customer SBC high availability, carrier rerouting, access diversity, route priority, detection timers, restoration order or established-call survival. Document every Zoom, customer and carrier failure domain and test only the accepted design. | Not verified The public overview describes phased migration and rollback flexibility, but the reviewed pages do not publish one customer's alternate gateway, carrier reroute, DNS behavior, health trigger, route priority, timer, access diversity, established-call treatment or restoration order. Migration rollback is not automatic call failover. Document and exercise the accepted new-call continuity design across RingEX, gateway, access and carrier failure domains. | Documented The carrier questionnaire calls for SIP OPTIONS, 503 handling and sequential failover, while Genesys publishes regional proxy and media addresses. Those are interface and planning requirements, not proof of the selected carrier's target order, health thresholds, timer, capacity, geographic diversity, restoration sequence or established-call survival. Record and test only the approved new-call failure cases. | Documented Outbound voice routes match called-number regular expressions. SBCs within the same route priority are tried in random order; lower-priority routes are considered after higher-priority SBCs are unavailable. Microsoft documents failover to the next SBC only for SIP 408, 503 and 504 responses. Record route priority, pattern, health, response and carrier behavior; do not infer failover for every code or established calls. | Documented Pure IP publishes geo-redundancy, intelligent routing and failover options, while Hypernetwork is a separate optional US inbound-DID resilience service. Those statements do not establish the ordered alternate targets, triggers, timers, coverage, established-call result or restoration procedure. Map and test only the contracted path. | Not verified A dated Ooma brief illustrates multiple carrier inputs and customer access choices, but it does not establish the selected alternate targets, triggers, timing, established-call outcome or restoration. Test only the contracted design. | Documented A later stored Trusted IP is a sequential SIP destination. Automatic Offline forwarding is a distinct rule that sends calls to a chosen telephone number when devices cannot connect or are offline. The reviewed pages do not establish one universal trigger timer, response matrix, retry count or restoration interval. | Not verified The product page describes combining hosted routing features with an on-premises PBX, but the reviewed trunk pages do not establish trunk-priority, health-check, automatic alternate-PBX delivery, detection or restoration semantics. Qualify any FQDN behavior, alternate call route, forwarding target, timing, caller identity, capacity, charges and return-to-primary path separately. | Documented Voiceflex describes optional automatic failover that sends calls to another PBX when the primary PBX does not respond or regularly register. It states that failover is configured at SIP-account level rather than individual-number level. This does not establish detection timing, restoration timing, active-call survival, capacity or caller-identity behavior; qualify new-call routing and return to primary with an approved test. | Documented Spitfire documents geographically diverse SIP nodes, outbound resiliency and options to divert calls to a predetermined alternate number or combine the service with an independent backup path. These descriptions do not establish detection or restoration timing, active-call survival, capacity or identity behavior for the selected order. Separate SIP-node, number-diversion and access-circuit tests. | Not verified 2talk describes scalable trunks and publishes network incident history, but the reviewed material does not establish account-specific alternate delivery, detection or restoration timing, capacity on a backup path, active-call survival or return-to-primary behavior. Treat portal forwarding, PBX redundancy, access resilience and provider recovery as separate mechanisms and test only with an approved plan. | Documented peoplefone documents provider-side forwarding when a line becomes offline after a recommended 180-second re-register period, with exact-number or prefix filters and a stated maximum of 300 forwardings per SIP line. That does not prove detection time, active-call survival, alternate capacity, caller identity or restoration behavior for an account. Test new-call failure and recovery separately. | Documented A&A documents multiple targets, per-target delay and up to ten Also Ring numbers. It also warns that remote voicemail can answer an external leg unexpectedly. These are call-routing tools, not proof of active-call survival, ordered resilience, answer confirmation, restoration time or alternate capacity. Test one approved failure and recovery path. | Documented Zen says calls can automatically reroute to another site, device or team if an office goes offline. The reviewed material does not publish the trigger, detection interval, precedence, alternate capacity, active-call behavior or return-to-primary sequence. Treat this as an available product capability whose account configuration and observed new-call behavior still require evidence. | Documented SureVoIP says a number can support up to five destinations, configured through support, and that each later destination is attempted when the preceding one times out. Its guide explicitly says Busy and Unavailable do not count. The page does not publish the timer, attempt count, active-call behavior or return-to-primary sequence, so those remain order- and observation-specific. | Documented Magrathea says SIP Resilience lets the client nominate several IP addresses, probes each address several times a minute, removes an address from the pool when a failure is detected and returns it when it responds again. The page does not define the probe method, threshold, call-distribution algorithm, active-call behavior or exact restoration timing. Confirm those boundaries for the selected service and test only approved new calls. | Documented NFON documents Premium multi-PBX modes for Primary/Backup, Round Robin and Forking. It separately documents a PSTN backup service when PBX endpoints are unreachable. These controls have different triggers and destinations: preserve the selected mode, endpoint priority or eligibility, registration or fault state, number-routing backup and new-call result. The public documents do not establish active-call survival. | Documented The product page discusses NAPTR and SRV routing, while the service schedule separately documents portal diversion and non-registration SMS alerts. Confirm the selected DNS names and account controls; none proves active-call survival. | Not verified The reviewed public material recommends the sip.t38fax.com service name rather than fixed addresses and publishes multiple signaling and media ranges, but it does not establish customer-controlled destination priority, retry policy, active-session survival or a recovery objective for one trunk. Preserve DNS, the selected edge, transaction results and a provider-approved failure test before claiming failover. | Not verified The SIP-trunk page advertises scale and burstable functionality, but the reviewed public pages do not define alternate-PBX delivery, health checks, retry responses, detection and restoration timers or established-call behavior. Bind every continuity claim to the ordered design and an approved new-call failure and recovery exercise. | Not verified The product page advertises built-in redundancy and failover across an existing PBX or b-hive platform. It does not define alternate targets, health checks, retry responses, detection and restoration timers, route priority or established-call behavior. Attach every continuity claim to the ordered topology and an approved new-call failure and recovery exercise. | Documented The 3CX guide permits a primary public IP and an optional failover IP in SIPcity peering preferences. The reviewed material does not define health checks, retry responses, detection or restoration timers, route priority, established-call survival or whether the alternate is used for every failure mode. Bind continuity claims to the saved portal state and a provider-approved new-call failure and recovery exercise. | Not verified Toku describes redundant carrier infrastructure and a multi-server Teams service. The reviewed pages do not define customer trunk targets, DNS behavior, health checks, retry responses, routing priority, timers, established-call survival or restoration. Treat platform redundancy and a selected interconnect continuity design as separate evidence; qualify new-call failure and recovery only in a provider-approved window. | Documented LoopUp lets the administrator choose round-robin distribution or ordered failover across a primary and optional additional customer endpoints. It also publishes regional platform endpoints and recommends DNS because addresses can change. The reviewed pages do not define every health signal, response class, retry timer, established-call survival or restoration interval. Prove each new-call path in a provider-approved window. | Not verified The reviewed public Localphone pages do not define redundant registrars, DNS failover behavior, retry timers, alternate delivery, restoration order or established-call survival. Treat registration recovery, inbound rerouting and user fallback as separate controls and qualify them only with account-specific provider evidence and an approved exercise. | Documented The service page recommends resilient access such as primary plus backup broadband or 4G/5G and says resilience is designed around the customer risk profile. The product schedule measures provider availability at its point of demarcation and excludes customer access, network and equipment causes. Exact SIP target failover, detection, rerouting and restoration remain unverified. | Documented The service page describes personalized forwarding and a virtual attendant that can front calls during weather events or a phone-system outage. These are routing features, not proof of SIP target health detection, access diversity, PBX survival or established-call continuity. Record each ordered control, trigger, destination, restoration rule and approved new-call test. | Documented The legacy PDF tied standard trunk failover to Redcentric-provided circuits and required professional-services design for third-party-network failover. Treat that as a historical acceptance question only: document today's circuits, route diversity, trigger, target order, recovery and commercial coverage from the current order. | Documented The product page describes flexible routing, geo-redundant infrastructure and automatic failover to backup carriers. It does not define the selected account topology, trigger, target order, DNS dependency, established-dialog behavior or recovery. Obtain the current route design and observe only authorized failure tests. | Not verified Status changes and callback evidence are documented, but no universal selected-account retry order, alternate proxy, established-call behavior or recovery objective is stated. Preserve registration transition and each call outcome separately. | Not verified The reviewed sources do not define universal DNS target order, redundant registrar behavior, customer-edge failover, retry timing, alternate inbound routing or established-dialog survival. Webhook fallback and call-status callbacks are application controls, not proof of SIP-path resilience. Obtain and exercise the approved design before relying on an alternate path. | Not verified No universal customer failover topology, target order, trigger, established-dialog behavior or recovery sequence was verified. A note about multiple devices or clone devices for phone-line service is not a SIP-trunk redundancy design. | Documented The schedule states one trunk routing group per point of interconnect unless the order specifies otherwise. Provider-network redundancy does not establish customer failover behavior. | Documented Portal controls include Immediate, Busy/No Answer, Unavailable and Selected Callers forwarding. The quick-start separately lists trunk overflow to a telephone number, multi-endpoint failover and load sharing across at most two endpoints. The selected order and portal object govern. | Documented Cloudli documents Settings → Service Continuity with a backup destination and per-number handling, and describes IP-enabled failover strategies. Trigger, scope, provider attempt, forwarded result and restoration remain unverified until observed. | Documented The Patton guide contains guide-specific OPTIONS and SIP-response rerouting behavior. Trigger, alternate selection, observed attempt, result and return to primary remain unverified until demonstrated for the current project. | Documented The current Evolved Voice page describes end-to-end failover through Customer Endpoint Diversity and emergency diversion. Topology, health test, trigger, alternate selection, completed result and return to primary remain unverified. | Documented Swisscom documents core-network forwarding, Multi SAP, Multi PBX, Multi Server, trunk failover and availability options. Ordered topology, trigger, alternate selection, completed result, established-call behavior and restoration remain unverified. | Documented The current comparison refers to backup and emergency routing. Ordered topology, trigger, alternate, completed call and restoration remain unverified. | Documented The CSD names Basic-Single, Single, Basic-Multi and Secure-Multi. Selected mode, path independence, trigger, alternate call and restoration remain unverified. | Documented The product page describes Divert on Down and the network page describes geographic redundancy. Configured destination, trigger, selected alternate, completed call and restoration remain unverified. | Documented The portal describes Offline diversion when a device is not registered. Configured destination, trigger, completed alternate call, restoration and established-call behavior remain unverified. | Not verified The reviewed trunk records do not establish account-level failover, alternate destinations or established-call behavior. Public outage information and a fault ticket remain context, not restoration proof. | Documented Symbio announced an Australian dual-network option with primary/backup or balanced routing. Account entitlement, trigger, selected path, completed calls, established-call behavior and restoration remain unverified. | Documented Business Continuity and BRS+ are documented optional packages; the product page also describes optional Shared Capacity. Account entitlement, configured policy, trigger, call result and restoration remain unverified. | Documented Current terms distinguish Emergency Diversion, Dual Voice Trunk and Dual Exchange Homing. Entitlement, configuration, trigger, call result, feature preservation and restoration remain unverified. | Documented SIP Advanced distinguishes Multi-Site and Dual Circuit options; Smart SIP documents 4G as possible primary or failover Access. Order, path diversity, trigger, call result and restoration remain unverified. | Documented The product page describes rerouting to a data line or PBX redirection to mobile during disruption. Inclusion, trigger, target, call result and restoration remain unverified. | Documented Vocus support describes whole-trunk Call Forward Always and Unreachable Destination controls. Entitlement, scope, target, trigger and completed calls remain unverified. | Not verified The reviewed records do not establish one included SIP-trunk failover design. Outage posts, alternate access, provider routing and PBX policy remain separate. | Documented Business and reseller material describe rerouting and redundancy. Entitlement, trigger, target, diversity, completed calls and restoration remain unverified. | Documented MetTel describes six geographically redundant North American data centers. One order’s ingress diversity, DNS or route behavior, customer-access diversity, established-call survival and completed failover remain unverified. | Documented NUSO documents built-in failover and NUSOflex for inbound PSTN and local-service impairment. One order’s enrollment, trigger, alternate destination, action, established-call behavior and restoration remain unverified. | Documented Always, Unreachable, phone-number forwarding, same-tenant reroute and optional Enterprise Trunking are separate controls. Enrollment, trigger, alternate answer, established-call behavior and restoration remain unverified. | Documented CFNR, Trunk Group Call Forwarding, Standard DTO, Enhanced DTO and managed-SD-WAN active/active continuity are distinct. Entitlement, trigger, alternate answer, established-call survival and restoration remain unverified. | Documented Cloud redundancy and automatic-failover claims are documented. Ordered triggers, targets, timers, access survival, alternate answer, established-call behavior and restoration remain unverified. | Not verified Network redundancy is marketed, but one order trigger, target, access survival, alternate answer, established-call behavior and restoration remain unverified. | Documented Trunk to Trunk and Trunk to Number Redirect are documented for inbound redirection during impairment or exhaustion. Trigger, target, access survival, alternate answer and restoration remain order- and observation-specific. | Documented DTFO and redundant-solution language are published. Entitlement, trigger, alternate target, access survival, alternate answer, established-call continuity and restoration remain order- and observation-specific. | Documented Redundant and non-redundant access-loop scopes are distinguished. Ordered design, alternate path, call delivery, established-call survival, media and restoration remain account- and observation-specific. |
|---|
| Pricing model | Documented Usage-based calling, separate number rental and optional features; destination, country and committed-use terms affect cost. | Documented Per-minute calling and an inbound channel option are published. Confirm included traffic, number costs, destination rates and optional charges. | Not verified Usage-based service is advertised. The current account rate deck, minimums, support charges and complete contract terms are not verified. | Documented The service describes pay-as-you-go usage; obtain the number, destination, emergency and optional-feature charges for the actual traffic mix. | Documented The pricing page lists metered voice, number and E911 examples plus volume, monthly-plan and annual-term alternatives. These are dated public inputs rather than a quote; destination, number type, emergency service, forwarding, taxes, commitment and renewal terms require the applicable rate deck and order. | Documented Outbound termination is per-minute; inbound capacity can be metered or flat-rate channels. Number rental, destination rates, minimum balance and optional tier terms must be included in an actual estimate. | Documented The service is presented as pay-as-you-go per-minute trunking without channel or port fees; destination rates, number rental, taxes, support and account terms require a current quote or rate review. | Documented SignalWire publishes usage rates, but the selected numbers, destinations, features, throughput, taxes, support and total cost remain account and date specific. A public rate page is not a quote or availability promise. | Not verified Obtain dated account terms for numbers, routes, calls, features, support, emergency services, taxes and fees. No price was tested or normalized. | Not verified The Elastic SIP Trunking page describes pay-as-you-go operation, while exact rates, number charges, emergency fees, taxes, support and commitments remain account- and region-specific. A dated quote is required. | Not verified Exact calling rates, number charges, emergency fees, taxes, support and commitments were not established for a specific account, country and date. Use a dated rate deck or quote for the intended traffic mix. | Not verified The provider describes channel and minutes-package rate-plan structures, but exact channels, minute inclusions, number charges, emergency fees, international rates, taxes and support terms require a dated account quote. | Not verified The public pricing page shows metered and unlimited structures, while a dated service-order template contains term, line, number, emergency and usage elements. Exact inclusions, minimums, rates, taxes, surcharges, support and commitments require a dated quote for the intended account. | Not verified AWS publishes pay-per-use inbound and outbound minute rates plus monthly number charges, with optional services and other AWS resources billed separately. Exact destinations, number types, taxes, storage, streaming and current account charges require the dated rate table and Cost Explorer review. | Documented The FAQ describes a prepaid account, renewals and add-ons charged on the fifteenth day of the month in UTC, service blocking after an insufficient-balance notice and possible number cancellation five days later. It also states a three-month DID minimum. These are dated public rules, not an account quote, current balance outcome or total-cost estimate. | Not verified Public pages describe destination- and route-based outbound rates, country- and number-based DID charges and account-level minimum commitments. Exact rates, increments, taxes, surcharges, channel charges, support and contract terms require the current portal and a dated quote. | Not verified Bulk Solutions publishes usage-oriented product and price examples. Exact rates, increments, number charges, emergency and messaging fees, taxes, surcharges, minimums, support and contract terms require the current portal or a dated quote rather than a copied marketing figure. | Not verified Public pages distinguish outbound route classes, DID-only service and channel-based inbound capacity. Exact rates, increments, number charges, minimums, taxes, surcharges, support and contract terms require the current account portal or a dated quote. | Not verified A forwarded call has an incoming and outgoing leg. The incoming service and outgoing plan determine their respective charge treatment; exact rates, included minutes, taxes and account limits require current account evidence. | Not verified The May 14, 2026 support article lists a $24.99 monthly recurring charge for newly purchased trunks plus per-minute usage. That dated public figure is not a quote: number charges, destinations, increments, taxes, surcharges, optional services and negotiated terms require the current account order. | Not verified Public pages describe subscription call paths, metered calling, hybrid use and optional bursting. Published figures are not a quote; number charges, included destinations, fair-use terms, international rates, fax, messaging, emergency service, taxes, surcharges and contract terms require the current account order. | Documented LES.NET publishes Canadian-dollar account, DID, usage, conferencing and fax components. Treat them as dated public snapshots and obtain a current order including taxes and optional services. | Documented The current public page lists a per-channel unlimited plan, scalable minute-and-DID bundles, DIDs, toll-free blocks, messaging and fax products. It also says additional fees, surcharges and terms apply. Treat the page as a dated planning snapshot and confirm destination coverage, taxes, regulatory fees, overage, porting and optional services in an order. | Documented CarrierX provides account-aware Rating APIs for inbound and outbound voice, SMS and MMS, plus DID tier rates and billing records. Treat returned effective rates, billing increments, minimums and subscriptions as dated account inputs; documentation examples are not quotes and public samples are not a complete fee schedule. | Not verified Obtain dated account terms for numbers, calls, routes, E911, porting, support, taxes and fees. No price was tested or normalized. | Conflicting documentation SIPStation's public marketing and store surfaces showed different current amounts during this review. Do not treat either as a durable quote. Price the exact account at checkout, including channels, DIDs, outbound T.38, E911, messaging, international use, taxes, top-ups and any support or commitment terms. | Not verified Number API records include activation, monthly and inbound-minute fields, while trunk controls can include maximum call cost. Example values are not a current quote; preserve the actual transaction, route charges, add-ons and taxes. | Documented Infobip documents metered and US unlimited channel plans. Metered service combines a channel charge with usage-rated traffic; the US unlimited plan excludes usage charges for domestic outbound traffic subject to fair use, while inbound and other-country traffic remain usage-rated. Capture the current quote, channel quantity, destination rates, numbers, taxes and fair-use terms. | Documented Zadarma publishes pay-as-you-go and bundled plans, with outgoing rates, included minutes, numbers and channel allowances varying by region and billing term. A displayed plan is not an account quote. Preserve the dated plan, destination rates, billing increment, included-use conditions, number fees, taxes, currency and renewal term. | Documented DIDforSale publishes pay-as-you-go, channel-based inbound, toll-free, messaging and unlimited-use examples with tiered commitments. Displayed figures are dated public list prices, not an account quote. Preserve direction, number and channel fees, destination rates, billing increment, acceptable-use terms, commitment, taxes and renewal conditions. | Not verified The reviewed public service and help-centre pages do not publish a complete current SIP-trunk rate card. Channel commit, maximum channels, DIDs, destinations, emergency service, forwarding and professional services can affect the account. Obtain a dated quote and preserve currency, billing increment, commitments, taxes, usage rates and renewal terms. | Not verified The public service pages describe wholesale origination, termination and optional features but do not publish a complete current account rate card. Obtain a dated quote or portal export covering numbers, inbound and outbound destinations, billing increments, failover, E911, messaging, porting, taxes, commitments and renewal terms. | Not verified GoTrunk advertises per-second billing, no setup fee and no contract, and its portal exposes destination rates. The number guide also notes a monthly charge for added incoming channels. These statements do not establish an account's current numbers, destinations, currency, billing increments, commitments, porting, emergency, support, taxes or renewal terms. Preserve a dated quote and rate export for the actual traffic mix. | Not verified Lumen distinguishes usage-based trunks from flat trunks and describes pooled sessions, but does not publish a complete current rate card for one account. The end-of-sale FAQ says out-of-term rates may change and Lumen cannot commit to holding them. Obtain dated contract terms for sessions, numbers, usage, toll-free service, changes, porting, emergency service, taxes, support and renewal. | Not verified The reviewed guide and public legal index do not publish a complete current SIP Trunking quote. Obtain dated terms for call paths, usage, numbers, toll-free service, international calling, off-net disaster-recovery forwarding, E911, porting, taxes, support, restrictions, renewal and termination. A real-time billing portal is operational evidence, not a general rate card. | Not verified Public rate and FAQ pages displayed usage, number and E911 amounts when reviewed on September 29, 2026, but their summary language is not a complete account quote and some headings describe rates as starting values. Obtain dated terms for directions, destinations, increments, numbers, emergency service, porting, taxes, fraud controls, support, commitments, renewal and termination. | Not verified The service page describes SIP trunking but does not publish a complete current account quote. Obtain dated terms for channels, inbound and outbound traffic, destinations, numbers, porting, failover forwarding, emergency service, taxes, support, commitments, renewal and termination. Do not transfer wholesale or deprecated hosted rate documents to the current product. | Not verified The current product page describes flexible pricing but does not publish a complete account quote. Older state tariffs and unrelated Long-Distance rate descriptions are not a current universal price. Obtain dated terms for trunks, channels, directions, destinations, numbers, porting, E911, failover, encryption, taxes, support, commitment, renewal and termination. | Not verified The reviewed public product and technical pages do not provide a complete account quote. Obtain dated terms for access, trunks, concurrent calls, call starts, traffic, destinations, numbers, porting, transcoding, encryption, resilience, emergency service, monitoring, taxes, support, commitment, renewal and termination. A technical default or marketing statement is not a billable entitlement. | Not verified The product page contains indicative figures while the code points customers to their contract and current price information. Obtain dated terms for access, channels, calls, numbers, porting, cloud features, support and termination. | Not verified The FAQ says usage billing begins when a call receives SIP 200 OK and rounds up to the next minute, and that CDRs appear on the monthly bill. It does not provide a complete current rate card or account quote. Obtain dated terms for trunks, numbers, destinations, minimums, rounding, emergency service, support, taxes, commitment, renewal and termination. | Not verified Bell publishes an optional Universal Trunk Group claim and a separate provincial 9-1-1 fee table, but neither is a complete SIP Trunking quote. Obtain dated terms for access, sessions, numbers, usage, overflow features, emergency service, support, taxes, commitments, renewal and termination. Do not convert the public 9-1-1 fee page into total service pricing. | Not verified The reviewed technical documentation requires an upgraded, KYC-complete account but does not provide a complete current trunk quote. Obtain dated terms for setup, numbers, usage, call-start or concurrency changes, support, taxes, commitments, renewal and termination. Do not convert a technical rate limit or Exophone example into commercial entitlement. | Not verified Nextiva publicly describes metered and unmetered plans and directs buyers to a personalized quote. A displayed web offer does not establish the current account price, included destinations, fair-use terms, number fees, porting, taxes, support, renewal or termination terms; obtain a dated quote and contract. | Not verified The public pages describe flexible pricing but do not establish one account's current charges. Obtain a dated quote covering locations, channels, bursting, numbers, usage, failover, E911, porting, support, taxes, commitments, renewal and termination. | Not verified Peerless publishes broad metered, unlimited, inbound-charge and flexible-billing claims, but those pages are not a current quote for a specific account. Obtain dated terms covering channels, activation, usage, numbers, E911, toll-free service, porting, support, taxes, commitments, renewal and cancellation. | Not verified The 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. | Documented Tata advertises volume-based pricing and the service schedule permits order-specific implementation charges. No complete current public rate card was found in the reviewed sources. Price the actual countries, directions, number types, access, commitments, emergency services, surcharges and taxes from the current order rather than marketing savings examples. | Not verified Spectrum describes one monthly transaction covering the connection, DID numbers, long-distance plan and network interface, with scalable capacity and Minutes of Use. The reviewed pages do not provide a complete current rate card. Obtain a dated quote for sites, access, call paths, numbers, usage, toll-free service, continuity options, emergency features, equipment, taxes and contract terms. | Not verified IDT Express describes pay-as-you-go voice and account rate information, but route, DID, porting, feature, minimum-commitment, tax and support terms remain time- and account-specific. Use a dated portal export or quote; public promotional credits and market-language are not a complete production cost model. | Not verified The portal distinguishes bundle, usage and outbound-only customers and supports billing and usage reports, but the reviewed public material is not a complete current rate card. Obtain dated contract terms for ports, minutes, numbers, porting, emergency service, messaging, support, minimums, taxes, renewal and cancellation. | Not verified The reviewed public sources promote cost control but do not provide a complete current SIP Solutions rate card. Obtain a dated quote or contract for sessions, minutes, numbers, porting, access, emergency service, protected transport, support, minimums, taxes, renewal, service levels and cancellation. | Not verified Cox states that SIP Trunking pricing varies and directs customers to request a tailored plan. Obtain a dated quote or contract for sessions, minutes, numbers, porting, access, E-SBC or equipment, emergency service, support, minimums, taxes, renewal, service levels and cancellation. | Not verified The IP Trunking page directs buyers to sales and does not publish a complete account price. Obtain a dated quote and signed schedule for sessions, usage, numbers, porting, access, managed edge, continuity options, emergency service, support, minimums, taxes, renewal, service levels and cancellation. Do not transfer Business Digital Voice per-line offers to enterprise IP Trunking. | Not verified The April 2021 schedule describes per-session and monthly billing, usage charges, optional features, access and termination terms, but it is not a current quote. Obtain a dated proposal and signed agreement for sessions, DIDs, usage, access, equipment, continuity, emergency service, support, minimums, taxes, renewal and cancellation. | Documented The public page describes a flat monthly rate based on concurrent call sessions, a three-session minimum, included US and Canada calling, and optional continuity, calling-name and bursting features, but directs buyers to obtain a quote. Use a dated quote and signed schedule for usage scope, numbers, ports, access, equipment, add-ons, emergency service, taxes, support, renewal and cancellation. | Documented Current material advertises usage-based or unlimited choices and says unlimited service is subject to the Acceptable Use Policy; an older feature sheet shows multiple package patterns and six-second billing. These are not a current account price. Use a dated quote, service order, agreement and AUP for paths, DIDs, ports, usage, international and toll-free traffic, emergency service, access, support, taxes, renewal and cancellation. | Documented The current public tariff page lists monthly Starter, Regular, Plus and Enterprise 10 charges exclusive of VAT, while the March 27 plan guide also lists Developer, Enterprise 25 and Enterprise 50. Pricing and inclusions can change and the two public tables are not identical. Use the dated account order and invoice for plan, incoming lines, outgoing limits, numbers, ports, calls, VAT and cancellation. | Not verified The public terms place charges, optional features, reconfiguration, commitments, invoicing and termination in the Order and also describe traffic-profile and fair-use conditions. No universal current rate card or account quote was established. Obtain dated country, Site, access, channel, number, usage, support, tax and term records before comparison. | Not verified The public product page provides a sales enquiry rather than a complete dated rate card. Obtain a written quote that separates access, channels, numbers, usage, optional features, installation, support, taxes, term, reconfiguration and termination before comparison. | Documented Gradwell advertises PAYG and bundled options and says cost depends on requirements and usage. The public pages do not provide a complete current account rate card. Use a dated quote for channels, call starts, minutes, numbers, porting, connectivity, installation, options, support, taxes, term, renewal and cancellation. | Documented VoiceHost publishes pay-as-you-go, bundle and channel-based options and notes that out-of-bundle and international usage can be charged separately. Public examples are not a complete account price. Use a dated quote or portal tariff for channels, call starts, usage, numbers, porting, options, support, taxes, term, renewal and cancellation. | Documented AT&T says customers can change concurrent call channels and pay for the lines they need, with optional calling plans and on-net VoIP-to-VoIP calls described separately. No complete public account price was found. Use a dated quote and bill for access, channels, usage, numbers, ports, features, managed equipment, support, taxes, term, renewal and cancellation. | Documented Voipfone calls the SIP trunk connection free and sells monthly plans, Flex components, numbers, calling credit and usage. That marketing label is not a complete account price. Use a dated order or quote for numbers, porting, extensions, minutes, usage, options, hardware, broadband, support, taxes, term, renewal and cancellation. | Documented Telekom publishes modular CompanyFlex pricing with access, number, flat-rate, usage, parallel-call and service options. A public starting price is not a complete account price and may change. Use a dated quote for sites, access, numbers, calls, minutes, service options, installation, support, taxes, term, renewal and cancellation. | Documented Iristel 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. | Not verified TELUS describes reduced costs, purchased sessions and burstability but does not publish a complete current enterprise price on the reviewed pages. Use a dated quote, contract and bill for access, base sessions, burst usage, calls, numbers, ports, continuity, emergency service, support, taxes, term, renewal and cancellation. | Documented The tariff provides monthly, three-year and five-year service structures, per-trunk and implementation charge categories, optional RTM and overflow charges, access-fee conditions and early-termination rules; some ranges are filed in confidence. This is not a complete account price. Use a dated quote, contract and bill for trunks, access, numbers, usage, features, emergency service, equipment, support, taxes, term, renewal and cancellation. | Not verified Cogeco describes a customized solution and notes that activation, network connection and installation charges may apply, but the reviewed page does not publish a complete SIP-trunk price. Use a dated quote, contract and bill for access, channels, numbers, ports, usage, failover, eSBC, emergency service, support, taxes, term, renewal and cancellation. | Not verified The reviewed current product page does not publish a complete selected-account price. Bind channels, calling scope, numbers, ports, installation, equipment or gateways, international and toll-free usage, emergency service, support, taxes, term, renewal and cancellation to a dated quote, contract and bill. Do not apply generic cost illustrations to the account. | Not verified The product page publishes general minute, channel and term language, while the attachment places pricing in the applicable service order. Neither is a complete selected-account price. Bind concurrent sessions, number blocks, installation, equipment, continuity options, calling, emergency-location records, support, taxes, fees, term, renewal and termination to a dated quote, contract and bill. | Not verified The 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. | Not verified Public marketing and support records do not constitute the selected account's accepted price. Bind account minimums, numbers, usage, international and toll-free rates, porting, failover destinations, emergency alternatives, taxes, fees, support, term, renewal and termination to a dated quote, contract and bill. Recheck before purchase because plan names and rates can change. | Not verified sipgate publishes current product and price pages and the help record describes monthly tariff variants, but a web page is not the selected account's accepted commercial record. Bind channel tier, numbers, usage, porting, international and premium destinations, taxes, support, renewal and termination to a dated order and bill. Recheck immediately before purchase or change. | Not verified Cisco identifies Route List Calls as an add-on for eligible subscriptions and says Dedicated Instance includes the feature, but the reviewed public pages do not publish the selected tenant's price, term, PSTN provider charges, numbers, porting, taxes, support or overage economics. Bind the license quantity and provider commercial terms to a dated quote, subscription and bill. | Not verified Microsoft documents Teams and Teams Phone licensing as prerequisites, while SBC software or service, carrier trunks, numbers, emergency services, access, support and usage remain separately sourced. The reviewed pages do not publish one account price or term. Bind every license, SBC, carrier and support charge to a dated quote, contract and bill. | Documented Google's current comparison publishes SIP Link Standard at USD 6 per user per month and Premier at USD 8 per user per month. These are dated public software-subscription prices, not a quote. The existing carrier continues to bill calling, while SBC, number, access, tax, currency, support and contract terms remain separate. | Not verified BYOC-P retains the chosen carrier and a customer-provided SBC while using Zoom Phone licensing. The reviewed documents do not establish a universal current total or itemized BYOC-P price. Obtain dated Zoom, carrier, SBC, private-circuit, number, emergency, messaging, support, tax and implementation terms for the exact countries and sites. | Not verified BYOC combines RingEX software, the customer's local-carrier service and a customer-purchased gateway. Public RingEX tiers do not establish the selected BYOC total. Bind user licenses, BYOC add-ons, carrier numbers and usage, gateway and support, access, implementation, taxes, term, renewal and termination to current RingCentral and carrier orders and invoices. | Not verified Genesys documents monthly fair-use allocations and overage treatment for BYOC Cloud usage, but the reviewed public pages do not establish the selected organization's current total. Obtain dated Genesys licensing and usage terms plus carrier numbers, channels or usage, access, equipment, emergency service, implementation, support, tax, renewal and termination terms. | Not verified Microsoft publishes consumption examples for the application and Direct Routing participant legs, but those examples do not establish the selected workload's current total and the service is in a retirement period. Bind dated Azure usage, SDK and support charges to carrier, SBC, access, number, emergency, implementation, tax, migration and replacement-platform terms. | Not verified The public material discusses cost and flexible scaling but does not establish the selected deployment total. Obtain a dated quote covering channels or usage, numbers, porting, access, SBC services, emergency calling, support, implementation, taxes, minimums, renewal, cancellation and parallel-running charges. | Not verified The public service page mentions unlimited usage plans but does not establish the selected total or scope. Obtain a dated quote covering sessions or usage, numbers, ports, access, equipment, emergency calling, support, taxes, minimums, renewal and cancellation. | Documented The October 11 review found Euro business plans with published channel counts, monthly charges or minimum spends, usage rates, optional minute packages, taxes and cancellation conditions on the current product page. Treat that dated public catalogue as research evidence only: obtain a current account-specific order covering numbers, ports, calls, add-ons, support, taxes, renewal and cancellation before purchase. | Documented The trunk product page says incoming calls are not charged and outbound calls are charged, while the voice-plan page publishes hosted-plan prices and inclusions. Those pages do not establish a complete trunk quote, number rental, port fees, outbound destinations, taxes, support, renewal or cancellation for a specific account. Obtain a current written order before purchase. | Not verified The reviewed pages do not publish a complete current price for a specific trunk, number set, destinations, port, recording, support, taxes or renewal. Voiceflex publishes a dated minimum-term schedule with different product entries, so no one term should be applied across every SIP-trunk order. Obtain the current order form, tariff, minimum period, renewal and cancellation terms in writing. | Not verified The product page advertises SIP trunking from £4 per month, but that headline does not establish the complete current price for a selected trunk, channels, numbers, ports, destinations, connectivity, support, taxes or renewal. The telephony terms say charges follow the notified tariff and may change. Obtain the current order form, tariff, minimum period, renewal and cancellation terms in writing. | Documented 2talk publishes plan, number, additional-trunk and out-of-plan rate-card entries and labels its voice offering prepaid with no contracts. Those catalogue entries do not establish the complete current charge, tax, destination rate, feature entitlement, credit, cancellation consequence or terms for a selected account. Preserve a dated quote, rate card and accepted terms. | Not verified The reviewed technical pages do not establish current setup, number, porting, channel, call, forwarding, support, tax or cancellation charges for a selected order. Obtain a dated quote, rate card, service schedule and accepted terms rather than treating technical availability as a price or entitlement. | Documented A&A publishes number setup, monthly number rental and destination-based call pricing, and states a one-month minimum term for the reviewed retail service. Prices are dated public catalogue evidence, not a complete quote: number grade, porting, special ranges, taxes, calls and account-specific terms still require a current order. | Not verified The current SIP Trunking page requests contact rather than publishing a complete price. The specific terms describe installation, monthly and call charges plus cancellation conditions, but do not establish the current amount, tax, destination rates, minimum service period or complete terms accepted by a selected customer. Preserve a dated quote, order and incorporated terms. | Not verified The outbound page displays example per-minute rates and describes an initial three-month term followed by monthly service, but the terms say website prices are periodically updated and the order form controls fees. Do not treat the displayed examples as a quote. Preserve a dated order, destination rates, billing increments, taxes, credit limits, term and cancellation treatment. | Not verified The emergency page describes tiered usage pricing, but the reviewed public pages do not establish current setup, number, porting, inbound, outbound, resilience, encryption, support, tax, minimum-spend or termination charges for a selected order. The website terms also say site material may change without notice. Preserve a dated quote, service schedule, rate deck, billing increments, taxes, credit terms and cancellation treatment. | Documented NFON publishes German SIP-trunk channel, package, activation, minute and flat-rate catalogue figures and explicitly says prices differ by operating country. Do not transpose those figures to another region or account. Preserve a dated local quote, currency, channel package, feature set, activation, numbers, usage, taxes, support, term and cancellation treatment. | Documented The service schedule states a default minimum term unless the order says otherwise and describes bundle and diversion charging boundaries. Approved price, taxes, exact term, support and SLA remain the dated order. | Documented T38Fax publishes service plans, a trial and usage terms, but the applicable rate, included sessions, number charges, porting, international use, private connectivity, taxes and support terms remain order- and date-specific. Preserve a dated quote or checkout summary rather than copying a headline price into a deployment plan. | Documented The current pricing page publishes usage-based voice figures, number charges and separate committed-use language. It also documents an account minimum in the FAQ. These public figures are dated evidence, not a quote: preserve the current order, currency, destinations, billing increments, minimum commitment, numbers, ports, support, taxes, term, renewal and cancellation. | Not verified Broadvoice describes flexible pricing and the agreement page links a current Elastic SIP Trunking Addendum. The reviewed public product page does not provide a complete selectable quote for one deployment. Preserve the signed order, channels, burst treatment, minutes, destinations, DIDs, toll-free service, taxes, fees, term, renewal, cancellation and support rather than reusing an old public rate card. | Not verified The trunk page identifies included components but the reviewed public page does not expose a complete current SIP-trunk price for one account. SIPcity publishes port submission, rejection, reversal and emergency-return charges separately, and its billing guide describes prepaid usage, monthly debits, top-ups and low-balance alerts. Use a dated order for the plan, extra channels, numbers, porting, usage, international destinations, hardware, taxes, term and cancellation. | Not verified The reviewed public pages do not provide a complete current carrier-voice price for one account. Capacity, numbers, portability, international termination, regulatory work, support, taxes and term can vary by market and order. Use a dated signed quote and usage schedule rather than converting general cost-efficiency or pay-for-use language into a price. | Not verified The reviewed public pages do not publish a complete order-ready price for channels, numbers, ports, calls, certificates, support, taxes or term. Use a dated quote and service schedule; do not convert the self-service 1-to-100 channel control into pricing or availability. | Not verified No current price is reproduced here. The reviewed support material does not provide a complete dated quote for one account, number, destination mix, usage, taxes, minimum spend, credit policy, term or cancellation. Use the signed order and current account-specific tariff instead of a historical support-page amount. | Not verified The service page describes a pay-as-you-use arrangement with a minute bundle and directs customers to an individual quote rather than publishing one complete price list. The fair-use page applies changing business-use and acceptable-use controls across IP Telecom services. Use the signed order, current tariff, taxes, term, limits and cancellation terms instead of reproducing a marketing amount. | Not verified Clearfly describes flexible pricing, metered trunks with local calling included and long distance billed per minute, but it does not publish one complete durable tariff for every order. Preserve the quote, current rate deck, taxes, fees, minimums, term, renewal, porting, emergency service, international use, suspension and cancellation terms. | Not verified No durable public tariff, selected availability commitment, service-credit schedule or complete commercial term was verified. Preserve the quote, service schedule, channel and number charges, porting, installation, access, support, emergency, usage, term, renewal, suspension and cancellation rules. | Documented CommPeak publishes usage-based voice pricing, separately billed SIP and DID services, country-specific compliance documents and custom high-volume quotes. The reviewed public pages do not establish the selected route rates, taxes, surcharges, deposits, SLA remedy, term, suspension or cancellation conditions; preserve the dated quote and contract. | Not verified The registration guides disclose a recurring registration charge but no selected-account amount, taxes, PSTN rate, number charge, SLA remedy or support entitlement was verified. Retain the dated order and billing evidence. | Documented TelVox publishes usage pricing billed by the second, with US starting rates and separate meters for PSTN, SIP or WebRTC legs, numbers, recording, storage and conferences. It says other destinations are scoped with sales and the live API remains v0.x, so preserve the dated rate card, quote, invoice rules, contract and integration version instead of treating examples as a universal price. | Documented The product page publishes a current channel price and volume-quote path, while the agreement allows fees and services to change. Preserve the dated quote, currency, taxes, fair-use treatment, term, cancellation, SLA and support terms rather than copying a volatile figure. | Documented Current Australian channel plans and legal documents are public, but approved price, taxes, fair-use treatment, SLA scope, exclusions, term and support remain the dated order and contract. | Not verified No complete selected-account price was established. Bind access, trunks, DIDs, continuity features, PBX or SBC work, usage, support, taxes, term, renewal and termination to the dated order, contract and bill. | Not verified No current selected-account price was established. Bind plan, capacity, numbers, usage, continuity, fax, taxes, regulatory charges, term, renewal and termination to the dated order, contract and bill. | Not verified No current selected-site price was established. Bind access, channels, numbers, usage, options, taxes, term, support and change charges to the dated order and bill. | Not verified No selected-site price was established. Bind access, endpoints, virtual lines, numbers, usage, options, support, taxes, term and changes to the dated current order and bill. | Not verified The factsheet notes price-plan and Voice Channel Flat structures but is not a binding offer and may be revised. Bind access, channels, numbers, usage, options, support, taxes, term and changes to the dated current order and bill. | Not verified The 2016 price list is historical and belongs to Business Voice Direct. Current Business Voice SIP package, access, channels, numbers, support, taxes and term require a dated quote and order. | Not verified The 1 January 2026 contract summary contains time-sensitive reference prices and says prices may change. The current quote, order, term, channels, numbers, options, usage and taxes govern. | Not verified The product page contains date-sensitive Australian plan, tax, channel and usage terms. The current Critical Information Summary, order, balance, inclusions, restrictions and fees govern. | Not verified Product and porting pages expose date-sensitive offers, fees and time estimates. The current order, Critical Information Summary, port category, taxes, terms and provider confirmation govern. | Documented The 1 July 2026 CIS publishes Basic and Premium channel examples, a two-channel minimum example, month-to-month service and possible equipment or installation costs. The current quote, order, taxes and later changes govern. | Not verified No public enterprise SIP-trunk price, channel rate, term, tax or implementation charge was established by the reviewed sources. The current quote and order govern. | Not verified Product examples and contract charges are dated and conditional. The current application, quote, taxes, term, implementation and optional-package charges govern. | Not verified Current application, pricing table, access method, term and feature selections govern. No universal public price or availability was established. | Documented Product pages publish selected term and Smart SIP price information, but the governing pricing schedule, site feasibility, installation and selected options determine one order. No universal current price or availability is inferred. | Not verified The older fee schedule is not a current quote and the overview does not establish one universal current price, term, installation or site availability. | Not verified Rates, terms, feasibility and activation depend on the current order and governing records. Public material is not a current quote. | Not verified Charges, service term, feasibility, availability and activation depend on the agreement and service order. Public material is not a current quote. | Not verified The reviewed public records do not establish a current quote, feasibility result, activation date or universal availability. | Not verified Pricing, fees, availability, optional features, serviceability and activation are time-sensitive and order-specific. This record does not reproduce them as a quote. | Not verified Marketing describes per-minute and bundled options without a complete account quote. Price, fees, taxes, availability, serviceability, commitment and activation are order-specific. | Not verified Telesystem publishes fee definitions but not a complete account quote. Access, sessions, bursting, forwarding licenses, numbers, usage, support, taxes, term, serviceability and activation remain order-specific. | Not verified Reviewed public sources do not establish one complete quote. Access, channels, features, DTO, SD-WAN, numbers, usage, support, taxes, term, serviceability and activation remain order-specific. | Not verified Reviewed public sources do not establish one complete quote. Paths, bursting, access, DIDs, usage, features, support, taxes, term, serviceability and activation remain order-specific. | Not verified Reviewed 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. | Not verified Reviewed public records do not establish one complete quote. Access, trunk group, capacity, numbers, DTO, usage, equipment, support, taxes, term, serviceability and activation remain order-specific. | Not verified The 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. | Not verified No current account quote was reviewed. Access design, handoff, channels, numbers, equipment, support, taxes, term, serviceability and activation remain order-specific. |
|---|