A gateway is the provider relationship
A gateway describes another VoIP server or provider, including its proxy and any required credentials or registration. Outbound routes decide which calls use it. Creating a gateway alone does not define which users may call which destinations. Use the provider's documented identity and trust model. IP-authenticated service and registration-based service require different checks. A non-registering gateway is not automatically failed merely because it has no registration success indicator.
A destination handles an incoming number
FusionPBX destinations can define an incoming DID and its action, with corresponding inbound routing. Match the number format actually delivered by the provider and the intended domain. Keep the public inbound context restricted to legitimate destinations. Send a test call to an extension first, then add a ring group, IVR or time-dependent destination. Verify invalid input, no answer and after-hours behavior. This makes the first failing transition visible when a more complex route does not work.
Test trust and routing separately
Verify the provider can reach the intended listener, that its source is authorized and that the called number matches the right rule. Then test outbound permissions and caller identity on a controlled destination. Do not broaden global trust rules to repair a number-format mismatch. For a failure, retain gateway state, incoming Request-URI, selected domain/context and the resulting FreeSWITCH call leg. If a shared gateway serves multiple tenants, explicitly test which destinations each tenant may use and where incoming numbers are delivered.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.