r1732 : dangerous outgoing dialplan behavior change !!!

[Scapal]

On previous versions, the providers dialplan where included in the phone context. Now they are merged in a per phone '-outgoing' context.

The provider ordering was preserved using includes and is not anymore, this could lead to the wrong provider being used.
This is a major change in the outgoing dialplan.

While the new behavior is not wrong, you better know it changed!

A better printable_dialplan.php should be implemented, reflecting the true outgoing rules ordering, would you decide to keep this new behavior.

[Scapal]

Wouldn't it be better to (somehow) set variables (ie. PROVIDER-UUID-CALLERID) in the Phone context and to check/use them in the common included provider-outbound contexts.?
This way you wouldn't have to care about the dial patterns in a phone-outbound context and would be just like before + setting 1 var per provider.

[Michael]

After reading the documentation for extensions.conf and understanding the way extension matching is prioritized, I don't believe anything was actually changed with this new implementation. As a first approach, I had generated the outgoing patterns in each phone's context but this was prioritized higher than the included contexts, changing behavior. I now generate all of the patterns in a phone specific *-outgoing context thus giving them the same matching weight.

Next week I will post a few before and after examples to solidify this conversation (I'm currently away from the office/lab). Of course, if someone provides examples where behavior changes before this, that would help move this discussion along.

A change in routing behavior after upgrading Askozia is unacceptable...so this will be resolved if there is an issue.

[Scapal]

Let say whe have those three providers:
"1- Provider 1", "2- Provider 2" and "3- Provider 3"

The first is the main provider who gets usually everything with basic rules:
0Z.
OOZ.

My second provider may only be used for dialing Belgian landline numbers:
0032[12356789]XXXXXX

The third one could only be used for mobile Belgian numbers:
00324[5-9]ZXXXXXX


In previous versions, the providers would be included in the phone context, using the 'include =>' dialplan command, ordered by their name,
hence "1- Provider 1", "2- Provider 2" and "3- Provider 3" in that order.
So, under the Askozia 2.0 (and 1.x) behavior, a phone would see all its external calls outgoing to Provider 1.

Now, with r1732, the ordering would go something like below, the Provider 1 never getting a call routed to it.

00324[5-9]ZXXXXXX
0032[12356789]XXXXXX
OOZ.
0Z.

Keeping and 'include' directive for each provider is important so that you can set a preferred provider even if multiple providers are eligible to route a call.
It would be nice to include a 'priority' in the providers, moving them like the members of a 'Call Groups'. For now, I prefix their name with a number to achieve that.

[Michael]

So the change has broken your naming workaround but not changed any intended functionality. I believe all routes are still considered equal in Askozia with the best match winning the race.

I think matching should be based on precision and not priority. Priority should only enter the decision process if the intended provider is unavailable.

Let's say that the intended functionality of Askozia's routing has not been altered by the changes in r1732. I wouldn't call this a dangerous change...

[Scapal]

Maybe the functionality you intended hasn't changed but it wasn't working that way until now, so it has effectively changed.

Even if I forced the order of priority by prefixing the provider names, the effective rule ordering may have changed for a lot of people.
Even with patterns sorted globally, if two provider include the same dial pattern, the order in the extensions.conf will matter.

Putting a priority is imho critical, you may have 2 providers having exactly the same rules but different prices, let's say a SIP provider and ISDN lines, you'd want to use the ISDN lines only as a failover provider and not let the wisdom of randomness decide for you.

Another behavior changed by this new per Phone caller-id system, is that if two providers have exactly the same pattern (among other), only the pattern of the first will indeed be added to the phone-outgoing dialplan, the second being totally ignored.

[Michael]

I think we'll need examples to continue this discussion. I wanted to post them today but did not get around to it with everything else piled up from the weekend.

Believe me, I appreciate the feedback. That's the point of releasing these developer snapshots!

My only point is that I believe you're using a side-effect of the previous behavior to emulate provider failover routing. Provider failover is already present in the provider configuration page and should be used instead of alphabetic ordering tricks.

I could restore the previous behavior but it gets clunky. To maintain that same include behavior would require generating a context for every possible combination of phones and providers. The solution which is implemented so far generates only one extra context per phone. Suggestions for both maintaining exactly the same behavior as in 2.0.x and implementing per phone caller-id are welcome!

Could you also post a snippet regarding the new per phone caller-id bits? That is something that has admittedly not received as much testing as it needs before release. We're currently installing new ISDN lines in the lab for this. They were not there after we recently moved offices and are just getting put in.

[Scapal]

Thank you for your time Michael.

I don't think the previous behavior is the best choice but I think both the old and the new behavior miss something.

Yes, there is a failover option but no way to be sure which one will be the primary.
If the primary and failover have the same patterns since they just are (for example) outgoing providers without any other route specification and that to be a failover provider the patterns must be compatible, how would you configure them to know which one will be the primary provider?
For now, only the lexicographic sort order of the provider name will have an effect on that (hence why I choose to add a priority number as provider name prefix).

A more elegant way would be for you to include that provider priority setting in the GUI, just by ordering them as you already order Calling Group members.

Then, the only remaining question would be, should you separate the providers pattern in the dialplan under 'include' directives or mix them.

Here is the effect of both approach:

Code:

Provider 1:
0Z.
00Z.

Provider 2:
0Z.
0032Z.

Method 1 (pre r1732): keep the strict provider ordering by using 'include' directives
The provider's 2 rules will only be matched against if no rules of provider 1 matches the dialed number.
Effective rules order:

Code:

00Z.   => Provider 1
0Z.    => Provider 1
0032Z. => Provider 2
0Z.    => Provider 2

003228888888 will then use provider 1.
028888888 will also use provider 1.

Method 2 (r1732): inline all the rules in the same (phone-outgoing) context without using includes
The only ordering remaining from the provider name ordering (or explicit priority if implemented) here would be for equal rules.

Effective rules order:

Code:

0032Z. => Provider 2
00Z.   => Provider 1
0Z.    => Provider 1

003228888888 will then use provider 2.
028888888 will use provider 1.


As you see, in both case, the provider ordering has an impact on the effective rules order.

Cheers