| 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 SIP registration and source-IP authentication as separate interconnection choices. Preserve the selected account path, credential or approved source address, target PoP and egress address; an allowed IP and a completed digest exchange are different evidence states. | Documented Outbound trunks have configured authentication methods; digest challenges use the fixed realm out.didww.com. Inbound trunk authorization is a separate optional challenge from the customer PBX. | 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 Bandwidth Build uses a realm hostname plus username/password SIP credentials to authenticate outbound calls. API credentials, number configuration and inbound routes remain separate objects. | 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 material authorizes outbound service by customer source IP. The account Settings area is used to add that address; this is a network identity control, not a SIP username-and-password claim. | 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 LES.NET's public voice page says an account can define multiple SIP trunks and control outbound calling and caller ID, but the reviewed pages do not identify the trunk's digest, source-IP or other authentication requirement. Confirm the exact account identity and authorization model before building a PBX object. | 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 Commio documents outbound trunks by permitted source IP. A changing public address must be updated in the portal, and multiple source addresses are represented by additional trunks. Preserve the exact egress address and propagation delay rather than substituting a credential-registration template. | 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 static-IP and username-based authentication for connecting an existing SIP platform. Record which method the account actually uses, the authorized egress address or credential owner, and the production signaling destination; the two methods are not interchangeable health signals. | 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 two connection models: a SIP login and password, or a trunk authorized by confirmed static source IP addresses. The IP-authorized model consumes an existing SIP login as its identifier and makes that login unavailable for registration. Record the selected model, source addresses or credential owner and the permitted caller-ID numbers; do not combine the two procedures. | Documented DIDforSale documents two interconnection paths: portal-approved source IP or FQDN, and a separately created SIP username, password and domain. The IP record must have termination enabled before it can originate calls. Record one intended model, credential or address owner and international-calling policy; do not leave both paths active by assumption. | Documented ThinkTel documents SIP-trunk authorization against the configured IP-and-port binding for the trunk pilot, checked through an access-control list. The Via and Contact must carry that contact address and port; traffic from another address is rejected. A separate digest procedure is documented for VoIP lines, so do not apply line-registration instructions to an IP-authorized trunk without an account-specific interop decision. | 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 two PBX identity models: a static public IP can authorize outbound traffic by source address, while a dynamic-address deployment uses generated username and password credentials. The same account can expose different inbound and outbound controls, so preserve direction, endpoint object, public address or redacted credential identity and configuration owner separately. | 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 reviewed public SIP Trunking page and data sheet do not establish a universal customer authentication model, credential format, source-IP policy or SBC trust boundary. The Local SIP Trunk terms describe routing between the customer's IP address and AireSpring, but that is not enough to infer IP-only authorization for every ordered product. Obtain the implementation worksheet and exact permitted sources before choosing a PBX template. | 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 Gamma's current product page establishes an on-premises PBX connection to the Gamma network over broadband, Ethernet or a private access circuit, but it does not publish a universal customer authentication method, source-address policy, credential format or SBC trust boundary. Obtain the current implementation record, assigned peers, permitted source addresses, transport and access design before choosing a PBX template. | 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 Exotel's current Dynamic SIP Trunking quickstart supports source-address allowlisting, digest credentials or both, selected for the platform's egress model. A permitted address and a completed digest challenge are separate evidence states. Keep API credentials, SIP credentials and reusable authorization material out of shared captures, and confirm the exact trunk object rather than copying an Alpha or historical setup. | 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 public API documentation defines API-key and environment-specific API-secret headers for DID and trunk-group administration. Those HTTPS credentials are not SIP credentials. The reviewed public sources do not publish one universal digest realm, username, secret lifecycle or source-address authorization rule for the voice interconnect; obtain the account turn-up record. | 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's business page says the service includes authentication protocols, but the reviewed public pages do not identify the ordered method, credential owner, digest realm or algorithms, source-address controls, certificate role or mutual-authentication behavior. Preserve the current handoff, configured PBX or SBC objects and observed challenge or source validation without exposing secrets. | Not verified The reviewed TELUS public pages do not define the selected trunk's credential or source-address authentication method, digest realm or algorithms, certificate role, mutual authentication or IP allowlist. Preserve the current order and handoff, then map each secret or trusted address to its PBX or SBC owner without exposing it. | Not verified The reviewed SaskTel product and tariff records do not define the selected trunk's credential or source-address authentication method, digest realm or algorithms, certificate role, mutual authentication or allowlist. Obtain the implementation handoff and map each secret or trusted address to its PBX, SBC and provider owner without exposing it. | Not verified Cogeco's public page describes a provider-supplied enterprise SBC but does not publish the ordered trunk's credential, digest realm or algorithms, source-address policy, certificate role or mutual-authentication behavior. Obtain the implementation handoff and map each trust decision to the Cogeco edge, supplied eSBC and customer PBX 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 OnSIP says enabling trunking on a hosted-PBX user creates authentication information for the customer's PBX. The reviewed public pages do not expose a safe, complete current credential schema, digest realm or algorithm, secret rotation process, source-address policy, certificate role or allowlist. Record the account-generated values and their owners in a protected implementation handoff; never copy reusable credentials into tickets or captures. | 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 Voximplant documents an IP or network allowlist for PBX-to-platform trunk calls without SIP authorization. Its outbound callSIP interface separately supports an authentication username and password, while application users can register as SIP endpoints. These are different trust paths; retain the selected source addresses, credential owner, destination and application rule without publishing secrets. | 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. |
|---|
| 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 For SIP-REG number routes, Flowroute says inbound calls originate only from PoPs with which the gateway registers. Registration, the number relationship, provider edge attempt, PBX answer and media remain separate evidence. | Documented Inbound trunks can use dynamic registration and deliver to the learned Contact. Outbound trunk registration is supported but not required to place calls; keep these two relationships distinct. | 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. | Not verified The reviewed Build page documents a realm and credentials but does not show REGISTER or establish one universal registration rule across Bandwidth trunk products. Preserve the actual initial request and assigned account path. | 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 help page describes IP authorization, and Voxbeam's published FreeSWITCH guide sets registration to false. Treat that guide as a legacy configuration example and confirm the current account model; do not use a REGISTER indicator as the sole health signal for an IP-authenticated path. | 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 public pages do not establish whether a trunk uses SIP REGISTER, static delivery, a fixed contact or another binding model. Do not interpret a missing registration indicator as a fault until the actual portal record and provider instructions identify the connection method. | 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 guidance authenticates by source IP, while inbound routing can target a SIP URI when a receiving switch requires registration. It does not document a Commio registrar binding used by the customer's PBX as the trunk identity. Confirm the selected direction and account workflow instead of waiting for an assumed REGISTER state. | 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. | Not verified The reviewed public pages say username-based authentication is available but do not establish a SIP REGISTER workflow, registrar address, binding lifetime or inbound-routing dependency. Confirm the current account procedure before selecting a registration template or treating an absent REGISTER state as a fault. | 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 The login-and-password path uses registration to sip.zadarma.com. The IP-authorized trunk explicitly disables registration for the selected SIP login and accepts outbound traffic only from confirmed addresses. Preserve registration, source-IP verification and call completion as separate evidence states. | Documented The credential path is documented for PBXs behind a firewall or devices that require SIP registration; the source-IP path instead authorizes traffic from a portal record. An activated SIP account, an allowed address, a successful REGISTER and a completed call remain separate evidence states. | Documented ThinkTel's current trunk overview says OPTIONS monitoring negates the need for REGISTER and registration should be disabled whenever possible. Treat an address binding, a response to OPTIONS and a completed call as separate states. Preserve the assigned proxy, source address, contact port and any explicit technical-services exception rather than inferring a registrar from older PBX examples. | 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 The dynamic-IP Asterisk PJSIP example uses REGISTER so inbound calls follow the most recent contact. The static-IP model sends calls directly to the configured address and does not establish a REGISTER dependency. A successful registration, accepted source address and completed call are separate evidence states; follow the selected account model rather than combining both templates. | 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 The reviewed public material does not say that the ordered SIP trunk registers, nor does it document a registrar, username, expiry or Contact behavior. Do not wait for a registration indicator or create credentials unless the current implementation record requires them. Preserve the ordered service, handoff, assigned hosts, SBCs and provider confirmation. | 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 product and support pages do not say that the ordered trunk registers or document a registrar, username, expiry or Contact behavior. Do not create credentials, wait for a registration indicator or infer a fixed-peer model from the access circuit alone. Preserve the order, handover record and current confirmation from the named Gamma supplier or channel partner. | 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 The current India TCP and TLS interface pages say SIP registration-based authentication is not supported. Digest credentials authenticate requests; they do not create a REGISTER binding. Do not diagnose an absent registration indicator as a trunk failure or transfer a phone-registration template into this service. | 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 reviewed public pages establish SIP interconnection and regional inbound source addresses but do not state that every account registers, uses static IP authorization or follows one registrar workflow. Preserve the ordered peer model, signaling addresses, transport and identity rules from the account's turn-up material. | 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 The Cox-hosted Asterisk 1.8.7 guide says its reference service requires SIP REGISTER through a Cox E-SBC and uses a provider-supplied pilot number and key. That evidence is tied to the documented legacy topology. Verify the ordered service, current PBX, registration interval, transport, E-SBC address and source restrictions before deployment. | 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 public pages do not establish whether an ordered trunk registers, uses IP-based peering or supports both. Do not infer a registrar from the SIP-trunk label or an editable portal IP. Record signaling peers, transport, Contact behavior, expiry, qualification and source-address requirements from the provider handoff and loaded system state. | Not verified The reviewed public pages do not establish whether a TELUS enterprise or partner trunk registers, uses static IP peering or supports another interconnect model. Record peers, transport, Contact behavior, expiry, qualification, DNS dependencies and source-address requirements from the exact service handoff rather than inferring them from the SIP Trunking label. | Not verified The public records establish SIP trunks between SaskTel and IP-enabled customer equipment but do not say whether the selected service uses REGISTER, static peering or another handoff. Record peers, transport, Contact behavior, expiry, qualification, DNS dependencies and source-address rules from the accepted implementation record rather than inferring them from the service name. | Not verified The reviewed public records do not state whether the selected Cogeco handoff uses REGISTER, static peering or another model. Record signaling peers, transport, Contact handling, expiry, qualification, DNS dependencies and source-address requirements from the accepted handoff and loaded eSBC or PBX state rather than inferring them from the SIP-trunk label. | 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 documents a user configured to route calls to and from the customer's PBX and notes that the trunking flag is stored with the registration until the device re-registers. That does not establish every PBX's registrar, proxy, transport, Contact, expiry, qualification, DNS or retry settings. Use the current account record and the applicable PBX configuration guide, then validate a sanitized registration exchange. | 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 The SIP-user FAQ constructs an application-and-account domain and documents username/password registration. The trunk FAQ instead starts with an IP allowlist and application rule, so it does not establish REGISTER as a universal trunk requirement. Confirm the ordered design, current domain, outbound proxy, DNS answers, transport and timer behavior for the selected account. | 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. |
|---|
| 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 Each number has separate primary and failover route relationships referencing route objects. Documented route types are host, number, uri and sip-reg. Host or URI routes can use a preferred inbound PoP; number routes return to the PSTN; SIP-REG follows the registered PoP. | Documented Assign a DID to a static endpoint SIP trunk or a dynamic-registration trunk; static routing can use a host and optional DNS SRV, while dynamic routing uses the registered Contact. | 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 Each SIP-trunking number needs at least one prioritized route. Routes contain endpoints, and endpoint weights distribute traffic inside a route; endpoints can be a domain, IP, SIP URI or forwarded telephone number. | 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 Inbound DIDs are delivered by SIP. The FAQ documents a default trunk-level IP or SIP URI and a per-DID SIP endpoint override. Record the exact destination and request-URI format instead of transferring outbound authentication assumptions to inbound routing. | 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 LES.NET says local DIDs can route to a phone system or call forward to another number. Record the selected destination for each DID and keep direct SIP delivery separate from telephone-number forwarding; the page does not establish the SIP URI format or PBX configuration. | 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 inbound routing profile must be assigned to a number. The profile can target an IP address, DNS A or SRV record, PSTN number or SIP URI, with the first entry primary and as many as two backup entries. Record number assignment, target type, port, identity handling and permitted source addresses for the actual route. | 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 Wavix documents routing a purchased number to a SIP-capable PBX or forwarding it to an external number. Preserve the exact number, selected route, destination URI or address, identity format and fallback ownership; provisioning a trunk alone does not prove that the number points to it. | 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 Zadarma documents routing a virtual number either to a registered SIP login or, for a customer server, to an external SIP URI without registration. The IP-authorized outbound trunk does not itself receive calls on its identifying login. Keep number ownership, inbound target, allowed provider source addresses and delivered called-party identity distinct from outbound authorization. | Documented A portal-approved IP or FQDN can be used to configure local and toll-free numbers for delivery, and DIDforSale publishes multiple inbound gateway addresses that customer firewalls must accept. Preserve the exact number route, destination address, provider sources, called-party format and PBX context rather than treating outbound authorization as inbound proof. | Documented A pilot identifies the trunk, while DIDs can be ordered from available rate centres and assigned through uControl. The service overview says each configured binding can be used for origination and termination. Preserve the exact DID, pilot, binding order, delivered called-party format and PBX context; a working outbound call does not prove the inbound route. | 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 GoTrunk documents inbound delivery either to a static SIP URI or to the latest registered contact for a credentialed endpoint. Purchased or ported telephone numbers are assigned a target that can be changed in the portal, and some number orders can remain pending. Preserve the exact number, endpoint, target, delivered called-party format, provider source and PBX context; outbound success does not prove inbound assignment. | Documented For the documented SONUS-based service, a route plan contains one or more trunks and controls inbound delivery. Sequential hunt and percentage allocation are available route-plan choices, while customer equipment separately controls how outbound traffic reaches Lumen. Preserve the service ID, telephone number, route plan, trunk group, hunt type, delivered identity and PBX context as separate evidence. | Documented The portal's Number Routing area assigns each DID or toll-free number to static-address or dynamic-registration delivery and controls the user part presented in the inbound Request-URI. Preserve the number, term type, IP or contact, translation value, delivered URI and PBX route independently; a portal entry does not prove PBX acceptance. | 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 The Local SIP Trunk terms describe inbound and outbound service through AireSpring-assigned or ported telephone numbers, with traffic delivered to the customer's gateway or IP-PBX over SIP. This does not establish the Request-URI format, asserted identity, accepted source set or routing object for an account. Trace one authorized number through the provider route, exact SIP identity and PBX destination. | 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 Gamma describes PSTN breakout through an on-premises PBX and says SIP Trunk Call Manager can terminate subscribed 01, 02, 03 and 08 numbers on Gamma SIP Trunks. That does not establish the Request-URI, asserted identity, number format or PBX route for an account. Trace one authorized number from the assigned route through the exact SIP identity to its final destination. | 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 describes SIP Trunking as two-way PSTN access over a single SIP connection and publishes per-number portal controls for eligible call-forward features. That establishes a service and administrative boundary, not the assigned peer, delivered number format, PBX context or final destination. Preserve each number, Bell handover, received Request-URI and resolved route separately. | Documented For the documented Connect applet path, an Exophone is mapped to a flow whose Connect applet dials sip:<trunk_sid>; the trunk then uses its destination URI, and the phone-number mode is pstn. Exophone assignment, mode, flow publication, destination reachability, delivered identity and an answered call remain separate states. | 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 The API supports DID inventory and trunk groups and publishes different inbound source addresses for the US, Hong Kong and UK points of presence. Number ownership, selected trunk group, permitted source, delivered called identity, PBX match and downstream destination remain separate evidence states. | Documented Numbers belong to packages and follow that package's routing policy. Usage accounts can place available trunks into a routing profile, while bundle accounts use a primary trunk and optional redundant trunk. Number assignment, package, profile, selected trunk, delivered identity and PBX destination 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 The current product page describes SIP Trunking as connecting an existing PBX to telephone service, while the PBX guides route assigned DIDs through a local Cox E-SBC into PBX destinations. Keep number assignment, E-SBC peer, delivered called identity, PBX match and final destination as separate evidence. | Documented Verizon describes IP Trunking as PSTN calling for a premises or cloud business phone system and says it provides or ports telephone numbers. That establishes the service role, not the exact Request-URI, Diversion, P-Asserted-Identity, number format or PBX destination. Capture the delivered identifiers and match policy for the actual order. | Documented The schedule defines purchased Direct Inward Dial numbers and SIP sessions connecting the customer location to the PSTN. It does not establish one current Request-URI, P-Asserted-Identity, Diversion, number-format or PBX-destination rule. Record the delivered identifiers and matching policy for the actual order. | 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 AT&T describes calling plans that support inbound and outbound calling, local and long-distance calling, virtual telephone numbers and use with existing premises equipment. Those statements do not establish an account's assigned inventory, port state, Request-URI, asserted identity or normalization. Retain the order, number record and matched PBX destination for authorized acceptance calls. | 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 Iristel describes SIP trunking for making and receiving calls and an Espresso DID portal for ordering and configuring DIDs, connectivity and porting. Those capabilities do not establish an account's assigned numbers, activation, Request-URI, delivered identity or PBX normalization. Retain the DID record, port status and matched route for authorized acceptance calls. | Documented TELUS describes SIP Trunking as integrating inbound and outbound voice with a customer phone system, and its guide says DIDs can be added or ported. Those descriptions do not establish an account's assigned numbers, port completion, Request-URI, asserted identity or PBX normalization. Retain the number record and an authorized call trace for each accepted pattern. | Documented SaskTel lists inbound and outbound Calling Line Identification and Calling Name Identification, includes one primary number in the tariff description and provides additional DIDs when ordered. Those features do not establish one account's assigned inventory, port state, delivered Request-URI, asserted identity or PBX normalization. Preserve the order, number record and authorized traces for accepted patterns. | Documented Cogeco advertises local numbers for distant locations and says geo-redundancy can reroute incoming calls to an active trunk. Those claims do not establish an account's assigned inventory, completed port, delivered Request-URI, asserted identity, PBX normalization or the active failover destination. Preserve the order, number record and authorized traces for every accepted pattern. | 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 Comcast lists DID, DNIS, ANI, Calling Name Delivery and multiple Caller ID options. Those feature names do not establish one account's number inventory, completed port, delivered Request-URI, asserted identity, digit format or PBX route. Reconcile the service order and portal inventory with authorized SIP traces and call-detail records for every accepted pattern. | 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 OnSIP documents transferring existing PSTN Gateway numbers to the hosted-PBX account and warns that transferred numbers begin ringing the new PBX immediately. It also documents provider-side ring time and external-number failover for the trunking user. These facts do not establish one account's assigned numbers, completed ports, Request-URI, asserted identity, digit format or PBX route. Reconfigure first, preserve the number record and validate each accepted inbound pattern. | 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 Voximplant documents forwarding allowed PBX traffic into an application rule and handling the resulting CallAlerting event in a VoxEngine scenario. It also sells phone numbers separately. Selected number inventory, portability, delivered Request-URI and identities, rule order, scenario behavior and alternate targets remain account and application specific. | 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. |
|---|
| 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 Provider-edge strategy and number-route failover are separate. A preferred edge can be attempted first for Host or URI routes, while the number failover relationship selects another route object. The public material does not publish one universal response, timeout, retry or restoration matrix. | Documented DNS SRV and inbound trunk groups can redirect new call attempts according to priorities, weights, ringing timeouts and selected rerouting codes. Each attempt can create its own CDR. | 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 Build documents secondary and tertiary routes after a primary-route failure. Number features separately expose Final Destination URI. The reviewed pages do not publish a complete response-code, timer, retry or restoration contract. | 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 Public pages describe call forwarding as a routing choice, not a failure-triggered priority list. They do not establish which timeout or SIP response advances, whether an active call survives, or how a destination is restored. Treat resilience as an account-specific design and controlled test. | 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 up to three ordered inbound destinations. It advances immediately on most responses other than 486, and after roughly four seconds when a destination gives no signaling response. Confirm the behavior of every intended failure response and restoration; this routing policy does not establish preservation of active calls. | 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 The provider advertises redundant trunking and multiple fail-over options, but the reviewed public pages do not define customer destination order, response-code triggers, timers, restoration or active-call behavior. Obtain the applied route policy and test each approved failure state; data-centre count is not proof of customer-site recovery. | Documented Static trunks can contain multiple customer destination IPs with failover or round-robin selection, while Call Routing can try up to ten destinations in sequence. New FQDN-based trunks in documented paired regions can expose SRV primary and secondary SBC entries; an A lookup returns only the selected data-centre SBC. These paths need separate failure and restoration tests, and none proves survival of established calls. | 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 DIDforSale says calls can arrive from several gateway IPs for load balance and uptime, but the reviewed public pages do not define customer destination priority, health checks, timeout, retry order or established-call survival. Accepting every published provider source is an ingress requirement, not proof of customer-side failover. | Documented ThinkTel documents round-robin and lowest-available routing across configured bindings, OPTIONS-based binding state and SureCall forwarding after all bindings are down. Response-code retry behavior and the selected mode still require account confirmation. Test each binding, exhaustion case, all-down forwarding and restoration separately; a secondary binding does not establish established-call survival. | 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 Lumen documents sequential hunt and percentage allocation across trunks in an inbound route plan, and its product sheet describes built-in failover protection. Those statements do not define every account's response-code triggers, timers, access-path behavior or established-dialog survival. Record the configured hunt type and approved failure cases, then test new-call routing separately from active-call continuity. | Documented Disaster-Recovery Routing can forward an individually configured number to as many as three alternate locations, using telephone numbers or IP endpoints, after delivery to the intended location fails. The guide does not publish every detection interval, SIP response trigger or established-call behavior. Treat it as new-call routing and validate approved failure cases separately. | 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 general data sheet advertises geo-redundant network failover, while the separately named Long-Distance SIP Trunking service documents Direct Termination Overflow and flexible routing. The reviewed material does not establish that those portal controls, triggers or destination types apply to every Local SIP Trunk order. Obtain the exact service design and test new-call failover with approved destinations, timing and rollback. | 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 The product page describes connecting two on-premises systems, rerouting between sites and combining Gamma SIP Trunks with the separate Inbound service or SIP Trunk Call Manager for alternate destinations. Gamma's user-support page lists separate Call Manager and Inbound guides, reinforcing that these controls are named service components rather than a universal trunk property. None of those pages proves the ordered trigger, route order, timer, destination, recovery behavior or established-call survival. Record the exact products and test bounded new-call failures with approved destinations and rollback. | 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 geo-redundancy through dual virtual connections and automatic overflow or rerouting of inbound calls to an existing PSTN, PRI/T1 or alternative service. The public statements do not establish the ordered topology, trigger, response-code treatment, recovery timing, established-call survival or feature entitlement. Treat dual connections and call redirection as separate controls and obtain the exact design. | Documented Exotel documents an FQDN destination that is resolved for each call attempt and can represent changing or multiple A or AAAA addresses. That is a destination-resolution capability, not proof of health-aware ordering, qualifying SIP responses, recovery timing, provider-PoP diversity or established-call survival. Validate the selected destination behavior with bounded new-call tests. | 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 automatic restoration. The public article does not enumerate every response, timeout, retry interval, probe or established-call outcome, 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 IDT Express advertises redundant call routing, multiple points of presence and a private IP backbone. The reviewed public sources do not disclose the account's route order, retryable responses, timers, alternate destination, restoration behavior or treatment of established calls. Treat those as turn-up and approved acceptance-test inputs rather than inferred resilience. | Documented Usage-account routing profiles can be round-robin, sequential or proportional. Bundle packages can have one primary and optional redundant trunk, with traffic described as moving to the redundant trunk after network failure. These new-call controls do not prove the trigger, independence, retryable responses, restoration sequence or survival of an established call; verify the ordered design and test plan. | 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 Cox advertises call redundancy, downtime protection, business continuity and real-time capacity changes. The Asterisk reference topology also shows an E-SBC with diverse routes to primary and secondary provider SBCs. These statements do not prove the customer's access diversity, retry rules, route order, restoration behavior or survival of established calls; obtain the ordered design and test only approved new-call failures. | Documented Verizon advertises configurable reliability, portal-based reallocation during disaster recovery and service-level options up to 100% availability. The service guide describes VARRS as an optional mirrored-capacity business-continuity arrangement. These claims do not prove that one order includes VARRS, diverse customer access, a tested alternate destination or survival of established calls; obtain the exact schedule and test approved new-call failures. | Documented The April 2021 schedule describes separately purchased peer failover, load-balancing, overflow and emergency-redirect features, with public/private access constraints for paired Sites. These are orderable schedule terms, not proof that a current account includes them, that access paths are diverse or that established calls survive. Confirm the signed order and test approved new-call failures. | 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 AT&T's business-continuity page lists call forwarding to other locations as an IP Flexible Reach use, and the product page describes branch-office extensions. Neither statement defines automatic trigger, retry, customer-access diversity, restoration order or established-call outcome for one design. Bind continuity to the ordered feature set and a provider-approved new-call failure exercise. | 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 advertises redundant infrastructure, built-in redundancy and automatic failover destinations, while its failover article describes redirection to backup lines. The reviewed pages do not define an account's trigger, timer, retry order, destination, customer-access diversity, established-call result or restoration sequence. Bind failover to the order and a provider-approved new-call failure exercise. | Documented TELUS advertises redundancy, failover and a geo-redundant platform. The public pages do not define the selected account's failure trigger, timers, destination, customer-access diversity, established-call outcome or restoration sequence. Bind continuity to the order and a provider-approved new-call failure exercise. | Documented SaskTel describes optional RTM overflow within the serving central-office switch and a separate Emergency Call Redirection feature that moves voice traffic to a predetermined alternate business location only after a customer request during an emergency. Neither establishes automatic customer-access failover, trigger timers, established-call survival or restoration. Bind every continuity path to the order and an approved new-call exercise. | Documented Cogeco describes physical SIP geo-redundancy and automatic failover or reroute for voice traffic. The page does not define one customer's sites, access diversity, trigger, timer, route order, established-call behavior or restoration sequence. Bind each path to the current design and exercise only a provider-approved new-call failure case. | 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 Comcast lists Failover/Overflow, load balancing, bursting, Unreachable Destination and optional Call Forward Not Reachable. These are distinct ordered controls: added bandwidth, another trunk group and forwarding to a ten-digit number are not interchangeable, and none proves access diversity or established-call survival. Record entitlement, trigger, target, capacity and restoration behavior separately and exercise only an approved new-call plan. | 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 can conflict with or pre-empt this preference. This is a provider-side new-call option, not proof of access, PBX, registration or media-path diversity. Record the trigger, timer, destination, loop prevention, caller experience, established-call behavior and restoration order, then exercise an approved failure case. | 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 The reviewed sources describe a global platform and application-controlled routing but do not define one universal customer-side DNS target order, failover trigger, retry policy, established-dialog behavior or recovery sequence. Obtain the current ingress and egress design and observe only authorized failure tests before relying on an alternate path. | 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. |
|---|
| 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 The public pricing page presents usage-based starting prices for voice and messaging, while the SIP trunking product page directs buyers to discuss pricing, coverage and activation. A dated quote, number charges, emergency fees, taxes and commitments remain account-specific. | 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 dated CAD account, DID, usage and setup figures, with metered and flat-fee number options plus separate outbound, conferencing and fax-to-email charges. These public figures are a planning snapshot, not a quote; confirm the current rate deck, destination mix, taxes, porting and optional services in a dated order. | 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. | Documented Commio's public pricing entry requests a custom quote, while its routing documentation describes account rate decks, per-minute maximums and route selection. Price the exact destination and number mix from the effective account terms, including billing increments, number rental, carrier or regulatory charges, emergency service and messaging fees. | 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. | Documented Wavix publishes usage-based starting rates, separate number and add-on charges, a Flex monthly minimum starting at $15 and Flex Pro starting at $250. The minimum is not an included-usage promise, and displayed routes or examples are not a quote. Preserve the dated destination rate, billing increment, number rental, add-ons, taxes and account commitment. | 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 Gamma's product page contains general cost examples and marketing comparisons, while its 2020 small-business code points customers to the contract and current price information. Neither is a complete current account quote. Obtain dated terms for access, channels, calls, destinations, numbers, porting, Call Manager or Inbound features, resilience, emergency service, support, taxes, commitment, renewal 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. | Documented Voximplant publishes separate SIP-calling, registration, PSTN, number, application and optional-feature charges, and warns that regional functionality can vary. The public schedule does not establish the selected destination rates, taxes, surcharges, volume terms, SLA remedy, support entitlement, suspension or cancellation conditions; preserve the dated quote and contract. | 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. |
|---|