[asterisk-bugs] [Asterisk 0010834]: [patch]Empty vars in AEL2 switches lead to dropped calls

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10834 
====================================================================== 
Reported By:                adiemus
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   10834
Category:                   PBX/pbx_ael
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:            1.4.10  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-27-2007 17:59 CDT
Last Modified:              10-03-2007 07:54 CDT
====================================================================== 
Summary:                    [patch]Empty vars in AEL2 switches lead to dropped
calls
Description: 
Occasionally my telco doesn't signal CID data properly, leaving me empty
vars for CALLERID(number) and CALLERID(name).  In my dialplan, I have the
following structure:

switch(${CALLERID(number)}) {
    case 1234567890:
       NoOp(Call from 1234567890);
       break;
    default:
       NoOp(No special processing);
}

In the case of a blank CALLERID(number) I'd expect the default path to
run.  However, this AEL gets translated to:

exten => s,16,Goto(sw-12-${CALLERID(number)}|10)
exten => s,17,NoOp(Finish switch-pstn-inbound-12)
exten => _sw-12-.,10,NoOp(No special processing);
exten => _sw-12-.,11,Goto(s|17)
exten => sw-12-1234567890,10,NoOp(Call from 1234567890)
exten => sw-12-1234567890,11,Goto(s|17)

So when asterisk processes it, I end up with:

    -- Executing [s at pstn-inbound:12] Goto("Zap/4-1", "sw-12-|10") in new
stack
    -- Goto (pstn-inbound,sw-12-,10)
[Sep 27 17:58:13] WARNING[32414]: pbx.c:2450 __ast_pbx_run: Channel
'Zap/4-1' sent into invalid extension 'sw-12-' in context 'pstn-inbound',
but no invalid handler
    -- Hungup 'Zap/4-1'

Not quite sure where the "bug" is here since obviously "sw-12-" won't be
matched by "_sw-12-."  Maybe this is the desired behavior and I'm wrong.

For now I'm just checking if CALLERID(number) is empty first, and
populating it with "0000000000" before the switch() which works around the
problem.

  -Chris

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

---------------------------------------------------------------------- 
 murf - 10-03-07 07:54  
---------------------------------------------------------------------- 
You are correct about not being specify an empty case. It'd have to be done
grammatically, like with a new keyword or somesuch; and right now, it's not
worth it. I think you have it correct; it should end up in the default, and
in that case, you can detect and handle it.

If I ever do handle null cases grammatically, I'd just remove the
generation of the null pattern; actually, I'd just modify it slightly. No
sweat.

Whether I use a - or a 1 or whatever, ${EXTEN} will end up being "-" or
"1" or whatever, which would be an unpleasant surprise for those expecting
to see nothing. And for everyone else, everywhere else, they would see the
extra - or 1 or whatever either at the beginning or end of the string they
expected. It would possibly break existing implementations. Not good!

True, not everyone uses ${EXTEN} in switch cases, or even know they can
use it. But if I don't muck with it, I don't have to document it. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-03-07 07:54  murf           Note Added: 0071387                          
======================================================================