Guido Hecken
2008-Mar-26 11:30 UTC
[asterisk-users] Asterisk parking hold and transferdigittimeo ut
> -----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
Jared Smith
2008-Mar-26 12:01 UTC
[asterisk-users] Asterisk parking hold and transferdigittimeout
On Wed, 2008-03-26 at 12:30 +0100, Guido Hecken wrote:> 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?This is a very popular misconception regarding include statements, so let me try to reiterate how includes work. When a call comes into a particular context, Asterisk looks for the following items: 1) Exact matches in the current context. If a match is found, Asterisk will not continue searching. 2) Pattern matches in the current context. If at least one pattern match is found that matches the dialed extension, Asterisk will not continue searching (even if a better match is included . 3) Any "switch =>" statements. These can be used for remote dialplan lookups, realtime dialplan lookups, DUNDi, etc. If Asterisk finds at least one match, it will not continue searching. 4) Any included contexts. These will be followed in order, and for each included context, this same list will be applied. In your example above, you somehow assumed that the included context would be searched, even though Asterisk already found a match in the current context. -- Jared Smith Community Relations Manager Digium, Inc.
Guido Hecken
2008-Mar-26 15:27 UTC
[asterisk-users] Asterisk parking hold and transferdigittimeo ut
> -----Urspr?ngliche Nachricht----- > Von: Jared Smith [mailto:jsmith at digium.com] > Gesendet: Mittwoch, 26. M?rz 2008 13:01 > An: Asterisk Users Mailing List - Non-Commercial Discussion > Betreff: Re: [asterisk-users] Asterisk parking hold and > transferdigittimeout > > On Wed, 2008-03-26 at 12:30 +0100, Guido Hecken wrote: > > 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? > > This is a very popular misconception regarding include statements, so > let me try to reiterate how includes work. > > When a call comes into a particular context, Asterisk looks for the > following items: > > 1) Exact matches in the current context. If a match is > found, Asterisk > will not continue searching. > 2) Pattern matches in the current context. If at least one pattern > match is found that matches the dialed extension, Asterisk will not > continue searching (even if a better match is included . > 3) Any "switch =>" statements. These can be used for remote dialplan > lookups, realtime dialplan lookups, DUNDi, etc. If Asterisk finds at > least one match, it will not continue searching. > 4) Any included contexts. These will be followed in order, > and for each > included context, this same list will be applied. > > In your example above, you somehow assumed that the included context > would be searched, even though Asterisk already found a match in the > current context.Hi Jared, thanks for your general explanations on using contexts and includes. Since I have your book in my rack, I really should have done some better reading and obviously understanding ;-) Homework done, lesson learned! Regards, Guido 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
Mojo with Horan & Company, LLC
2008-Mar-26 16:19 UTC
[asterisk-users] Asterisk parking hold and transferdigittimeo ut
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
Guido Hecken
2008-Mar-26 17:35 UTC
[asterisk-users] Asterisk parking hold and transferdigittimeo ut
> 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. > > MojHi Moj, thanks for pointing this out. In the meantime I've learned how to use contexts and includes ;-) Jared's post, some hours ago, was very helpful. Regards, Guido 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