Start with the account, connection and voice profile
QuestBlue describes a setup sequence in which an organization creates a portal account, purchases or ports a number, creates a SIP connection and associates it with an outbound voice profile. Preserve those as separate objects. Record the legal customer, current order, numbers, connection identifier, outbound profile, PBX or SBC, support owner and rollback contact before applying a template.
A portal login, available number or created connection does not prove that inbound routing, outbound authorization, caller identity, media or emergency service is active. Retain the dated order and observed portal state without exposing secrets.
Documented service facts
Reviewed 2026-10-13. Compare SIP trunk services →
SIP authentication
Not verifiedQuestBlue 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.
SIP registration
Not verifiedThe 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.
Inbound delivery and number format
Not verifiedQuestBlue 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.
Routing and failover
Not verifiedThe 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.
Number and regional availability
DocumentedThe product page describes searching for numbers by area code or region, instant DID ordering and real-time porting, while the site presents QuestBlue as a global SIP-trunking provider. These claims do not establish current inventory, portability, local-presence eligibility, activation timing or caller-identity rights for one account. Preserve a dated order or port result for the exact number and legal entity.
Audio codecs and DTMF
Not verifiedThe reviewed public pages do not publish one codec list, packetization interval, DTMF method, RTP range, transcoding policy or media-anchoring model for every SIP connection. Obtain the selected service specification and preserve both SDP bodies, telephone-event mapping, RTP endpoints and decoded authorized-call evidence.
Fax and T.38
Not verifiedQuestBlue markets a separate online-fax product, but the reviewed SIP-trunk pages do not establish T.38, G.711 fax pass-through, switchover behavior, gateway support or document limits on the voice trunk. Treat trunk fax and the separate hosted fax service as different orders and acceptance paths.
Signaling and media encryption
Not verifiedThe FAQ describes encryption for communications data and layered infrastructure controls in general terms. Those statements do not establish SIP TLS, certificate validation, SRTP, keying, approved source ranges or end-to-end protection for the ordered trunk. Map each leg and verify authorization, signaling confidentiality and media confidentiality separately.
Concurrent calls and call-start rate
Not verifiedQuestBlue markets scale and burstable functionality, while its pricing page says customers pay for usage rather than doing capacity planning. Neither page publishes a universal per-account concurrent-call limit, calls-per-second rate, burst policy, bandwidth requirement or PBX ceiling. Obtain dated limits and run only a separately approved bounded load test.
Emergency calling
Not verifiedQuestBlue advertises emergency calling as a separate communications capability and publishes an Emergency Calling API page. The reviewed SIP-trunk page does not establish automatic E911 entitlement, address validation, caller-ID mapping, nomadic behavior, callback handling or an approved test workflow for every trunk. Confirm each site and maintain an independent calling path; do not place an uncoordinated emergency call.
Pricing model
DocumentedThe 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.
Administration and support
DocumentedQuestBlue documents portal setup, downloadable reporting, usage and invoice access, portal-based tickets and support for qualified engineers. Public wording does not establish one maintenance notice, response target, escalation, retention period or restoration commitment for every customer. Record portal roles, named contacts, monitoring boundaries and the signed support terms.
SMS and MMS
Not verifiedQuestBlue publishes SMS and MMS as separately priced communication channels. The reviewed SIP-trunk pages do not establish messaging eligibility on every voice number, sender registration, API or webhook security, throughput, retention or price for a selected account. Qualify messaging as a separate number, compliance, application and commercial workflow.
Do not infer the SIP mechanics from the portal workflow
The public setup page does not define a universal authentication or registration model. Obtain the selected connection record and technical specification before configuring digest credentials, source-IP trust, registrar, proxy, transport, Contact, expiry or firewall policy.
For one authorized call in each direction, preserve resolver output, source and destination addresses, SIP and authorization identities, challenge, Request-URI, identity headers, provisional and final responses and the first PBX route. A successful REGISTER, OPTIONS response, portal status or outbound profile association is not equivalent to completed bidirectional calling.
Bind numbers and ports to actual route evidence
QuestBlue advertises number search, instant DID ordering and real-time porting. These capabilities do not prove current inventory, a completed port, the selected activation window or the format delivered to the PBX. Preserve the exact number, legal entity, service address, authorization record, submitted request, firm order commitment where applicable and final activation result.
After cutover, test inbound calls from independent networks, outbound caller identity and every required special workflow under an approved plan. Do not cancel a remaining legacy dependency solely because the number appears in the new portal.
Treat media, fax and protection as unresolved until specified
The reviewed public pages do not publish a universal codec, DTMF, RTP, T.38, TLS or SRTP contract for the selected connection. Obtain the current technical specification and configure only the overlapping PBX and service methods.
Preserve offer and answer SDP, telephone-event mapping, RTP endpoints, decoded result, transport, certificate validation and negotiated media-protection profile where applicable. General data-encryption or infrastructure-security wording does not prove protected SIP signaling or media, and the separate online-fax product does not prove T.38 on the voice trunk.
Keep scale language separate from explicit limits
QuestBlue describes elastic scale, burstable functionality and usage-based charging. Those statements do not publish the selected concurrent-call entitlement, calls-per-second rate, burst treatment, access bandwidth, SBC or PBX resources or an observed load result.
Record each quantity separately from number count, minute usage and price. Use a written capacity record and a provider-approved bounded load plan; a successful low-volume call does not establish production capacity or resilience.
Qualify emergency, messaging, support and price independently
Emergency calling and SMS or MMS appear as separate capabilities in QuestBlue material. Confirm entitlement, number mapping, registered or dispatchable location, callback identity, outage alternative, sender registration, application credentials and compliance before relying on either. Do not place an uncoordinated emergency call.
The pricing and FAQ pages publish usage figures, billing increments, minimum-commitment language and portal support. Reconcile them against the signed order, destination rates, numbers, ports, taxes, term, renewal, cancellation, maintenance, escalation and retention. Public prices and support wording do not prove the selected account or an observed response.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- QuestBlue SIP Trunking ↗
- QuestBlue pricing ↗
- QuestBlue frequently asked questions ↗
- QuestBlue number porting ↗
- QuestBlue Emergency Calling API ↗
- QuestBlue customer support ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.