Freeze one failed inbound attempt and a working outbound control
Record the ordered Simwood service, called number, timestamp and timezone, assigned server, outbound challenge result, current registration, provider attempt, edge receipt, PBX response, route result and media result. A working outbound call is useful only as a bounded credential and egress control because Hosted outbound can authenticate after a 401 without a REGISTER.
Redact credentials, telephone numbers, addresses and call content. Do not treat a portal label or command output from another node as evidence for the failed attempt.
Prove the current Hosted registration
Capture the configured registrar, DNS answers, selected address and transport, REGISTER challenge, authenticated REGISTER, accepted expiry, Contact user and current binding. Compare the provider-observed Contact with the PBX object and node intended to receive this number.
If registration is absent or stale, correct that boundary before changing inbound routes. Do not transfer a Carrier, Wholesale, Partner or Direct authentication assumption into the Hosted trunk.
Compare Request-URI and To as different routing inputs
Preserve the inbound INVITE Request-URI and To header. Simwood documents the Request-URI user as the trunk username by default or the registered Contact user when supplied, while To carries the called number for routing. Compare both with PJSIP endpoint identification, endpoint context and the first loaded FreePBX or Asterisk match.
A route keyed only to one of these values can miss a valid call. Normalize the demonstrated input at the narrowest owner; do not enable anonymous SIP or an unrestricted catch-all route.
Prove whether the provider attempted the customer edge
Join the portal or support correlation record to customer-edge capture using the same timestamp and identifiers. If there is no provider attempt, investigate number assignment, time-of-day routing, forwarding or failover at the provider boundary. If the attempt reaches the edge, preserve source, transport, TLS result, SIP response and the owning PBX object.
The current Partner and Direct whitelist is product-scoped and not all-inclusive. The older Asterisk 16 sample address list is not a current complete firewall input. Obtain the current Hosted policy instead of copying either list blindly.
Inspect generated and loaded PBX state
For FreePBX, compare the GUI trunk and inbound route with generated PJSIP configuration and loaded endpoint, AoR, auth, registration, identify and dialplan state. For hand-managed Asterisk, compare the installed branch and loaded objects with the version-scoped Asterisk 16 example. Preserve the first divergence before editing.
A visible route, registration object or identify section is not proof that the running process loaded it, selected it for this source or reached its destination.
Correct the earliest mismatch and repeat the same call
Change only the earliest demonstrated fault: product scope, number route, registrar, Contact, expiry, network policy, endpoint identification, context, called-number normalization, inbound destination or authorized failover rule. Repeat the same inbound call, verify answer and two-way audio, and restore any temporary diagnostic or failover change.
Do not infer one universal failure timer or response-code matrix from a single result. No Simwood account, trunk, registration, firewall, PBX, route, packet, media stream or live call was inspected for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Simwood Hosted SIP Trunks ↗
- Simwood hosted trunks interop ↗
- Simwood hosted trunk overview ↗
- Simwood Asterisk 16 hosted trunk example ↗
- Simwood hosted TLS/SRTP settings ↗
- Simwood Partner and Direct IP addresses and whitelisting ↗
- Simwood portal overview ↗
- Simwood Carrier Services API v3 ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.