[asterisk-bugs] [Asterisk 0014735]: Detection of call pickup code in chan_dahdi should have higher priority than dialplan matches

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14735 
====================================================================== 
Reported By:                stevedavies
Assigned To:                dbrooks
====================================================================== 
Project:                    Asterisk
Issue ID:                   14735
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-24 06:39 CDT
Last Modified:              2009-08-04 13:59 CDT
====================================================================== 
Summary:                    Detection of call pickup code in chan_dahdi should
have higher priority than dialplan matches
Description: 
Hi,

Just spent some time investigating why a customer couldn't do *8 from
their analogue phones.  This on a freepbx system.

In the end it turned out that the customer had a dialplan rule that
matched "_*." and played a "your call cannot be completed as dialled"
message.  This is in freepbx's "bad-number" context which is included at
the lowest level in the from-internal context.

When I looked at the logic in chan_dahdi (and chan_zapata) I was surprised
to find that it actually "prefers" a dialplan match over matching the
ast_pickup_ext or *69 or the rest.

My opinion is that it would be much more sensible to prefer the
feature-code match where the dialplan also had a match.  Especially where
the dialplan match is a pattern match.

My logic is that the feature code is like an "exact" exten line.  And the
concept that "exact matches" have priority over patterns is well
established in Asterisk.

I also point out that chan_sip in fact does prefer the pickup code over
any dialplan match.  So at the moment chan_dahdi and chan_sip are
inconsistent.

Regards,
Steve


====================================================================== 

---------------------------------------------------------------------- 
 (0108608) svnbot (reporter) - 2009-08-04 13:59
 https://issues.asterisk.org/view.php?id=14735#c108608 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 210436

_U  trunk/

------------------------------------------------------------------------
r210436 | dbrooks | 2009-08-04 13:59:52 -0500 (Tue, 04 Aug 2009) | 17
lines

Blocked revisions 210067 via svnmerge

........
  r210067 | dbrooks | 2009-08-03 11:15:20 -0500 (Mon, 03 Aug 2009) | 11
lines
  
  Fixes dialplan wildcard extension taking precedence over call pickup
code.
  
  Prior to this patch, a wildcard extension in the dialplan (for example,
_*.) would take
  precedence over picking up a call in the channel's pickup group. This
patch simply moves
  the block of code handling pickup group matching to above the extension
matching code.
  
  (closes issue https://issues.asterisk.org/view.php?id=14735)
  Reported by: stevedavies
  
  Review: https://reviewboard.asterisk.org/r/319/
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=210436 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-04 13:59 svnbot         Checkin                                      
2009-08-04 13:59 svnbot         Note Added: 0108608                          
======================================================================