VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

Superloop Business Voice SIP Trunks: order, PBX and fault evidence

Keep Superloop SIP Trunks, TotalTalk, Inbound and Teams Voice distinct while tracing the service order, PBX, DID, network and fault boundary.

Reviewed 2026-10-28Current Superloop Business VoIP and SIP material, Voice specifications, terms index, Business Voice Service Schedule applicable to services entered from 10 March 2026, business support and outage surfaces were reviewed October 28, 2026. The public record does not establish which service, agreement, order, site, access, PBX, SBC, registrar, authentication, source trust, signaling target, transport, codec, DTMF method, media range, encryption option, DID state, emergency-location record, capacity, fault class, restoration target, price, availability or compatibility applies to one customer. No Superloop account, quote, order, portal, circuit, router, PBX, SBC, credential, endpoint, DID, port, queue, forwarding rule, packet, call, media stream, outage, fault ticket, emergency outcome, price, availability, compatibility, incident or support response was inspected or testedAdvancedDocumentation based · not lab tested

Identify the ordered Superloop voice service

Superloop’s current business page distinguishes hosted PBX from SIP, while the March 2026 Business Voice schedule names TotalTalk, SIP Trunks, Inbound and Microsoft Teams Voice within one service family. Those labels do not describe one interchangeable technical product.

Retain the exact service order, product name, site, requirements sheet, term and governing schedule. A family-level inclusion, portal function or hosted-platform feature is not proof that a SIP-trunk order contains it.

Documented service facts

Reviewed 2026-10-28. Compare SIP trunk services →

SIP authentication

Not verified

The reviewed public records do not establish one registrar, credential or source-trust profile. The service order and implementation record govern.

SIP registration

Not verified

Registration, OPTIONS, source identification, expiry and Contact behavior are not published as one universal Superloop SIP Trunk profile.

DIDs and inbound delivery

Documented

The schedule covers DID porting and configuration and warns of possible inbound interruption. One number state, delivered identity and completed route remain unverified.

Continuity and outage evidence

Not verified

The reviewed records do not establish one included SIP-trunk failover design. Outage posts, alternate access, provider routing and PBX policy remain separate.

Access and demarcation

Documented

Superloop describes connecting existing phone systems to its IP network and depicts access examples. The exact ordered handoff and responsibilities govern.

Signaling and media

Not verified

No universal public codec, DTMF, media-range or SIP transport profile was established. Issued implementation data and observed negotiation govern.

Fax and non-voice use

Not verified

The reviewed current records do not establish fax, T.38, modem, alarm or EFTPOS compatibility for one order.

Transport and media protection

Not verified

The data sheet describes dedicated and secure service at a design level, not universal TLS, certificate, SRTP or end-to-end protection evidence.

Channels and call rate

Not verified

Public pages describe scalability but do not establish one account channel quantity, call-attempt rate or burst policy. The service order governs.

Power and emergency calling

Documented

The schedule says power or internet outage can prevent calls including 000 and advises an alternative method. One site location and route remain unverified.

Term, price and availability

Not verified

Charges, service term, feasibility, availability and activation depend on the agreement and service order. Public material is not a current quote.

Faults and support

Documented

The schedule defines P1–P4 examples, fault tickets and response/restoration targets but describes restoration and availability as best-efforts boundaries.

SMS and MMS

Not verified

The reviewed Superloop Business Voice and SIP records do not establish SMS or MMS on SIP-trunk DIDs.

Bind the PBX and access demarcation to the order

The product page says SIP connects an existing phone system to Superloop’s IP network. The data sheet depicts Superloop access and managed-router examples, while the schedule requires customer firewall or infrastructure changes where needed. It does not publish one universal access or handoff.

Preserve the ordered circuit or internet path, router or SBC, addressing, routing, firewall, PBX and customer/provider responsibility boundary. Link reachability or a supplied router does not prove SIP identity, DID delivery or media.

Do not invent a public SIP profile

The reviewed public records do not establish one registrar, authentication or source-trust model, signaling target, transport, codec, DTMF method, media range or encryption profile for every Superloop SIP Trunk. The data sheet’s dedicated, secure and high-quality statements are design descriptions rather than one loaded configuration.

Use the issued implementation record and loaded PBX state. Keep registration, OPTIONS or source identification, accepted requests, negotiated SDP, packets, decoding and audible result as separate evidence.

Keep DIDs, platform features and porting separate

The schedule discusses DID porting and configuration, 13/1300/1800 numbers, queues, IVR, forwarding and office hours at family level. Its defined Business Voice Platform, however, names TotalTalk or Microsoft Teams Telephony. Do not transfer every platform function into a SIP-trunk order without the order or implementation record.

Preserve number ownership, accepted port, provider attempt, delivered identity, PBX receipt, route match, feature owner and completed call independently. The schedule warns that porting may interrupt inbound service.

Treat power, internet and emergency readiness as site evidence

The schedule says a power or internet outage can prevent ordinary and 000 calls; it advises an alternative such as a mobile phone. It also says quality depends on LAN, router and QoS conditions.

Document power, access, alternate-calling method, number and location records for the actual site. Do not place an uncoordinated 000 call or turn general outage language into proof of one trunk’s emergency route, location or callback behavior.

Keep fault targets and availability claims bounded

The schedule defines P1 through P4 examples, response and restoration targets, a fault-ticket process and planned-outage notice. It also says restoration is best endeavours and its Service Availability Target is best efforts only without service credits.

A ticket number, priority, update or closed status is not proof that the carrier boundary caused the incident, every call path recovered, media worked or the service met a measured availability percentage. Preserve the order, exclusions, timestamps and end-to-end retest.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Troubleshooting · Current Superloop Business VoIP and SIP material, Voice specifications, terms index, Business Voice Service Schedule applicable to services entered from 10 March 2026, business support and outage surfaces were reviewed October 28, 2026. The public record does not establish which service, agreement, order, site, access, PBX, SBC, registrar, authentication, source trust, signaling target, transport, codec, DTMF method, media range, encryption option, DID state, emergency-location record, capacity, fault class, restoration target, price, availability or compatibility applies to one customer. No Superloop account, quote, order, portal, circuit, router, PBX, SBC, credential, endpoint, DID, port, queue, forwarding rule, packet, call, media stream, outage, fault ticket, emergency outcome, price, availability, compatibility, incident or support response was inspected or tested

Superloop SIP trunk order, DID, registration or fault boundary fails

Find the first divergence across the ordered Superloop service, access, PBX, SIP identity, DID, media, outage and fault-ticket evidence.

Read guide →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Guide

SIP trunk channels and simultaneous calls

Size external capacity around busy-hour demand and the provider’s counting rules.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide

NAT for VoIP: signaling and media addresses

Map each translation boundary and compare advertised destinations with reachable addresses.

Read guide →
Guide

QoS for VoIP

Apply prioritization where you control the bottleneck and understand what happens beyond it.

Read guide →
Guide

PBX credentials and extension secrets

Keep administrator, handset, trunk and backup identities separate and retire them deliberately.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Guide

Business number porting: a cutover checklist

Keep ownership records, dependencies and a fallback plan aligned with the gaining provider’s process.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Troubleshooting · Current SIPTRUNK IP-authentication, registration, status, inbound-call, failover, interconnection and general-configuration documentation reviewed October 14, 2026; the sources describe mutually exclusive credential-registration and static-public-IP modes but do not prove the selected account mode, public address, gateway resolution, Contact, registration, number assignment, route, failover treatment, capacity, compatibility or completed call, and no account, portal, credential, PBX, firewall, DNS answer, packet, registration, number, route, failover event, media stream or live call was inspected or tested

SIPTRUNK registration or IP-authentication mode does not match the call path

Determine whether the trunk uses credential registration or static-IP authentication, then trace the exact public address, gateway, Contact or stored destination, provider state, inbound route and failover treatment.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Current Sangoma outbound-route guidance, current Asterisk Dial and troubleshooting documentation, and SIP standards reviewed October 5, 2026; no phone, PBX, carrier or live call test

Outbound VoIP calls fail: locate the broken call leg

Classify one failed call, then follow the exact digits through the phone, PBX route, attempted trunk, remote response, answer and media.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

VoIP call connects but has no audio

Separate endpoint audio selection from a media path that fails in both directions.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →