Easybell SIP trunks: registration, Trusted IP, FQDN and fallback evidence

Freeze the connection and each directional identity mode

Record the Easybell connection, assigned number or block, current inbound authentication mode, current outbound authentication mode, registrar, transport, public address or FQDN, number-signaling format and PBX owner. Easybell exposes inbound and outbound Trusted IP choices separately, so one direction cannot establish the other.

Export the effective portal settings before editing. A successful outbound call or REGISTER does not prove the inbound delivery target.

Distinguish registration from inbound IP-only delivery

With SIP-password authentication, the device registers using its SIP username and password and its address is not the identity. With inbound IP authentication, Easybell says credentials are ignored and calls are sent to the stored public addresses instead. A PBX that continues to register but is not one of those stored addresses will no longer receive inbound calls.

Preserve the selected mode, provider attempt, customer-edge receipt and PBX result. Do not repair an inbound IP-target mismatch by rotating an unrelated password.

Read trusted addresses as a sequential new-call list

Easybell permits up to four inbound Trusted IP addresses and documents sequential attempts when the first is unreachable. That describes provider-side selection for new inbound calls; it does not establish the trigger detail, timer, retry count, restoration interval, equal load sharing or survival of an established call.

Retain the configured order, public address after NAT, each observed attempt and final result. A reachable firewall is not proof that Asterisk or FreePBX matched and answered the call.

Treat trusted FQDN as DNS-backed identity

Trusted-FQDN authentication replaces a fixed IP entry with a domain whose current answer identifies the target. Easybell validates the submitted domain and recommends TCP or TLS plus leading-plus E.164 signaling for the cited cloud example. Those recommendations are not universal account state.

Preserve the configured FQDN, authoritative and recursive answer, TTL, provider resolution time, actual destination, certificate result when TLS is used, delivered number and PBX match. Portal acceptance does not prove later DNS resolution or route convergence.

Keep trusted-IP sequencing apart from offline forwarding

Automatic fallback routing is configured under the Offline status and forwards incoming calls to a chosen telephone number when none of the VoIP devices can connect or are online. That forwarded PSTN or VoIP leg is distinct from trying the next stored Trusted IP.

Record the fallback target, its independent access path, caller treatment, capacity, charges and observed trigger. The reviewed pages do not establish instantaneous detection, every failure class, return-to-primary timing or established-call continuity.

Prove PBX, media and recovery after provider selection

For one authorized test call, correlate the Easybell attempt with customer-edge packets, Asterisk endpoint identification, assigned context, delivered E.164 or local number form, first matching route, answer and SDP. Then inspect RTP endpoints, negotiated codec and decoded audio in both directions.

Change only the demonstrated owner: directional authentication mode, stored address order, FQDN or DNS, transport, number normalization, firewall, PBX identification, route or media policy. No availability, compatibility, pricing or laboratory result is claimed.

Diagnose Easybell inbound identity before changing the PBX

Use the Easybell inbound identity diagnostic to correlate the selected inbound mode, stored address or FQDN, provider attempt, PBX match and fallback.