The log shows an incoming call from 828xxx2212 to the DID 828xxx7774, which is internally routed to ring group 281 in the mydomain.cloud context. The ring group is configured for an enterprise strategy (ring all), and it attempts to originate an outbound leg to the external cell phone number 1770xxx4144 (which appears to be 1-770-xxx-4144, likely with a '1' prefix for US dialing).
The call to the cell phone fails immediately on the outbound b-leg (loopback/1770xxx4144-b) with hangup cause NORMAL_CLEARING. This occurs because:
- The outbound leg inherits variables from the inbound a-leg, including call_direction=inbound.
- In the dialplan (mydomain.cloud context), the outbound route sections (e.g., [call_direction-outbound], [Bulkvs.10-11-NANP]) require ${call_direction} to be empty (^$) or set to outbound for matching. Since it's set to inbound, none of the outbound routes match.
- The dialplan falls through to unrelated sections, eventually hitting [is_zrtp_secure], which fails (no ZRTP), and executes the anti-action eval(not_secure). This is the last instruction, so FreeSWITCH treats it as the end of the dialplan and hangs up the leg.
No SDP negotiation occurs on the failed leg (hence no codec mismatch visible here), but the L16/L16 in your CDR likely reflects an internal default or prior attempt before the route failure.
Fix Suggestions
- In FusionPBX, edit the ring group (Apps > Ring Groups) and ensure external destinations have proper outbound permissions. Set call_direction=outbound explicitly for external legs in the bridge string (via Advanced > Dial String or custom Lua edits in app.lua ring_groups).
- Add toll_allow=domestic (or as needed) to the ring group or the originating extension's user settings (Accounts > Extensions > edit > Toll Allow).
- If using a custom outbound route, remove or adjust the ${call_direction} =~ /^$/ condition to allow inherited values, or unset call_direction before bridging: {call_direction=} in the originate.
- Test by dialing the cell directly from an internal extension to isolate route issues.
- Update FusionPBX to the latest patch (Advanced > Upgrade > Source) if this is a known bug in 5.5.
