I have an interesting dilemma with sequencing in the dialplan. Up to now, I have assumed that the extensions in the dial plan were tested in the order that they appear in extensions.conf. In other words, I have the following fragment which was designed to dial toll free on the PSTN and all other long distance on VoIP:

[longdistance]
include => local ;Handle local, etc first. (or so I thought!)
exten => _91NXXNXXXXXX,1,Dial(${VPLSTRUNK}/${EXTEN:1}) ;Dial long distance through VoiP
exten => _91NXXNXXXXXX,2,Congestion ;OOPS! No lines available?
:
:


[local]
:
exten => _91800NXXXXXX,1,Dial(${PSTNTRUNK}/${EXTEN}) ; Long distance toll free accessed through PSTN trunk interface
exten => _91800NXXXXXX,2,Congestion
exten => _91888NXXXXXX,1,Dial(${PSTNTRUNK}/${EXTEN})
exten => _91888NXXXXXX,2,Congestion
exten => _91877NXXXXXX,1,Dial(${PSTNTRUNK}/${EXTEN})
exten => _91877NXXXXXX,2,Congestion
exten => _91866NXXXXXX,1,Dial(${PSTNTRUNK}/${EXTEN})
exten => _91866NXXXXXX,2,Congestion


; The rest of the local definitions, etc
:

I expected that the "_918" definitions would be tested first, followed by the "_91N" definitions. Unfortunately, it appears as if the definitions made using the "include=" operator are always tested last. This means that the toll free numbers dialed by people in the longdistance context are always routed over VoIP rather than PSTN because they match the "_91N" pattern. While I can fix this with a complicated set of conditionals or dial string patterns, I wonder if anyone has found a more elegant solution, remembering that I want to give some extensions access to only the local context, but still provide toll free service for everyone (i.e, I don't want to move the "_918" definitions into the longdistance context).

Stephen R. Besch

_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to