VoIP.info Provider research

Intermedia SIP Trunking: locations, failover and emergency identity

Evaluate Intermedia's location-based trunk model, customer PBX boundary, per-number failover, emergency-location controls and support assumptions.

Reviewed 2026-10-05Current Intermedia SIP Trunking product page and support articles reviewed October 5, 2026; no account, order, PBX, gateway, number, location, trunk, call, failover, emergency workflow, price, availability, compatibility or support response was testedIntermediateDocumentation based · not lab tested

Define the ordered trunk and the customer PBX boundary

Intermedia describes SIP Trunking as PSTN connectivity for an existing phone system. Its overview distinguishes an interworked IP PBX, which can connect without a gateway, from an analog, digital or non-interworked PBX that requires a gateway. Preserve the exact PBX, software release, gateway or SBC, ordered locations and approved integration path; a generic product page does not establish compatibility.

The overview says Certified Integration Partners test the network before installation, and the configuration-guide index says its partner-created guides are provided for convenience and are not actively maintained. Treat both as workflow evidence rather than a current certification for an arbitrary version. Record who owns PBX configuration, network remediation, carrier activation and post-cutover support.

Documented service facts

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

Outbound authentication

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.

SIP registration

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.

Inbound delivery

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.

Inbound failover

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.

Number and regional availability

Not verified

The product and overview pages describe local, toll-free, remote-market and international DIDs, but they do not prove inventory, portability, address eligibility or serviceability for one account. Require a dated result for every number and site.

Audio codecs

Not verified

The reviewed service pages and multi-product port table do not establish one SIP Trunking order's codecs, packetization, DTMF or media endpoints. Retain the actual SDP offer and answer, payload mapping, RTP endpoints and application result.

T.38 fax

Not verified

The reviewed trunk pages do not establish T.38 or voice-band fax behavior for one order. Qualify exact direction, number, gateway, document set, error correction, switchover and fallback separately.

Signaling and media encryption

Not verified

Intermedia lists SecureSIP and SRTP for hosted services in a broad port table, but that does not prove TLS, certificate validation, SRTP, keying or downgrade behavior on one trunk. Obtain trunk-specific parameters and verify both negotiated legs.

Concurrent calls and burst

Not verified

The product page promotes scalable channels and bursting, but the reviewed sources do not establish purchased concurrency, burst policy, call-start rate, rejection behavior or PBX capacity. Obtain the current order and perform only a bounded acceptance test.

Emergency calling

Documented

HostPilot distinguishes a default 911 number for a PBX location from a dedicated number for a remote phone and requires the phone system to send that dedicated identity. Confirm physical address, eligible caller ID, callback and the provider-approved test path for every endpoint location.

Pricing model

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.

Administration and support

Documented

HostPilot exposes location, number, caller-ID, 911, failover, call-history and limited QoS views. Intermedia's partner-created PBX guides are not actively maintained, so record configuration ownership, exact versions, support escalation and rollback instead of treating a guide as current certification.

SMS and MMS

Not verified

The reviewed SIP Trunking sources do not establish SMS or MMS entitlement on trunk-assigned numbers. Verify number capability, sender registration, consent controls, application path, throughput, retention and fees separately.

Keep location, number and route state separate

Intermedia's HostPilot guide defines a location as the address where a SIP Trunking PBX resides and permits multiple phone systems at one physical address as separate locations. Retain the account location, trunk, assigned DID, inbound INVITE, PBX route and final destination as distinct evidence. A number visible in HostPilot is not proof that the PBX accepted or delivered its call.

The portal also exposes location-level and number-level caller identity. Intermedia notes that the portal value is used only when the phone system sends no outbound caller ID and restricts portal entries to numbers assigned to the company. Capture the identity actually sent by the PBX and accepted on the carrier leg; do not infer caller-name delivery or destination presentation from a portal field.

Exercise per-number failover as a bounded new-call control

Intermedia documents failover routing per phone number to an alternate ten-digit destination when the customer location is detected as unavailable, followed by automatic restoration when monitoring sees the location recover. Preserve the configured number, primary destination, alternate, observed trigger, timestamps, call detail and restoration event.

The public article does not enumerate every SIP response, timeout, retry interval, monitoring probe or established-call outcome. Therefore treat the feature as a new-inbound-call control until an account-specific contract and authorized test prove more. An alternate mobile, PBX or data centre is useful only to the extent that it does not share the failed power, access, account or downstream carrier path.

Map emergency identity to the phone's physical location

HostPilot distinguishes one default 911 number for a trunk location from a dedicated 911 number for a remote phone. For a dedicated number, Intermedia states that the phone system must send that number as caller ID for the corresponding address to reach the emergency operator. Record physical location, registered address, eligible outbound identity, callback number and PBX identity rule together.

The portal requires an updated address when the phone system or remote phone moves and confirmation that the address is within coverage. That administrative confirmation is not a completed emergency call. Follow the provider's current approved test process, avoid an uncoordinated live emergency call and maintain an independently validated fallback until every location is accepted.

Bound network, media and protection claims to the trunk

Intermedia publishes broad port information for several services, including SIP, SecureSIP, RTP and SRTP ranges for hosted platforms. Those tables do not by themselves prove the signaling host, transport, certificate policy, media range or protected-media entitlement of one SIP Trunking order. Obtain the current trunk-specific implementation record before changing a firewall or describing a call as encrypted.

Likewise, a product claim about compatibility or a partner guide does not establish negotiated codec, DTMF, fax or quality. Retain the actual offer and answer, payload mapping, RTP endpoints, DTMF events, packet observations and application result. Keep T.38 and voice-band fax as separate acceptance cases rather than inheriting them from a gateway model.

Require dated capacity, commercial and operational evidence

The product surface promotes scalable channels, DIDs, bursting, reporting and hybrid deployment, while the older support overview mentions a minimum of two trunks and optional services. Neither page establishes one account's concurrent-call entitlement, burst policy, rejection behavior, call-start limit or current price. Obtain a dated quote and order covering locations, channels, bursting, numbers, toll-free service, usage, failover, E911, porting, support, taxes, commitments, renewal and termination.

A public status page or SLA statement is not a test of the customer's PBX, gateway, firewall, access circuit or alternate route. Preserve portal state, configuration ownership, support contacts, change windows, rollback and a bounded acceptance record. The reviewed trunk sources also do not establish SMS or MMS entitlement on trunk-assigned numbers. No account, order, PBX, gateway, number, location, trunk, route, identity, call, media path, failover, emergency workflow, message, capacity, price, availability, compatibility or support response was tested for this guide.

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.