SureVoIP SIP Trunking: routing, failover and emergency boundaries

Identify the exact ordered service

SureVoIP publishes outbound SIP trunking, inbound number delivery, hosted service and forwarding as distinct capabilities. Record the legal account, order, numbers, outbound entitlement, PBX or SBC, internet access, support level and current portal destinations before applying a template.

Do not infer the outbound authentication or registration model from the inbound destination form. The public pages reviewed here do not define one complete signaling contract for every order, so preserve the current welcome pack and provider-supplied values as primary deployment evidence.

Bind each number to its inbound route

SureVoIP documents SIP delivery to a customer FQDN or IP address, with an optional port that defaults to 5060. Its portal displays UK numbers in international format with 44 replacing the leading zero. Preserve the selected number, configured destination, DNS result, Request-URI, identity headers, PBX match and final destination.

A portal row does not prove that an INVITE reached the current address or matched the intended PBX route. Correlate one timestamped non-emergency call from provider delivery through the final application, and keep personal call data out of published records.

Treat ordered destinations as timeout failover

SureVoIP says one number can have up to five destinations and later entries are attempted when the preceding destination times out. The same guide says Busy and Unavailable do not count. Record the ordered destinations, timeout behavior, response that ended each attempt, alternate capacity and recovery procedure.

Do not generalize this into failover for every SIP response, active-call survival or a published detection interval. Exercise an approved new-call test window, observe the exact attempt sequence, and verify return to the primary destination without placing an emergency call.

Measure media instead of copying firewall examples

SureVoIP support pages show typical customer-side SIP and RTP ports for Asterisk and FreeSWITCH and ask operators to capture the actual ports used by their system. Those examples are not a complete provider media-source contract. Preserve both SDP bodies, each connection address and port, both RTP directions, negotiated payloads, decoded audio and DTMF evidence.

Apply least-privilege rules to the current provider-confirmed boundary and selected topology. Do not expose PBX management, permit all UDP or disable the firewall to manufacture a result. Treat fax, TLS, SRTP and provider source ranges as unverified until current service-specific documentation or observed negotiation establishes them.

Keep emergency access attached to location and power

SureVoIP says 999/112 access is available within England, Wales, Scotland and Northern Ireland, but warns that internet or power failure can remove all service and that number or location details may not reach the operator. It requires the address of a principally fixed service to be registered and recommends a landline or mobile when possible.

For each site, confirm the applicable order, registered address, callback identity, user instructions, power and access dependencies and an accessible alternative. Follow a provider-approved validation procedure; never place an uncoordinated emergency test call.

Reconcile capacity, price and acceptance evidence

SureVoIP describes dynamic outbound capacity but does not publish the selected concurrency or calls-per-second limit. Its terms require advance notice before disproportionate activity. Obtain current limits and provider approval before a bounded load test.

The product page contains example rates, while the terms make the order form and current charges material. Preserve the dated quote, billing increments, taxes, term, cancellation treatment and support commitment. Build an acceptance matrix for inbound, outbound, identity, audio, DTMF, timeout failover, recovery and rollback, recording observed results without turning catalogue claims into laboratory validation.

When the next SureVoIP destination is not tried

Use the SureVoIP destination-failover diagnostic to separate an absent alternate, a first-destination response, a genuine timeout and failure after delivery to the next route.