[Asterisk-Users] 'I'nvalid extension handling problems,
even with workaround
Rich Adamson
radamson at routers.com
Tue Jan 4 11:56:13 MST 2005
> > [not-in-service]
> > exten => _.,1,Answer
> > exten => _.,2,Wait(1)
> > exten => _.,3,Playback(the-number-u-dialed)
> > exten => _.,4,Playback(not-yet-assigned)
> > exten => _.,5,Wait(2)
> > exten => _.,6,Hangup
> >
> > The above is "included" as the last of several includes, forcing it to
> > be the last choice if no other matches.
>
> Yes, that would be a problem.
>
> Let's imagine the following:
>
> [internal]
> include => not-in-service
> exten => _2XX,1,Dial(SIP/${EXTEN})
>
> Now, if somebody dials 300, it would go to not-in-service,_.,1 - right?
> But if somebody dialed 200, it would go attempt to Dial(SIP/200). If
> that call fails or when the call is over, it would go to
> not-in-service,_.,2 - since that is a matched next "step" in the
> dialplan.
The actual dialplan looks more like this:
[from-sip]
include => internal
include => long-dist
include => misc-extns
include => not-in-service
The internal & misc def's are extension specific (no matching) while the
long-dist entries are pattern-matched. At least in theory, the only time
we should reach not-in-service is when none of the earlier contexts
match anything (including pattern patching entries).
More information about the asterisk-users
mailing list