By default, fusionpbx will dial all extensions internally. However, calls to any other number on the system, be it Destinations, IVR Menus, Time Conditions, Queues, Ring Groups, will always use an outbound route (assuming there is a valid match). I am trying to keep these calls internal as it's a waste of money to use an outbound route for these calls. How can I create an outbound route that sends a call from extension 101 to time condition 1000. Sending the call to app is_local does not work.
Internal Calls
- Thread starter dcitelecom
- Start date
whuuuut?
on a domain if you dial the number of an IVR, time condition, ring group, et cetera, you will be directly dialing that said item. The call remains local and remains on the domain. Equally, when you select any one of these entities as the action from a dropdown, your call still remains local and on the domain.
Perhaps more explanations in detail would help.
on a domain if you dial the number of an IVR, time condition, ring group, et cetera, you will be directly dialing that said item. The call remains local and remains on the domain. Equally, when you select any one of these entities as the action from a dropdown, your call still remains local and on the domain.
Perhaps more explanations in detail would help.
Unfortunately, I see extensions dialed internally but every other number on the system is dialed using an outbound trunk. This is consistent with the answer given in this post https://www.pbxforums.com/threads/should-pbx-know-a-call-is-internal.3645/ and unfortunate as it's a waste of money.
This must be how your dialplan external routes are set up. Your conditions for sending external calls through the trunk are too lose so it matches even internal extensions. I'd recommend you investigate the external dialplan to only match outbound calls.
Thanks but this is not about extensions. That part works fine. It's about recognizing the numbers assigned to IVR menus or time conditions as internal numbers. For example, I have a Destination "15141234567" pointing to a time condition 5141234567 which points to IVR 1234567 and then to extension 101. In my scenario, I want the system to know that ALL of these numbers are internal but only 101 is recognized as internal. All other numbers are sent to an outbound trunk.
Shoudn't
condition ${user_exist}= false, the first line of every outbound route, address exactly this problem? If I dial an internal number that exists on my system, this condition should break the outbound route and skip it.Yes because all my extensions represent local numbers in Toronto and must be 10 digits. Thus, 10-digit calls can be internal to extensions on the system or external to other local numbers in Toronto and I need an outbound route for 10-digit local calls. Fortunately, the ${user_exist} false condition works ok to screen 10-digit destination numbers for internal calls.
However, if my end user is a business with extensions numbered 101, 102, etc. then the 10-digit local number must be a Destination, ring group number or IVR menu number and the ${user_exist} false condition does NOT work because the ${users} variable ONLY looks at extensions. I don't know if it would break things but IMHO the ${users} variable should also check for the existence of entities like Destinations, IVR Menus, or Time Conditions. That would certainly fix my issue.
However, if my end user is a business with extensions numbered 101, 102, etc. then the 10-digit local number must be a Destination, ring group number or IVR menu number and the ${user_exist} false condition does NOT work because the ${users} variable ONLY looks at extensions. I don't know if it would break things but IMHO the ${users} variable should also check for the existence of entities like Destinations, IVR Menus, or Time Conditions. That would certainly fix my issue.
@dcitelecom Why this? you have some special use case for those 10-digit extensions?
I think using the is_local dialplan is your solution here and I know you said "is_local does not work", does that mean you couldn't get it to work OR it does not help your use case?
Yes. I provide local line service in Toronto and local numbers are 10 digits. That's why the extension numbers must be 10 digits.
is_local does not help in my case because it also uses the ${user_exist} false condition to determine what is local
The issue is really the ${user_exist} variable. It only looks at extensions and ignores the rest of the system
I still don’t understand how is your service any different than ours. We provide 10 digit numbers to users that are pointed to short local extensions. And everything works as expected. A 10 digit DID will point to a 3 digit IVR or 3 digit Ring group. This is how the system is designed to work.
If there is some requirement beyond the intended use you should look into writing your own dialplan. Lua scripting is very powerful and can do better than ${user_exists} variable.
If there is some requirement beyond the intended use you should look into writing your own dialplan. Lua scripting is very powerful and can do better than ${user_exists} variable.
I would never use >= 10 digit length numbers for extensions, ivrs, anything else. >= 10 digits length is reserved for DIDs in North America. And if you do any smart dialing that prepends the area code on a 7 digit dial out you would not use >= seven digits length for anything other than DIDs.
North America outbound routes are going to be reserved for>\ >= 10 digit length.
Keep your "extensions" of any kind between 3 & 6 digits in length to avoid far more work than needed.
North America outbound routes are going to be reserved for>\ >= 10 digit length.
Keep your "extensions" of any kind between 3 & 6 digits in length to avoid far more work than needed.
Thanks everyone for your amazing replies. My system uses the e.164 numbering format. Thus Destinations are configured to match what we get from our DID provider i.e. 11 digits (1+area code + number) and extensions are configured to match what the end user dials when he wants to make a local call i.e. 10 digits. This way, any 10-digit call on our system is local first and with thousands of end-users calling each other, we avoid paying long-distance charges for many calls every month. There might be different ways to do this but this way is working fine for us. The only issue we found is incorporating business numbers into this dial plan because their extensions are 3 to 4 digits. However, these numbers represent maybe 5% of the entire system so it's not critical but it would be nice to find a solution.
Ah! You have an interesting configuration @dcitelecom. The issue becomes more clear. Are most of your DIDs all on the same domain? Your design of numbers has been created with thoughtfulness which greatly reduces the potential of "collisions".
I am thinking of a modified copy of the is_local dialplan that looks at the database for all of the number types you are wanting. I have seen "look at the database" dialplans but have not implemented them.
It would Be a spelunking adventure to understand exactly how the user_exists variable is built and populated so that you could build a dialplan with IF user exists OR time condition exists OR OR OR....
I am thinking of a modified copy of the is_local dialplan that looks at the database for all of the number types you are wanting. I have seen "look at the database" dialplans but have not implemented them.
It would Be a spelunking adventure to understand exactly how the user_exists variable is built and populated so that you could build a dialplan with IF user exists OR time condition exists OR OR OR....