[Home]

Summary:ASTERISK-11721: The new pattern matching does not work
Reporter:Private Name (falves11)Labels:
Date Opened:2008-03-26 00:48:35Date Closed:2008-04-16 14:01:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_config
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12298.patch1
( 1) dialplan_error_1.txt
( 2) dialplan_new.txt
( 3) dialplan_reload.txt
( 4) extensions.conf
Description:I have a lot of extensions, several thousands, and therefore I decided to use the new patter-matching. It does not work at all. I send a call to my cell at 19544447408, and it gets rejected with "not found". Please see the dialplan and the SIP trace.

****** ADDITIONAL INFORMATION ******

if I use the old patter-matching, it works.
Comments:By: Private Name (falves11) 2008-03-26 08:34:22

Dear Developers
If you look at the file dialplan_new.txt, you can see a perfect example of a dialplan that works perfectly on the old pattern-matching and does not work at all on the new. Since I am trying to store all my least-cost routing table in the dialplan, it is critical that the best algrithm be used, sinde that would mean the difference between 5 calls per second or 20. I am talking about thousand of entries in the dialplan. Please help me understand what I am doing wrong. There is a problem becuse if I test the dialplan from the console typing "show dialplan 19544447408@inbound", it shows a match, yet when a SIP call comes in, it says "not found".
By: Steve Murphy (murf) 2008-03-28 12:14:35

falves11-- hang in there... I'm looking at this now. Thanks for the example data. It'll help.
By: Steve Murphy (murf) 2008-03-28 12:21:20

Oh, falves11, if you are in trunk, try updating;

yesterday, I added a fix for the handling of '.' in patterns that might affect this. You might make sure you have the latest stuff. That will be a quick way to verifiy if this problem is fixed or not. Meanwhile, I'll begin playing with your data.
By: Private Name (falves11) 2008-03-28 12:57:39

I am usuing the bang (!) now instead of the "." but the issue remains.
By: Steve Murphy (murf) 2008-03-28 13:08:40

you **are** using a trunk version updated to today, right?
By: Private Name (falves11) 2008-03-28 13:12:40

that is correct. I am Trunk person.
By: Steve Murphy (murf) 2008-04-01 11:37:27

falves--
I have re-engineered the new pattern matcher to better handle the '.' wildcards, cleared up a few bugs, made sure it considered all possible patterns, etc. Then I upgraded the matching code to use pretty much the same exact scoring algorithm that the old(current) matcher did, and added code to 'sort' the pattern trie, and then modified the find_exten to quit after the first (now first=best) match. It seems to work, I have more testing to do, but if you want to test in your environment, I've got the patch attached to this bug (see above). If you can try it out, add a note to this bug of problems/success/failure.  The new pattern matcher should now almost exactly match the behavior of the old one, except it runs a lot faster on big dialplans, of course.
By: Digium Subversion (svnbot) 2008-04-01 14:57:41

Repository: asterisk
Revision: 112289

U   trunk/main/pbx.c

------------------------------------------------------------------------
r112289 | murf | 2008-04-01 14:57:37 -0500 (Tue, 01 Apr 2008) | 21 lines

(closes issue ASTERISK-11721)
Reported by: falves11
Patches:
     12298.patch1 uploaded by murf (license 17)
Tested by: murf

I have hopes that the changes made over the last few days will
finalize and solidify this code. While there are bound to be
small tweaks still needed, I feel that the job (at last) is
somewhat completed. Finally, I had a chance to comprehend how
the scoring of extension patterns was done in the previous
version, and I've come very close to using the exact same
criteria in the new pattern matching code. The left-right
sorting is now replicated in the trie structure itself, such
that the first match found will the 'best' match. Compared
the results against 1.4 for several extensions. Replicated
falves11's setup and it works. Used some devious patterns
provided by jsmith, supplemented with a few of my own.
Looks good.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=112289
By: Digium Subversion (svnbot) 2008-04-01 15:16:11

Repository: asterisk
Revision: 112299

_U  branches/1.6.0/
U   branches/1.6.0/main/pbx.c

------------------------------------------------------------------------
r112299 | murf | 2008-04-01 15:16:08 -0500 (Tue, 01 Apr 2008) | 29 lines

Merged revisions 112289 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r112289 | murf | 2008-04-01 14:02:19 -0600 (Tue, 01 Apr 2008) | 21 lines

(closes issue ASTERISK-11721)
Reported by: falves11
Patches:
     12298.patch1 uploaded by murf (license 17)
Tested by: murf

I have hopes that the changes made over the last few days will
finalize and solidify this code. While there are bound to be
small tweaks still needed, I feel that the job (at last) is
somewhat completed. Finally, I had a chance to comprehend how
the scoring of extension patterns was done in the previous
version, and I've come very close to using the exact same
criteria in the new pattern matching code. The left-right
sorting is now replicated in the trie structure itself, such
that the first match found will the 'best' match. Compared
the results against 1.4 for several extensions. Replicated
falves11's setup and it works. Used some devious patterns
provided by jsmith, supplemented with a few of my own.
Looks good.


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=112299
By: Private Name (falves11) 2008-04-14 00:23:20

The patch does not work at all. I have a working diaplan that works fine under the old technology and fails to work under the new one. My dialplan is short but not trivial. Please contact Ryan Brindley at Digium. He has the login information for my test box, from a support case. All you have to do is send a call with and the without the extenpatternmatchnew =no. You will see immediately the problem.
Federico Alves
By: Steve Murphy (murf) 2008-04-14 13:44:13

I haven't reached rbrindley yet today, but if this is the same machine he had me look at a few days back, the asterisk there is at v. 114098, but my corrections are in 12298; so if my info is wrong, please double-check the version of asterisk you are running (core show version), and if the version number is below 12298, then do the "svn update" thing, and redo the make and make install thing to update. Let me know if this the problem or not...
By: Private Name (falves11) 2008-04-14 16:12:30

I a downloading SVN Trunk and I get SVN-trunk-r114127.
What is happenning??
By: Private Name (falves11) 2008-04-15 08:30:09

The developer is confused with the numbering and I am afraid his changes never made it to the system. As we all know, the current SVN Trunk version 114127 as of 9:30 AM 4-15-08.  
But Murf writes:
"..if this is the same machine he had me look at a few days back, the asterisk there is at v. 114098, but my corrections are in 12298; so if my info is wrong, please double-check the version of asterisk you are running (core show version), and if the version number is below 12298, then do the "svn update" thing, and redo the make and make install thing to update. Let me know if this the problem or not..."

Murf is confused. The number 12298 is the BUG ID, not the version number. Version number is still in the 114K's, not 122K. I downloaded the latest version and the patch does not work.

I think that, "ceteris paribus", the new pattern-matching technology must work identical to the old one, except for offering constant speed or better performance, otherwise it would break existing dial-plans. This is exactly what is happenning now.
By: Steve Murphy (murf) 2008-04-15 09:33:52

My apologies-- You are right-- I misinterpreted my notes here.

I agree that the behavior of the new matching code should match the behavior of the 'old'. That is my goal. I first have to understand why we are not getting the same results. I thought I had the same stuff as you, found the problem, and fixed it, but it looks like I don't have a grip on reality.

In the meantime, I've found another bug in the pattern matcher, and in the late hours last night, and in the early hours this morning, I managed to track it down and make a fix. It has to do with a gap in the logic between MATCH and SPAWN, and could easily be what's biting you. I will (in a few hours) commit it to trunk and update this bug. So hang on-- and thanks for taking the time to help perfect this code!
By: Steve Murphy (murf) 2008-04-15 15:11:36

OK, I've tested and committed the fix I previously mentioned to trunk & 1.6.0;
if you could give it a spin (version should be 114146 or greater for trunk),
I would much appreciate it, to see if it solves the problem with your dialplan.

many thanks!
By: Private Name (falves11) 2008-04-16 13:34:34

Congratulations, now it works fine. I cannot evaluate the speed, though, but I trust is faster.
By: Joshua C. Colp (jcolp) 2008-04-16 14:01:55

Closed as it has been fixed.