Hi Karl,
Ok that makes sence as to the way its attempting to look up the extensions for an
exact_match and when the remote Asterisk server is available the lookup happens
quickly enough that the delay is not noticeable..
The main problem is that when the remote system becomes unavailable the local one
tries so hard to process the "switch" command that it doesn't ever get to the
can_match section of the dial plan which is why I made the comment that I thought the
local dial plan should be completely checked before the remote Asterisk box is
queried.. but in thinking about it this could have its own set of problems..
Is there a way to get asterisk to verify that the remote host is in fact available
before attempting the "switch" so that if it is unavailable the local dialplan will
process as if the "switch" statement wasn't there at all??
Or alternatively cache all the extensions on the remote dialplan on startup and
periodically, Then use the cache to make the routing election as to which way to go
when processing a call.. This would obviously potentially have convergence issues if
dialplans are changed often..
I think verifying the avaiability of the remote system would probably be the most
viable option..
This brings me to another thought..
What if there are two identically configured wildcard extensions on both systems...
eg exten => _90027.,1,Dial(Zap/1/${EXTEN})
Which would have the higher priority? would can_match(local) have a higher priority
than can_match(remote) or would it use the first one it came across?? which could be
the remote one so LCR could get very tricky..
Thanks..
> On Fri, 2003-07-04 at 02:01, WipeOut . wrote:
> > Hi,
> >
> > It seems that the "switch" parameter has a priority in the dialplan
> > that is higher than the wildcard extensions.. This I am finding to be
> > a problem..
> >
>
> switches are actually searched after the local dialplan.
> The problem is that _90027. is a can_match not exact_match so *
> continues to search the switch for an exact match until the digit
> timeout or until you're done dialing at which point it uses the local
> match of _90027..
>
> After dialing take a look at iax2 show cache to see the results of the
> lookups against the switch.
>
> --Karl
>
> > My setup..
> >
> > UA1--[AST1]--{IAX}--[AST2]--UA2
> > | |
> > PSTN1 PSTN2
> >
> > I use switch on AST1 to connect to AST2... As you can see I have PSTN
> > connections on both and also the IAX connection is not permanent..
> >
> > I have wildcard extensions that define which PSTN line to use when
> > dialing out..
> >
> > For example I have the following on AST1 in extensions.conf..
> >
> > [extensions]
> > switch => IAX2/user:[EMAIL PROTECTED]/extensions
> > and my local extensions are in this context..
> >
> > [dialout-uk]
> > exten =>
> > _90044[1-9].,1,Dial(IAX2/user:[EMAIL PROTECTED]/[EMAIL PROTECTED])
> >
> > [dialout-int]
> > exten => _90027.,1,Dial(Zap/1/${EXTEN})
> > and some other country definitions..
> >
> > What is happeneing is that when I break the IAX connection(this way I
> > can see the errors) and I dial 90027315555555 from UA1, AST1 tries to
> > look for extension 9 on AST2 via "switch" and times out then tries
> > extention 90 on AST2 then 900 then 9002 then 90027 etc... you get the
> > idea.. Only once it has tried every number will it move to the _90027.
> > definition and use the PSTN line attached to AST1 as it is supposed
> > to.. This whole sequence takes a while to run through and by then you
> > would have hung up the phone and tried again..
> >
> > I have tried moving things around in the extensions.conf file but it
> > seems that "switch" has a higher priority than local wildcard
> > extension definitions..
> >
> > Surely ALL local definitions (static or wildcard) should take priority
> > over "switch"ing to the remote Asterisk box?? so "switch should be the
> > last thing to try when all else has failed... or am I missing
> > somthing??
> >
> > Later..
> --
> Karl Putland <[EMAIL PROTECTED]>
>
> _______________________________________________
> Asterisk-Users mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-users
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
