Start with the trunking user and current PBX driver
OnSIP documents Hosted Trunking as a hosted-PBX user configured to route calls to and from a customer-administered PBX. Enabling it creates authentication information and stores the trunking flag with the registration. Preserve the selected account, PBX, user, SIP address, authentication username, domain, secret owner and current registration before changing routes.
OnSIP's public Asterisk example targets Asterisk 1.8 or newer and uses sip.conf, sip show registry and the legacy SIP channel driver. Asterisk now says chan_sip was deprecated in 17 and removed in 21. Treat the OnSIP article as provider-behavior evidence, not a PJSIP or FreePBX paste-in template; translate the handoff to the installed driver and version.
Documented service facts
Reviewed 2026-10-22. Compare SIP trunk services →
SIP authentication
DocumentedEnabling Hosted Trunking creates authentication information for the selected user. Preserve the account-generated username, authentication username, domain and secret owner; the public example does not establish a universal current digest, rotation, source-address, transport or certificate contract.
SIP registration
DocumentedOnSIP stores the trunking flag with registration and says re-registration is needed to clear it. Its Asterisk example uses legacy chan_sip; Asterisk removed chan_sip in version 21. Translate the assigned handoff to the loaded current driver and validate a sanitized REGISTER and response.
Inbound delivery
DocumentedTransferred PSTN Gateway numbers begin ringing the new OnSIP PBX immediately. Preserve number and transfer state, timestamp, provider attempt, called identity, edge receipt, current PBX context and destination rather than treating account inventory as proof of routing.
Routing and failover
DocumentedOnSIP documents rerouting an inbound call to a selected external number after a configured ring time and warns that PBX inbound rules may conflict or pre-empt it. Preserve provider timer, PBX response, local forwarding, external attempt and loop prevention separately.
Number and regional availability
Not verifiedThe reviewed pages establish that OnSIP can transfer existing PSTN Gateway numbers and that paid business plans provide PSTN gateway service; they do not establish current number availability, portability, serviceability or lead time for a requested rate centre or address. Retain dated qualification and port responses for every number block and activation date. Do not confuse a free SIP address with an orderable PSTN number.
Audio codecs and DTMF
Not verifiedThe reviewed trunking pages do not publish one complete current codec, packetization, DTMF, early-media, transcoding or media-address profile. Obtain the current OnSIP handoff for the selected PBX and preserve both SDP bodies, negotiated payload mapping, RTP evidence and decoded digits for every required call path. A PBX-specific setup article is not proof of negotiation on the production call.
T.38 fax
Not verifiedThe reviewed trunking records do not establish T.38 or audio-fax entitlement, direction, switchover behavior, gateway compatibility, redundancy or page limits. Treat fax, alarm, elevator and other non-voice devices as separate workflows with their own service confirmation, path, power, monitoring and acceptance evidence.
Signaling and media encryption
Not verifiedThe public Free Plan page discusses encrypted peer-to-peer media when both parties use the OnSIP app, but that is not a trunk security profile and must not be generalized to PSTN or PBX call legs. The reviewed trunking pages do not establish SIP TLS versions, certificate validation, client certificates, SRTP suites, keying or protected legs for one trunk. Verify signaling and media protection separately on the selected route.
Concurrent calls and call starts
Not verifiedThe reviewed first-party support pages do not establish the selected account's simultaneous-call allocation, calls per second, burst behavior, codec bandwidth, registration scale or PBX resource limits. Bind each numeric limit to the current order and an approved load plan. A number's ability to receive multiple calls or a plan description does not prove account, access or PBX capacity.
Emergency calling
DocumentedOnSIP states that Hosted Trunking subscribers cannot use its E911 feature. Contract a separate compliant emergency path before production; map locations, callback identity, notification and outages, and use only provider-approved non-live validation.
Pricing model
Not verifiedPublic 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.
Administration and support
DocumentedPreserve selected account and user, trunking flag, registration, current driver, 000 outbound transformation, caller identity, number transfers, ring timer, external destination, authorized changes and tickets. Do not paste the legacy chan_sip example into a current PJSIP deployment.
SMS and MMS
Not verifiedThe reviewed trunking records do not establish SMS or MMS entitlement on trunk numbers, sender registration, API access, throughput, webhook security, retention or price. The Free Plan's messaging and SIP-address capabilities are a different product context and must not be treated as trunk-number messaging. Require a separate current service record and workflow.
Prove the 000 outbound flag at the provider leg
OnSIP says all Hosted Trunking calls require a 000 prefix as the flag for trunking-style delivery. Its Asterisk example also instructs the operator to confirm the outbound dialed number contains 000 while the resulting outbound INVITE targets the ordinary destination at sip.onsip.com. Preserve the user-entered digits, normalized PBX digits, selected route and actual provider-leg Request-URI.
Apply the prefix exactly once in the outbound transformation intended for this trunk. A user-facing access code, a PBX route prefix and OnSIP's provider flag are different stages. Registration success does not prove that the correct number or caller identity reached OnSIP.
Treat number transfer as an immediate routing cutover
OnSIP warns that transferred PSTN Gateway numbers begin ringing the new OnSIP PBX immediately. Inventory each number, current owner, old destination, transfer action, new trunking user and rollback authority before making the change; reconfigure and verify the intended PBX object first.
For an inbound attempt, retain the number record, transfer timestamp, provider attempt, Request-URI or called identity, source, edge receipt, PBX context, normalized digits and first matching destination. A number listed in an account is not proof that the transfer completed or that the PBX matched it.
Separate provider ring-time failover from PBX rules
OnSIP documents a ring-time control that can reroute an inbound call to a selected external number after attempting the customer PBX. It also warns that inbound rules on the PBX may conflict with or pre-empt that preference. Preserve the saved timer and destination, the provider attempt, PBX provisional and final responses, local forwarding and the actual external attempt.
This public procedure does not establish every trigger, timer value, loop guard, retry order, established-call behavior or restoration rule. Use an approved non-emergency test and do not manufacture an outage merely to observe rerouting.
Keep registration, routing and media as separate states
The OnSIP Asterisk article lists a registration transaction, formatted inbound INVITE, outbound caller identity, 000 prefix and outbound authentication as separate checks. Follow that separation on the current platform: configuration loaded, registration accepted, provider request received, endpoint or trunk identified, route matched, final response returned and media negotiated.
If signaling completes, compare both SDP bodies, selected codec and DTMF payload, RTP endpoints, NAT translation and packets in each direction. The reviewed public trunking pages do not publish one universal current transport, codec, encryption, fax or capacity profile.
Design emergency calling outside Hosted Trunking
OnSIP says a user configured for Hosted Trunking cannot use other hosted-PBX features including E911, and its current E911 page states that E911 is not available to Hosted Trunking subscribers. Do not infer emergency service from an OnSIP number, registration or normal outbound call.
Contract and validate a separate compliant emergency path before production. Map location, authorized callback identity, notification, power and access failure, keep an independent means of reaching emergency services and use only the provider-approved non-live validation method. Obtain dated commercial terms for all services; no account, route, call or emergency workflow was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- OnSIP Trunking ↗
- Enabling OnSIP Trunking ↗
- OnSIP Trunking Inbound Call Preferences ↗
- Enable E911 ↗
- Asterisk Configuration for OnSIP Trunking ↗
- Asterisk documentation: Configuring chan_sip ↗
- OnSIP Support ↗
- OnSIP Free Plan ↗
- OnSIP E911 emergency response locations ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.