[Asterisk-Users] Re: 'I'nvalid extension handling problems, even with workaround

[Rich Adamson]

Inline...

> Humrmrm... 2 days, no answers... :-/

Well, let me see if I can take a stab at this one.

After working with * for about a year now, I'd suggest the toughest
part of the learning curve is truly understanding how to take advantage
of the various 'context' statements to accomplish an objective. Part of
reason for the steep learning curve appears to relate to the lack of
any reasonable form of tracing/debugging what the system is actually
using for a context at each step. (What I mean is that its not intutive
for the beginner.)

It would really be nice if there was a 'debug context' type command
that would simply display each extensions.conf line as it is executed.

> Either I made a stupid question (I don't think so: I have *really* tried to solve
> that on my own before asking the list) or this one's just something nobody has
> ever tried but me (I also find that unlikely: even the telco here plays a message
> when I dial a wrong number; also there's the wiki page I mentioned, which
> indicates that someone in the past has had the same issue).
> <snip>
> >I'm having trouble configuring Asterisk to play an "invalid extension" message to
> >anyone dialing an undefined extension.
> <snip>
> >I then did the "separate context with _." trick the above wiki page suggests; at
> >first it seemed to work: picking up an extension and dialing any invalid
> >extension would play the message (albeit it would play twice, can't understand
> >why) and then hang up.
> <snip>
> >;;;extensions.conf
> >[internal]              ;;; context used by our internal SIP-phon
> >include => voiptalk.org         ;include context below
> >exten => 11,1,Dial(SIP/gsbt100,20,tr);calling : dial our office phone
> >include => invalid_calls        ;all ext numbers not handled above are invalid

The 'separate context' approach _does_ work, but you've just confused
that approach by dropping the Dial statement in the middle. Change this
to something like:
 [internal]
 include => valid-extensions
 include => voiptalk
 include => any-other-context-that-you-need
 include => invalid-calls

The above _sequence_ of include statements is maintained for each call.
In other words, if a call does _not_ match entries in 'valid-extensions',
then it proceeds to the next include. However, if a match is found (including
special cases such as 't', etc) then the call processing may _not_ step
through the remaining includes.

I'm not sure at all about using context names with a period in it, so
just to ensure that isn't causing an issue, stick to context names with
alphanumeric characters. (At least eliminate that uncertainty.)

> >[voiptalk.org]
> >;forwards any calls starting with an "8" thru voiptalk.org
> >exten => _8.,1,Answer
> >exten => _8.,3,SetCIDNum(55555555)
> >exten => _8.,4,SetCIDName(My Name And Surname)
> >exten => _8.,5,Dial(SIP/${EXTEN:1}@voiptalk.org,,g)
> >exten => _8.,6,HangUp
> >[invalid_calls]         ;;; default context for invalid calls
> >exten => _.,1,Wait(1)
> >exten => _.,2,Answer
> >exten => _.,3,Playback(invalid)
> >exten => _.,4,Hangup
> >;;;end of extensions.conf

In the above [invalid_calls] context, change the order to:
 exten => _.,1,Answer
 exten => _.,2,Wait(1)
 exten => _.,3,Playback(invalid)
 exten => _.,4,Hangup

It is rather important from a learning perspective that you create
the [internal] context for use by "internal phones only". Don't try
to use that same context for incoming voiptalk calls, etc. For incoming
external calls, create a separate context something like:
[incoming-voiptalk]
 include => valid-extensions
 include => invalid-calls

After you've made the above changes, "stop" and restart asterisk to
ensure you know exactly what asterisk believes the dialplan is supposed
to be. Stay away from the various 'reload' commands until you understand
exactly what is happening.

Then place test calls and watch the CLI paying close attention to which
contexts are actually in use (or which context a call stops progressing
in). If necessary, increase the debug level to see the needed call progress
info.

Rich