Call routed to wrong domain

P

PrettyBrutalXperience-Guy

Member
Jan 7, 2021
144
22
18
45
Anyone ever experience calls landing in the wrong domain? I stumbled accross multiple examples of calls which should have been terminated at domain A show up in CDR of domain B. Seems like the behavior changed at a point in time, and they're being routed through an IVR in domain A (an identically named IVR exists in domain B which I just now realized is very suspicious, likely it was created when the behavior changed in which case is this a 'bug' or undocumented 'feature'?).
1764888360787.png
 
IVR Menu Code
The code for the IVR Menu is here on GitHub.
- https://github.com/fusionpbx/fusion.../resources/scripts/configuration/ivr.conf.lua

The line that transfers the call for direct dial is this one. So the dialplan context is using the domain_name.
xml:append([[ <entry action="menu-exec-app" digits="]] .. direct_dial_regex .. [[" param="transfer ${cond(${user_exists} == true ? $1 XML ]] .. xml.sanitize(domain_name) .. [[)}" description="direct dial transfer"/>\n]]);
Click to expand...
You can look at the call detail record to see the domain_name's value. If you look at this file you will see that it finds the recording to play for the greeting also with the domain_name. So the greeting would fail if the domain name was wrong.

How it works
  • Direct dial checks to see if the destination is a valid SIP user (extension)
  • If user_exists is true then direct dial transfers the call through the dialplan
    • Using the domain name as the context
  • You could have a dialplan that directs calls to a different domain.
    • The only dialplan to do that on purpose is the is_local dialplan

How to get more information
  • You could look at the call detail records, click on the eye icon to go to the details page for more information.
  • The FreeSWITCH logs for the call would be very helpful.
 
Thanks for the quick and informative reply Mark, turns out this is happening because many of my inbound routes have "presence_id" hardcoded to the domain they were created on and this number/route must have been created in domain B then moved to domain A without a close review of the dialplans.

For others who may be curious, I studied the CDR as Mark suggested and noticed in the "Application Log" portion of the CDR very early on the presence ID is using the wrong domain name. The "Destination" settings for that number looked okay, but in "Inbound Routes" I noticed that presence ID is hardcoded to instead of using the ${domain_name} variable. I quick spot check and I found that not all my inbound routes have this entry, but those that do are hardcoding the domain name rather than using a variable.

Thanks again Mark and kudos on an amazing platform (maintainability is everything, verbose logging and easy access to it makes life easier for those supporting systems, I just didn't give enough attention in my first review of available information).
 
I'm happy you found the answer to the cause of the issue. Good job!

For the verbose logging for FreeSWITCH, the thanks go to Anthony and the FreeSWITCH team.
 
You must log in or register to reply here.
Top Bottom