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

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
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-03 11:15 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


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

---------------------------------------------------------------------- 
 (0108548) svnbot (reporter) - 2009-08-03 11:15
 https://issues.asterisk.org/view.php?id=14735#c108548 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 210067

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r210067 | dbrooks | 2009-08-03 11:15:35 -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=210067 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-03 11:15 svnbot         Checkin                                      
2009-08-03 11:15 svnbot         Note Added: 0108548                          
2009-08-03 11:15 svnbot         Status                   assigned => resolved
2009-08-03 11:15 svnbot         Resolution               open => fixed       
======================================================================