VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
guido.hecken at gwsnet...
Guest
|
 Posted: Wed Mar 26, 2008 6:30 am Post subject: [asterisk-users] Asterisk parking hold and transferdigittime |
 |
|
| Quote: | -----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 |
|
| Back to top |
|
 |
guido.hecken at gwsnet...
Guest
|
| Posted: Wed Mar 26, 2008 10:27 am Post subject: [asterisk-users] Asterisk parking hold and transferdigittime |
|
|
| Quote: | -----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:
| Quote: | Now, what happens:
Call for 9556230 reaches capi-in, is redirected through
|
include statement to
| Quote: | capi-in-sub and executed.
So far so fine, expected behaviour.
Call for 95562315 reaches capi-in and is executed direct,
|
the include
| Quote: | directive isn't executed at all!
Why?
Through the include statement, asterisk has to look first
|
in capi-in-sub,
| Quote: | there it should
find this extension:
exten => 95562315,1,DoSomethingAnybodyWouldExpect()
...
and follow the dialplan under capi-in-sub since a valid
|
extension was found.
| Quote: |
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 |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
