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.

 

[uberFusion]

My settings are correct. Inbound, gateway, IVR, Outbound, Domain Snyc etc...
Incoming calls are in context public. The domain user_exsits was not setting the context. Even though the IVR transfered the call to the extension, FreeSwtich was looking in context Public. You would think the IVR would transfer the context, but it does not. Used a Action Set context=${domain_name} in user_extists of the domain to force context.

Almost, at least I have a different error! The extensions are still not found even though sofia status lists them as registered in that domain.

Note, if the phones are registered directly to Fusion then can call each other and ring, plus the IVR works. The IP's of the phones when the SIP Server / SIP Proxy is pointed to the fusionPBX domain is the phones's public IP. Since I want to use dSIP I have to point the phones at dSIP. When they register in FusionPBX through dSIP the IP's are that of dSIP. Now they dont't work because that IP is the trusted Provider IP. I think this confuses FusionPBX.

Is it possible to get dSIP to pass the phone's actual public IP to Fusion? This would solve these issues.

 

[uberFusion]

Found something:
"configuring dSIPRouter to use the autonat: prefix for the external IP in the SIP profile,"
"If you are using FreeSWITCH behind dSIPRouter and want to use autonat: in FreeSWITCH’s SIP profile, you should configure it directly in FreeSWITCH’s sip_profiles/external.xml file by setting:

"ext-rpt-ip" / "ext-sip-ip" to autonat

This allows FreeSWITCH to dynamically determine the external IP using UPnP or NAT-PMP."

I dom't think this is right. All that would do is set the IP to the external IP of the server instead of the local lan.

 

[pbxgeek]

In my experience setting up the DSip router, there were so many issues that many gave up. When calls are working, problems start happening with music on hold, parking, BLFs, etc. I'd like to know if anyone out there has actually gotten it working all the way and is using it in production?

 

[uberFusion]

In my experience setting up the DSip router, there were so many issues that many gave up. When calls are working, problems start happening with music on hold, parking, BLFs, etc. I'd like to know if anyone out there has actually gotten it working all the way and is using it in production?

Exactly. I'm at that point. The dialplan in Fusion can work perfect by itself. Add dSIPRouter and it all breaks. Best I've got so far was to have a call come in then get to the IVR. It fails to find the ext after that. Either 404 not found, 407 proxy auth or the latest 480 not available. I haven't even successfully made a call out yet.
Most issues are context being set to public rather than transfer to the domain. Even though in many places there are actions to set the context to the domain_name.