Peers in Unreachable / Lagged / Reachable status "Loop" - Followup

Asterisk Asterisk Dialplan
1

Hi There community,

I’m opening a followup of an closed topic that you can find here:

After researching about this behavior, I found that maybe Asterisk started to “Tilt” since i have more than 700 extensions on a context, I’m not sure how asterisk reads extensions.conf file but i know that its a sequential order with priorities.

If i have 700+ exten possibilities in the same prioritiy and number length with the old dialplan algorithm receiving a lot of traffic, Maybe there is the issue.

I would like to know if someone could explain to me how Asterisk reads the dialplan extensions in “backend” like:

Asterisk reads every extension in the same priority and match the best (Old Algorithm) per call
Asterisk reads every extension per triad in the same priority and match the best (New algorithm) per call
Asterisk reads every comment with semi-colon “;” ?

Any advice or ideas will be greatly appreciated
Kind Regards

2

That’s really a developer level question, and I’m not convinced that there are many people who have delved into pbx.c.

However, the easy bit is that comments are stripped very early, and everything is done on parsed fields without any comments.

Other than that, you really are going to have to spend a day or two with asterisk/pbx.c at master · asterisk/asterisk · GitHub to get the answer.

3

I think the old algorithm is to sort the distinct extension patterns in descending order of specificity, and within each pattern, have a hash index on priority (and on label). Then when you do a lookup, you lookup the context to get a pointer to the list of extensions, then try each extension pattern combination in turn until it both matches, and the required priority or label exists for it. (The priority search may have originally been a linear search, within each pattern.)

I think the new does a digit by digit search through an auxiliary tree to find matching patterns without examining all of them.

Remember that the matching system has to cope with priority 666 being a specific match, whereas all the others are pattern matches.
I haven’t verified that all the steps of the above happen.

4

Dear @david551

Thanks a lot for your commentaries, sadly i don’t really understand the Github code,

About the commented lines on the dialplan and the new algorithm, thank you so much for your “It makes sense for me”, you confirmed my thoughts

About the issue that i was experiencing, the dialplan was too long and working with the old algorithm even with “good” exten REGEX-es, after changing to the new algorithm the system could support all the incoming traffic.

So, in summary for who reads this:
Long dialplans and too many traffic through it could cause the system to “collapse” in SIP terms, meaning that:
Peers will disconnect and you will receive and reply SIP methods with delay.

Kind Regards community

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.