Context issues when dSIP is routing to FusionPBX

[uberFusion]

FusionPBX works when phones are registered to FusionPBX. But I use dSIPRouter. Phones register through dSIPRouter and have the IP's of it.
You can call the DID and dSIP will route the call to Freeswitch then match the DID inbound. The IVR plays, but then the extension returns 404 no found.
The reason is that FreeSwitch is looking in the "public" context instead of the domain context after the transfer from the IVR.

user_exist and local_extension dialplans have been copied to the domain and the context changed. I'm really just stumped here.

Like I said, if the phones register directly to FreeSwitch, the call completes and everything works except for dialing out because the outbound proxy is not correct.
The goal is to close off the ports on Fusion except for port 80/443 on the pblic IP and have dSIP route on the internal acting like a firewall since the domains sync to auth users.
It's kinda like dSIP does not pass the context to FreeSwitch.

Please advise. Google, AI's and docs have been no help.

 

[kenn10]

I asked Grok how to solve your issue and it provides this information (which seems to make good sense.)

Proposed Solution​

1. Associate the Inbound Route with Your Specific Domain:
   • In FusionPBX, go to Dialplan > Inbound Routes and edit the route that's matching your DID.
   • Change the "Domain" field from "Global" (if it's set that way) to your specific domain (e.g., whatever domain the extensions and IVR are under).
   • This sets the ${domain_name} variable early in the call flow, ensuring the transfer from the inbound route to the IVR uses transfer <IVR_ext> XML ${domain_name} under the hood. That switches the context to your domain, where your extensions live.
   • Save and apply the changes (Dialplan > Dialplan Manager > Reload XML if needed).
2. Verify/Adjust IVR Menu Options:
   • Go to Apps > IVR Menus and edit your IVR.
   • For each option that transfers to an extension, confirm the action is set to "Transfer" and the destination is an extension in your domain. FusionPBX should automatically append the context (e.g., transfer 100 XML <your_domain>), but if not, you can manually edit the dialplan entry for the IVR in Dialplan > Dialplan Manager to include it.
   • If your IVR has an "Exit Action," ensure it's also pointed to a domain-context destination if applicable.
3. Confirm dSIPRouter and ACL Setup:
   • In dSIPRouter, double-check your endpoint group for FusionPBX is pointing to the internal SIP port (5060) on FreeSWITCH's IP, not the external (5080). This keeps things trusted/internal.
   • In FusionPBX, go to Advanced > Access Controls > domains, and add dSIPRouter's internal IP (CIDR format, e.g., 192.168.1.10/32) as a node. This treats traffic from dSIP as trusted, allowing seamless domain context access without auth challenges.
   • No need to touch the external profile (5080)—keep it disabled or firewalled if not needed, aligning with your port 80/443-only exposure.
4. Test and Debug:
   • Place a test inbound call to the DID.
   • Check FreeSWITCH logs (Status > Log Viewer or CLI with fs_cli -x 'sofia status') for the context during the IVR transfer— it should show your domain, not "public."
   • If the 404 persists, enable debug logging (fs_cli -x 'sofia loglevel all 9') and look for where the extension lookup happens. If it's still in public, add a temporary dialplan in public context to force a transfer to your domain (e.g., condition for the extension, action: transfer ${destination_number} XML <your_domain>).
   • For outbound calls via dSIPRouter, ensure phones have dSIP as their outbound proxy/SIP server—this should fix the proxy issue you mentioned with direct registration.

This should get everything flowing without compromising security. If the domain association doesn't click it into place, it might be worth checking if dSIPRouter's domain sync is fully propagating the domain in the SIP headers (e.g., To/From)—their docs have a section on FusionPBX hosting for that.