[asterisk-dev] CID match uses "shortest prefix match"

[Peter Beckman]

On Thu, 19 Mar 2009, Leif Madsen wrote:

> Leif Madsen wrote:
>> Klaus Darilion wrote:
>>> Thus, as you see, CID matching use a different sorting approach. Bug?
>>
>> I would say this is indeed a bug, and may be suffering from the same
>> issues Jared had mentioned in Asterisk 1.2, but perhaps were not applied
>> to the CID pattern matching stuff when the other pattern matching stuff
>> was fixed (just a guess).
>>
>> I'd say you should open an issue on http://bugs.digium.com so we can
>> track this and get it resolved.
>>
>> I don't see any reason why the pattern matching in the CID matching
>> section should work any differently from the standard pattern matching.
>
> I should also note that this functionality change would only occur in Asterisk
> trunk, and would be first fixed in Asterisk 1.6.3 as this would cause a
> behaviour change in previous Asterisk releases, and would risk breaking existing
> dialplans. (This is of course if whoever decides to resolve the issue doesn't
> make it configurable for some reason, in which case it could potentially be
> backported; but I don't want to volunteer any additional work to whoever may
> choose to fix this. :))
>
> The change would be documented in UPGRADE-1.6.3.txt upon resolution.

  I really think it would be better for everyone using 1.6.x in production
  to make this a configurable flag to use the old, legacy implementation or
  the new, more correct implementation.  Then in 1.6.4 (or somewhere down
  the line) make the new, more correct implementation default, and make a
  new flag for the old way (or just drop the old way).

  [Sort-of related rant about changing functionality, broken, buggy or not,
   between minor releases.  Feel free to break this off into another
   conversation.]

  The biggest problem I perceive people having with Asterisk is upgrading
  breaks things or bugs they fixed or worked around.  This is why I and
  others do not upgrade regularly, because it is awful to try and figure out
  what changed from release to release.  Sure, "Read the Upgrade notes" or
  "Read the changelog" is nice, but that's only things the developers know
  about.  There's no running log about what BROKE in a given release (like
  Call Pickup for example) -- no broken.txt with versions and what broke in
  them.

  Changing broken functionality with no warning other than "Read the Upgrade
  Text" is why people don't upgrade.  At least give them a release or two,
  or like 6 months, before fixing something that many have worked around
  that will fundamentally change functionality.

  I'm certain there are people who have a working dialplan right now, have
  NO IDEA that CID matching is broken and have written their dialplan so it
  works, and if they were to upgrade, their dialplan WILL BREAK and they'll
  have no idea why, nor where to look for why, nor even a clue about WHAT to
  look for.

  Fixing bugs is great, but realize that many of us simply work around the
  bugs that exist in a release, and the next release that fixes bugs we've
  worked around (or didn't realize were bugs, just strange Asterisk
  functionality) breaks everything.  Until Asterisk can be upgraded and
  simply work the same way a previous version did, effectively being
  backwards compatible for some period of time or releases, I think that ANY
  change to Asterisk, bug fix or otherwise, should become a configurable
  item, so that people can upgrade and get new features and bug fixes and
  turn them on where and when they want.

  Here's a thought -- for any 1.x release (or 2.x), the feature set released
  in 1.6 will always remain the same.  Bug fixes will be made, but the
  earlier version, bug fixes and all, will remain for the entire 1.6
  lifetime.  I can upgrade from 1.6.0 to 1.6.16 and unless I change a
  config line "compatibility=1.6.0" to "compatibility=1.6.16", my dialplan
  will continue to work.

  Now, with some coding goodness, we can send warnings to console that we're
  using a broken piece of code that has been deprecated, but our dialplan
  still works.  And with the new, faster release cycle Digium has been
  working on, broken things fixed in 1.6 will be completely fixed in 1.7 and
  not disablable.

  Not only that, but I can install 1.6.16, run it in 1.6.0 mode, and do
  testing of my dialplan with the same install, being able to migrate to
  1.6.16 feature set on my own time, while maintaining security patches,
  etc.

  Maybe that's harebrained, more work than is really necessary.  But I feel
  like Asterisk Releases are like a box of chocolates -- you never know what
  you're gonna get.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------