[Home]

Summary:ASTERISK-12616: Local channel does not support exten/callerid style dialplan entries (ast_exists_extension placement).
Reporter:Eric Futch (efutch)Labels:
Date Opened:2008-08-19 15:25:51Date Closed:2008-10-06 11:41:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080915__bug13343.diff.txt
Description:local_alloc in chan_local.c calls ast_exists_extension before any CallerID information for the local channel is populated.  Therefore, it cannot pass the CallerID number to ast_exists_extensions like other channel techs do.  So calls will not match the exten/callerid style dialplan entries like these:
7002001234/_212NXXNXXXXX,1,Noop(Call from 212 area.)

Either the CallerID information should be populated before ast_exists_extension in local_alloc is called, or the call to ast_exists_extension to be placed somewhere after the CallerID information is established in local_call.

This problem also seems to exist in 1.6, after quickly checking chan_local.c
Comments:By: Leif Madsen (lmadsen) 2008-08-27 12:11:57

Can you provide a method to reproduce this? I'm guessing you're doing something like the following...

[testing]
exten => 100,1,NoOp()
exten => 100,n,Set(CALLERID(num)=2125551212)
exten => 100,n,Dial(Local/7002001234@callerid_check)
exten => 100,n,Hangup()

[callerid_check]
exten => 7002001234/_212NXXXXXX,1,NoOp(Call from 212)

exten => 7002001234,1,NoOp(General incoming call)


Something like that? (I haven't done any testing, I just made this dialplan up now.)
By: Eric Futch (efutch) 2008-08-27 12:20:20

Something like that, yes.
By: Eric Futch (efutch) 2008-08-27 12:29:50

More importantly, if you remove the fall through case "exten => 7002001234,1,NoOp(General incoming call)" as you have it... the Dial will fail because it doesn't match the "exten => 7002001234/_212NXXXXXX,1,NoOp(Call from 212)" line properly.
By: Tilghman Lesher (tilghman) 2008-09-15 17:01:28

The only logical thing I can think of to do would be to remove the optimization completely where we check that the extension exists, since we won't know what the callerid will be until later on in the call process.

Would this change solve your issue?
By: Eric Futch (efutch) 2008-09-16 10:34:01

This patch looks good to me.  The only problem with it is that tmp->context and tmp->exten need to be p->chan->context and p->chan->exten for ast_exists_extension in the first chunk.  You got them right on the following line though (ast_log).  Once I changed that it compiled and tested ok.
By: Leif Madsen (lmadsen) 2008-10-06 10:10:15

Corydon76: seems the patch works for the original poster based on his latest note.
By: Digium Subversion (svnbot) 2008-10-06 11:41:14

Repository: asterisk
Revision: 146711

U   branches/1.4/channels/chan_local.c

------------------------------------------------------------------------
r146711 | tilghman | 2008-10-06 11:41:14 -0500 (Mon, 06 Oct 2008) | 9 lines

Check whether an extension exists in the _call method, rather than the _alloc
method, because we need to evaluate the callerid (since that data affects
whether an extension exists).
(closes issue ASTERISK-12616)
Reported by: efutch
Patches:
      20080915__bug13343.diff.txt uploaded by Corydon76 (license 14)
Tested by: efutch

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

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