Freeze one failed call and the effective portal state
Record the called number, timestamp and timezone, Easybell connection, inbound and outbound authentication modes, stored IP order or FQDN, transport, number-signaling format, Offline forwarding target and provider call evidence. Add customer-edge receipt, PBX identification, route, response, SDP and audio.
A green registration indicator is relevant only to the credential-registration path; it cannot prove an inbound IP-only or FQDN target.
Determine which inbound identity model owns delivery
If inbound SIP-password authentication is selected, preserve REGISTER, challenge, Contact and expiry. If IP authentication is selected, verify the public static address stored in the portal and whether Easybell attempted it. Credentials are ignored for that inbound mode. If FQDN is selected, preserve the configured domain and the provider-relevant DNS answer.
Do not combine successful facts from different modes into one assumed path.
Follow the selected address or FQDN to the edge
For Trusted IP, compare each provider attempt with the configured sequential order and the public address after NAT. For FQDN, compare the submitted domain, current authoritative answer, recursive answer, TTL and observed destination. If no attempt reaches the customer edge, preserve that bounded negative evidence before changing the PBX.
Portal acceptance, DNS resolution and packet arrival remain separate events.
Separate next-address attempts from Offline forwarding
A later stored Trusted IP is another SIP destination in the sequential list. The Offline rule instead forwards the incoming call to a chosen telephone number when devices are offline or cannot connect. Record which mechanism acted, its attempt and its result.
Do not infer a universal trigger timer, SIP-response matrix, retry count or restoration interval from either guide.
Prove PBX matching and media after edge receipt
At the edge, preserve source, destination, transport, Request-URI and identity headers. In Asterisk or FreePBX, record endpoint identification, assigned context, delivered number form and first matching inbound route. Then distinguish SIP answer, SDP, RTP flow, negotiated codec and decoded two-way audio.
A correctly selected Easybell target does not establish PBX acceptance or working media.
Correct the earliest mismatch and bound the result
Change only the demonstrated owner: inbound mode, stored IP, IP order, FQDN or DNS, transport, firewall, PBX identification, number normalization, route, Offline target or media policy. Repeat the same call and verify the intended result and rollback.
This does not prove every number, address, DNS resolver, fallback condition, compatibility, availability, pricing or established-call survival. No Easybell account, PBX, packet or call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Easybell general VoIP configuration ↗
- Easybell Trusted IP authentication ↗
- Easybell SIP-trunk authentication by trusted FQDN ↗
- Easybell automatic fallback routing ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.