[asterisk-users] Asterisk parking hold and transferdigittimeo ut

[Mojo with Horan & Company, LLC]

Guido Hecken wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Mojo with Horan & Company, LLC [mailto:mojo at horanappraisals.com] 
>> Gesendet: Dienstag, 25. März 2008 23:23
>> An: Asterisk Users Mailing List - Non-Commercial Discussion
>> Betreff: Re: [asterisk-users] Asterisk parking hold and 
>> transferdigittimeout
>>
>> It seems that the dialplan comes into play.  If your parking 
>> lot is 700, 
>> and you have any extension patterns that COULD begin with that, then 
>> asterisk will wait to make SURE you're not typing 700xxxx:
>>
>> Let's say that 700 is my parking lot extension.
>>
>> exten => _NXXNXXXXXX,1,blahblahblah
>>
>> This could match 7005551212, so asterisk waits around to make 
>> sure I'm 
>> not trying to find any more buttons before it accepts that I 
>> meant 700.  
>> As an example, if your parking lot extension was **, then 
>> asterisk could 
>> be pretty darn sure that that won't match anything else, and 
>> will accept 
>> it directly as a number to transfer too. 
>>     
>
> SOLUTION ###########################
>
> Thanks for the tip, it was really the dialplan. In our * installations we
> have an 
> outgoing context, named capi-out starting with this:
>
> [capi-out]
> exten => _XXX.,1,DoSomethingReallyImpressive()
> ...
>
> After I changed it to:
>
> [capi-out]
> include => notfall ; special context for 3-digit emergency numbers
> exten => _XXXX.,1,DoSomethingReallyImpressive()
> ...
>
> [notfall]
> exten => _11X,1,Dial(CAPI/ISDN3/${EXTEN}/b,60,tT)
> ...
>
> BTW these includes are really magic, cause sometimes they don't do what you 
> (especially I) expext.
> Please take a look at this:
>
> EXAMPLE ###########################
>
> ;DIALPLAN
> ...
>
> [capi-in]
> include => capi-in-sub
> exten => _955623XX,1,DoSomethingReallyImpressive()
> ...
>
> [capi-in-sub]
> exten => 9556230,1,DoSomethingReallyImpressive()
> exten => 95562315,1,DoSomethingAnybodyWouldExpect()
> ...
>
> Now, what happens:
>
> Call for 9556230 reaches capi-in, is redirected through include statement to
> capi-in-sub and executed.
> So far so fine, expected behaviour.
>
> Call for 95562315 reaches capi-in and is executed direct, the include
> directive isn't executed at all!
> Why?
> Through the include statement, asterisk has to look first in capi-in-sub,
> there it should
> find this extension:
> exten => 95562315,1,DoSomethingAnybodyWouldExpect()
> ...
>
> and follow the dialplan under capi-in-sub since a valid extension was found.
>
> What's wrong, any ideas?
>
>
> Regards,
>
> Guido Hecken
>  
> gwsNetTech
> Guido Hecken
>
> Quirrenbacher Str. 36
> 53639 Königswinter
> Germany
>
> fon     +49(2244) 870663
> fax     +49(2244) 870664
> mobil  +49(179) 1267353
> web     http://www.gwsnettech.de
> mailto:guido.hecken at gwsnettech.de
>  
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>   
According to this post:
http://lists.digium.com/pipermail/asterisk-dev/2007-April/027281.html
"Includes are tacked on to the end of the dialplan they are mentioned 
in, not where they stand."

So, since your "exten => _955623XX,1,DoSomethingReallyImpressive()" 
matches, asterisk doesn't need to even bother checking the included context.

Moj