[Asterisk-Users] Dial Plan Sequencing

Stephen R. Besch sbesch at acsu.buffalo.edu
Wed Nov 12 10:06:03 MST 2003


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




More information about the asterisk-users mailing list