[Asterisk-Users] switch => priority in the dialplan.. (probably an issue for Mark)

[WipeOut .]

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:password at AST2/extensions
> > and my local extensions are in this context..
> > 
> > [dialout-uk]
> > exten =>
> > _90044[1-9].,1,Dial(IAX2/user:password at AST2/${EXTEN}@dialout-uk)
> > 
> > [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 <karl at putland.linux-site.net>
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> 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