Voxtelesys SIP trunking: DID route profiles, registration and failover evidence

Inventory the DID, trunk groups, route profile and destinations separately

Record the telephone number, its assigned inbound trunk group and route profile, each destination type, priority and target, the outbound trunk group, authentication mode, PBX object and operating owner. Protect credentials, customer identifiers, personal numbers and packet payloads.

Voxtelesys documents Registered PBX, Customer IP, Transfer, Voice API and eFax as different destination types. The DID must also be assigned to the intended route profile. A created registration, enabled IP address or saved destination does not prove that the number uses that route profile or that a later destination is eligible.

Keep registration, static-IP routing and ACL state distinct

The registrar model supplies a domain, username and password and uses SIP REGISTER so the provider can learn the current Contact for inbound calls. Customer IP routing instead sends calls to a configured static public address. A registration indicator is not the health signal for an IP-routed destination.

A registration ACL is another independent control: Voxtelesys says only registration attempts from listed addresses are accepted and the ACL must be updated if the public IP changes. Preserve the authentication result, current Contact, source address, ACL match and selected route destination rather than flattening them into one online/offline state.

Interpret route priority without inventing a trigger table

The current DID-routing tutorial supports multiple prioritized destinations and shows a Registered PBX followed by a priority-two Transfer. The IP-address tutorial likewise places a Customer IP at an explicit priority. Preserve the configured order, first provider attempt, response or transport result, elapsed time and any later attempt.

The reviewed public pages do not publish one complete response-code matrix, timeout schedule, retry count or restoration rule for every destination type. Do not import another provider’s policy, treat every 4xx, 5xx or 6xx as equivalent, or claim that new-call advancement preserves an established dialog.

Treat transfer failover as a separate outbound call leg

The failover-transfer tutorial places a Transfer destination after normal routing and requires an outbound trunk group for that forwarded call. It describes failover when the first destination is down or does not answer, but warns that a cloud PBX can remain reachable even when one office loses local Internet.

Record the primary attempt, transfer selection, outbound trunk group, dialed transfer number, charge owner, answer and media on the forwarded leg. A portal transfer is not proof of customer-access independence, emergency behavior, caller-identity presentation or active-call survival.

Correlate provider records with PBX and media evidence

Use the portal call-record view for the relevant date range and trunk group, then correlate it with provider and PBX call identifiers, edge arrival, Request-URI, delivered number form, first matching route, destination and SIP result. A call-record row is provider evidence; it does not prove packets reached the customer interface or that the intended extension, queue, menu or voicemail handled the call.

After answer, retain SDP offer and answer, chosen codec, DTMF mode, RTP endpoints, firewall decisions, packet flow in both directions and an authorized listening result. TLS and SRTP are optional and require account and PBX configuration; successful registration or routing does not prove protected or intelligible media.

Keep emergency, capacity, number and commercial state independent

Voxtelesys documents E911 as a separate number-and-address workflow with an optional trunk-group association and SMS notification. Confirm activation, caller identity, location, callback, notification and the provider-approved test method separately from ordinary DID routing.

The public service page distinguishes lines, concurrency and calls per second, and warns that CPS does not guarantee concurrent capacity. Number inventory, port status, plan limits, rates, taxes, support and route behavior remain account- and date-specific. No Voxtelesys service, PBX, failover event or live call was tested for this guide.

Trace one Voxtelesys DID from route-profile assignment outward

Use the Voxtelesys DID-route diagnostic to prove profile assignment, destination priority, registration or IP state, provider attempts, PBX handling and transfer outcome.