Understanding destinations

[TurabG]

Hi all,

Today I have started using FusionPBX today on production with 4 trunks and 15 extensions, with several IVRs, Call Centers and as such. In general, everything is working fine except some, for which I would like to understand what is the function of destinations. Actually I didn't quite understand it from the docs which is very brief.

I created an inbound destination with one of my trunks. Then (as it suggested), it created inbound routes accordingly and inbound calls were routed correctly. BUT;

1- Inbound route can not be created without a destination. But I can create more inbound routes by copying one of them and then delete inbound destination; everything still works. So what's the point in the destination and what is the point in tying it to the inbound route?

2- Inbound destination conditions are written to the inbound route XML line by line; which actually breaks the conditioning. Like for example I expect two outbound caller ids to be redirected to an extension rather than being transferred to an IVR. When I put two "Caller ID" conditions to the inbound destination, it creates an inbound route with two lines of caller id regex check and it doesn't work. I delete one of the lines from XML, I change the regex of the other line to include two of the caller ids with an or identifier like: "^11111|22222$", this way it works. If the outbound caller id is 11111 or 22222, it is transferred to the extension I wanted. But this of course isn't reflected to the inbound destination. So again, what exactly is destinations if we already have inbound routes?

3- In call detail records, I see some of the caller destinations as variables like: "{caller_destination}". Is this the normal behavior or it is just because I don't have a destination tied to this inbound rule?

 

[DigitalDaz]

Destinations create the inbound route for you. Where do you see in the documentation that it says to do both?

 

[DigitalDaz]

With regards to why destinations, the reason is security. You can give access to destinations to a domain admin but giving access to inbound routes creates problems, they could potentially break the server.

 

[TurabG]

With regards to why destinations, the reason is security. You can give access to destinations to a domain admin but giving access to inbound routes creates problems, they could potentially break the server.

But changing the destination changes the inbound route too? I understand that inbound rules are more advanced to be given the access; but what about my points 2 and 3 while working only on destinations doesn't work as expected?

 

[TurabG]

Destinations create the inbound route for you. Where do you see in the documentation that it says to do both?

I didn't claim that it did. I am just trying to understand. So you say destinations is just a tool to set inbound rules in a simpler way as a UI?

 

[DigitalDaz]

I didn't claim that it did. I am just trying to understand. So you say destinations is just a tool to set inbound rules in a simpler way as a UI?

"I created an inbound destination with one of my trunks. Then (as it suggested), it created inbound routes accordingly"

Yes, destinations is a tool to create inbound routes.

 

[DigitalDaz]

I was mistaken, I thought you said, 'I' created inbound routes, didn't read properly.

 

[TurabG]

Yes, destinations is a tool to create inbound routes.

Then there is no problem having zero destinations if we have the inbound routes set correctly, right?

And you have any idea about the third article? Seeing the destination number as a variable in the CDR?

 

[DigitalDaz]

No idea about the variable, but almost no one uses inbound routes, we just use destinations. Without them, you will probably find dropdowns are not populated correctly in other modules.

 

[TurabG]

That's actually what I am trying to understand, thank you for bearing with me. But as I said, having multiple conditions in destination doesn't actually work, so I have to manually edit the inbound route.

 

[DigitalDaz]

So do that, create the destination, then edit the inbound route, that's probably the best.

That said, what multiple conditions do you need? That would normall be dealth with in a custom place that you send the destination to.

 

[TurabG]

That said, what multiple conditions do you need?

There are some certain callers which I don't want to be transferred to the standard IVR, but instead, it must be transferred to a specific extension. For that, while creating the destination, I add multiple conditions like:


This creates two different regex lines for the two caller ids, in the inbound rule; which doesn't work I don't know why. (I guess when it's two different lines, it expects to pass both regex and it works like "AND" rather than "OR"? If that's the case, then this is a bug which will cause it to definitely fail.) So I go to the inbound rules, delete one caller id regex line completely, then edit the other line to add them together in one single regex, only then it works.

Also, the "Caller ID Number" input on this screenshot also doesn't have any effect. I fill it in, save the destination; but it doesn't put it anywhere in the inbound rule.

 

[DigitalDaz]

The caller id name and caller id number are there for a certain purpose.

There is a permission in the group manager, caller id select or something, I would have to loo it up.....

Once set, when the extensions page is visited and you got to edit an extension, the freeform text input fields for caller id and number become select boxes and are populated with the values from above.

With regards to what you are doing above, to keep my inbound routes/destinations clean is to send the destination to a custom dialplan entry and then do that logic in that custom dialplan.

 

[DigitalDaz]

I have nver tried what you are trying above bur have you tried in the condition, instead of two lines, in the one field 11111|22222

ie using the bar, or operator

 

[DigitalDaz]

I have just realised I do very similar to allow pinless entry to a conference on my box in the dialpan, maybe I will try it in the destination and see if it works:

 

[TurabG]

I have just realised I do very similar to allow pinless entry to a conference on my box in the dialpan, maybe I will try it in the destination and see if it works:

View attachment 3365

Yes, it definitely works in the destination, I am using it right now. But as I said, destination UI doesn't work that way, I have to manually edit inbound route to make it as exactly in the screenshot you posted.

Now I am pretty sure that the UI makes it two lines and it works as logical "AND" which expects to match both lines at the same time, which is in fact impossible. So this means you should NEVER use the same conditioning in the destination setup screen; meaning you must use for example "Caller ID Number" only once.

 

[DigitalDaz]

I have just checked and the bar | gets removed when you put multiple in.

I'm sure @markjcrane would some day fix that to maybe allow an array [11111,22222] for example and then include that as a single condition as an or method.

 

[TurabG]

I have just checked and the bar | gets removed when you put multiple in.

You sure? Here is mine and it works as expected:

But of course the line is "caller_id_number" check and not "{$sip_from_user}" if that makes the difference.

 

[DigitalDaz]

No, I mean in the destination it removes the bar

 

[markjcrane]

Sorry it does need some updates. I plan to make it work for multiple caller ID in one destination in the future.