2007-11-25 19:33:33 +00:00
..
2007-11-22 00:53:49 +00:00
2007-11-19 19:36:32 +00:00
2007-11-17 14:11:53 +00:00
2007-07-16 02:51:56 +00:00
2007-11-20 23:16:15 +00:00
2007-05-24 22:07:50 +00:00
2007-05-24 22:07:50 +00:00
2007-11-07 00:00:38 +00:00
2007-08-20 22:53:48 +00:00
2007-11-22 03:50:04 +00:00
2007-08-15 19:21:27 +00:00
2007-01-05 23:32:42 +00:00
2007-11-16 20:04:58 +00:00
2007-09-06 20:00:08 +00:00
2007-11-16 21:08:28 +00:00
2006-11-15 20:55:17 +00:00
2007-11-22 02:07:33 +00:00
2007-11-21 01:29:45 +00:00
2007-06-19 17:07:28 +00:00
2006-11-24 14:00:19 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-11-25 19:33:33 +00:00
2007-11-16 20:04:58 +00:00
2007-11-21 16:07:11 +00:00
2006-09-28 13:02:30 +00:00
2007-11-16 20:04:58 +00:00
2007-07-16 02:51:56 +00:00
2007-09-25 21:06:44 +00:00
2007-07-30 20:42:28 +00:00
2006-08-21 02:11:39 +00:00
2007-11-17 14:11:53 +00:00
2007-09-13 15:26:40 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-11-17 03:28:31 +00:00
2007-07-16 02:51:56 +00:00
2007-08-29 15:19:11 +00:00
2007-09-26 06:53:43 +00:00
2007-08-15 21:25:13 +00:00
2007-09-05 16:31:39 +00:00
2007-11-22 00:53:49 +00:00
2007-11-22 00:53:49 +00:00
2007-08-06 19:52:40 +00:00
2007-11-14 03:22:09 +00:00
2007-06-29 20:35:09 +00:00
2007-11-23 09:03:33 +00:00
2007-01-01 20:08:47 +00:00
2007-11-17 06:33:07 +00:00
2007-11-06 18:44:19 +00:00
2007-09-25 09:07:30 +00:00
2007-11-08 05:28:47 +00:00
2007-09-12 21:25:57 +00:00
2007-11-19 19:36:32 +00:00
2007-11-19 14:36:12 +00:00
2007-11-17 14:11:53 +00:00
2007-11-16 20:04:58 +00:00
2007-11-22 00:53:13 +00:00
2007-11-22 03:50:04 +00:00
2007-07-10 15:07:25 +00:00
2007-07-16 02:51:56 +00:00
2007-11-17 14:11:53 +00:00
2007-11-17 23:03:16 +00:00
2007-07-23 14:21:41 +00:00
2007-11-20 23:16:15 +00:00
closes issue #11363; where the pattern _20x. buried in an included context, didn't match 2012; There were a small set of problems to fix: 1. I needed NOT to score patterns unless you are at the end of the data string. 2. Capital N,X,Z and small n,x,z are OK in patterns. I canonicalize the patterns in the trie to caps. 3. When a pattern ends with dot or exclamation, CANMATCH/MATCHMORE should always report this pattern, no matter the length. With this commit, I also supplied the wish of Luigi, where the user can select which pattern matching algorithm to use, the old (legacy) pattern matcher, or the new, trie based matcher. The OLD matcher is the default. A new [general] section variable, extenpatternmatchnew, is added to the extensions.conf, and the example config has it set to false. If true, the new matcher is used. In all other respects, the context/exten structs are the same; the tries and hashtabs are formed, but in the new mode the tries are not used. A new CLI command 'dialplan set extenpatternmatch true/false' is provided to allow switching at run time. I beg users that are forced to return to the old matcher to please report the reason in the bug tracker. Measured the speed benefit of the new matcher against an impossibly large context with 10,000 extensions: the new matcher is 374 times faster.
2007-11-24 21:00:26 +00:00
2007-11-16 20:04:58 +00:00
2007-10-26 17:39:39 +00:00
2007-11-25 17:50:07 +00:00
2007-11-17 14:11:53 +00:00
2007-07-16 02:51:56 +00:00
2007-09-21 14:40:10 +00:00
2007-11-16 20:04:58 +00:00
2007-11-16 20:04:58 +00:00
2006-12-29 06:26:53 +00:00
2007-08-13 21:59:15 +00:00
2007-11-06 02:53:13 +00:00
2007-11-16 21:08:28 +00:00
2007-11-16 21:08:28 +00:00
2007-11-06 19:10:26 +00:00
2006-11-11 02:12:27 +00:00
2007-09-18 16:14:14 +00:00
2007-11-16 20:04:58 +00:00
2007-11-06 22:51:48 +00:00
2007-11-17 14:11:53 +00:00
2007-08-20 22:53:48 +00:00
2007-11-20 23:16:15 +00:00
2007-02-24 20:29:41 +00:00