asterisk users - Sep 2004 - 'Hangup' not hanging-up, is this intended behaviour?

Greetings folks;

I have a bit of a conundrum, and I can't tell if Asterisk is doing
something daft, or whether I'm clean missing out why it's doing what
it's
doing. So, I have a dialplan that looks a little like this:

--------------------
[start]
include => dids
include => everythingelse

[dids]
; Test
exten => 8378,1,SetCallerID(3015551212)
exten => 8378,2,Hangup

[everythingelse]
exten => _.,1,AGI,MyScript|${EXTEN} ${ACCOUNTCODE}
--------------------

The 'Hangup' on 8378 doesn't hang up. Instead it falls through to
'everythingelse' context, and the AGI is executed in the hangup
priority.

    -- Executing SetCallerID("SIP/3015551212-5acc",
"3015551212") in new stack
    -- Executing Hangup("SIP/3015551212-5acc", "") in new
stack
  == Spawn extension (start, 8378, 2) exited non-zero on
'SIP/3015551212-5acc'
    -- Executing AGI("SIP/3015551212-5acc", "MyScript|h
3015551212") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/MyScript
    -- AGI Script MyScript completed, returning 0

If I dial something else (MyScript processes outbound toll/intl calls),
the same as the above happens - the script is again run immediately after
it ends, in the hangup priority. The script is exiting with 0 as a return
code on completion.

When I ask it to Hangup, I expect it to Hangup. I'm guessing that the
_. catch-all is also catching priorities as well as all extensions, which
may or may not be a "feature" of Asterisk. How do I stop this from
happening?


Thanks all for your help;
JP

> Hello all,
>
> I updated from CVS a few days ago and noticed that my calls just cut
> out without reason.
> The CLI says this:   -- Hungup 'Zap/3-1'
>
> It occurs without error or warning.
>
> Is their a bug in CVS asterisk or libpri? This never occurred before.
We upgraded to 1.0 RC2 on Tuesday and the exact thing happened to
us. Apparently there's a bug somewhere in there
(Asterisk/libpri/zaptel/libzap) that causes an outgoing CLID/ANI to have a
1 prefixed to it. Annoying.
Assuming we're having the same thing happening...

We chatted with the Digium telephone monkeys and they told us it was a bug
that the developers would have to deal with - and that we should back out
the upgrade.
Instead we talked to the telco dude at our colocation facility and he had
the telco switch that our primary rate goes through DROP the first digit
of CLID/ANIs (Don't ask me how), et voila, we were back in business.

Why everyone isn't complaining about it, I'm not sure, perhaps some
switches deal with it differently. Heck if I know. Either way, that was
our fix.

On Wed, 8 Sep 2004, JP Hindin wrote:
> I have a bit of a conundrum, and I can't tell if Asterisk is doing
> something daft, or whether I'm clean missing out why it's doing
what it's
> doing. So, I have a dialplan that looks a little like this:
> --------------------
> [start]
> include => dids
> include => everythingelse
> 
> [dids]
> ; Test
> exten => 8378,1,SetCallerID(3015551212)
> exten => 8378,2,Hangup
> 
> [everythingelse]
> exten => _.,1,AGI,MyScript|${EXTEN} ${ACCOUNTCODE}
> --------------------
So I figure I'd answer my own question.
The obvious hit me. Been "working" on this on and off for a couple
weeks
now, and the day after I post, I work it out.

_. matches all extensions. t and h (so on) are extensions. Therefore,
_. matches those extensions as well. Whether this is a "Feature"
I'm not
sure.

The obvious solution to stop Hangups falling through to _. is this:
exten => _X.,1,AGI,MyScript|${EXTEN} ${ACCOUNTCODE}

And, finally, the problem is solved. Like. Duh.

JP