; extensions.conf - the Asterisk dial plan
;
; Static extension configuration file, used by
; the pbx_config module. This is where you configure all your
; inbound and outbound calls in Asterisk.
;
; This configuration file is reloaded
; - With the "dialplan reload" command in the CLI
; - With the "reload" command (that reloads everything) in the CLI
;
; The "General" category is for certain variables.
;
[general]
;
; If static is set to no, or omitted, then the pbx_config will rewrite
; this file when extensions are modified.  Remember that all comments
; made in the file will be lost when that happens.
;
; XXX Not yet implemented XXX
;
static=yes
;
; if static=yes and writeprotect=no, you can save dialplan by
; CLI command "dialplan save" too
;
writeprotect=no
;
; If autofallthrough is set, then if an extension runs out of
; things to do, it will terminate the call with BUSY, CONGESTION
; or HANGUP depending on Asterisk's best guess. This is the default.
;
; If autofallthrough is not set, then if an extension runs out of
; things to do, Asterisk will wait for a new extension to be dialed
; (this is the original behavior of Asterisk 1.0 and earlier).
;
;autofallthrough=no
;
; If clearglobalvars is set, global variables will be cleared
; and reparsed on an extensions reload, or Asterisk reload.
;
; If clearglobalvars is not set, then global variables will persist
; through reloads, and even if deleted from the extensions.conf or
; one of its included files, will remain set to the previous value.
;
; NOTE: A complication sets in, if you put your global variables into
; the AEL file, instead of the extensions.conf file. With clearglobalvars
; set, a "reload" will often leave the globals vars cleared, because it
; is not unusual to have extensions.conf (which will have no globals)
; load after the extensions.ael file (where the global vars are stored).
; So, with "reload" in this particular situation, first the AEL file will
; clear and then set all the global vars, then, later, when the extensions.conf
; file is loaded, the global vars are all cleared, and then not set, because
; they are not stored in the extensions.conf file.
;
clearglobalvars=no
;
; If priorityjumping is set to 'yes', then applications that support
; 'jumping' to a different priority based on the result of their operations
; will do so (this is backwards compatible behavior with pre-1.2 releases
; of Asterisk). Individual applications can also be requested to do this
; by passing a 'j' option in their arguments.
;
;priorityjumping=yes
;
; User context is where entries from users.conf are registered.  The
; default value is 'default'
;
;userscontext=default
;
; You can include other config files, use the #include command
; (without the ';'). Note that this is different from the "include" command
; that includes contexts within other contexts. The #include command works
; in all asterisk configuration files.
;#include "filename.conf"
; The "Globals" category contains global variables that can be referenced
; in the dialplan with the GLOBAL dialplan function:
; ${GLOBAL(VARIABLE)}
; ${${GLOBAL(VARIABLE)}} or ${text${GLOBAL(VARIABLE)}} or any hybrid
; Unix/Linux environmental variables can be reached with the ENV dialplan
; function: ${ENV(VARIABLE)}
;
[globals]
CONSOLE=Console/dsp                             ; Console interface for demo
;CONSOLE=Zap/1
;CONSOLE=Phone/phone0
IAXINFO=guest                                   ; IAXtel username/password
;IAXINFO=myuser:mypass
TRUNK=Zap/G2                                    ; Trunk interface
;
; Note the 'G2' in the TRUNK variable above. It specifies which group (defined
; in zapata.conf) to dial, i.e. group 2, and how to choose a channel to use in
; the specified group. The four possible options are:
;
; g: select the lowest-numbered non-busy Zap channel
;    (aka. ascending sequential hunt group).
; G: select the highest-numbered non-busy Zap channel
;    (aka. descending sequential hunt group).
; r: use a round-robin search, starting at the next highest channel than last
;    time (aka. ascending rotary hunt group).
; R: use a round-robin search, starting at the next lowest channel than last
;    time (aka. descending rotary hunt group).
;
TRUNKMSD=1                                      ; MSD digits to strip (usually 1 or 0)
;TRUNK=IAX2/user:pass@provider
;
; Any category other than "General" and "Globals" represent
; extension contexts, which are collections of extensions.
;
; Extension names may be numbers, letters, or combinations
; thereof. If an extension name is prefixed by a '_'
; character, it is interpreted as a pattern rather than a
; literal.  In patterns, some characters have special meanings:
;
;   X - any digit from 0-9
;   Z - any digit from 1-9
;   N - any digit from 2-9
;   [1235-9] - any digit in the brackets (in this example, 1,2,3,5,6,7,8,9)
;   . - wildcard, matches anything remaining (e.g. _9011. matches
;       anything starting with 9011 excluding 9011 itself)
;   ! - wildcard, causes the matching process to complete as soon as
;       it can unambiguously determine that no other matches are possible
;
; For example the extension _NXXXXXX would match normal 7 digit dialings,
; while _1NXXNXXXXXX would represent an area code plus phone number
; preceded by a one.
;
; Each step of an extension is ordered by priority, which must
; always start with 1 to be considered a valid extension.  The priority
; "next" or "n" means the previous priority plus one, regardless of whether
; the previous priority was associated with the current extension or not.
; The priority "same" or "s" means the same as the previously specified
; priority, again regardless of whether the previous entry was for the
; same extension.  Priorities may be immediately followed by a plus sign
; and another integer to add that amount (most useful with 's' or 'n').
; Priorities may then also have an alias, or label, in
; parenthesis after their name which can be used in goto situations
;
; Contexts contain several lines, one for each step of each
; extension, which can take one of two forms as listed below,
; with the first form being preferred.
;
;[context]
;exten => someexten,{priority|label{+|-}offset}[(alias)],application(arg1,arg2,...)
;exten => someexten,{priority|label{+|-}offset}[(alias)],application,arg1|arg2...
;
; Included Contexts
;
; One may include another context in the current one as well, optionally with a
; date and time.  Included contexts are included in the order
; they are listed.
; The reason a context would include other contexts is for their
; extensions.
; The algorithm to find an extension is recursive, and works in this
; fashion:
;        first, given a stack on which to store context references,
;           push the context to find the extension onto the stack...
;    a) Try to find a matching extension in the context at the top of
;       the stack, and, if found, begin executing the priorities
;       there in sequence.
;    b) If not found, Search the switches, if any declared, in
;       sequence.
;    c) If still not found, for each include, push that context onto
;       the top of the context stack, and recurse to a).
;    d) If still not found, pop the entry from the top of the stack;
;       if the stack is empty, the search has failed. If it's not,
;       continue with the next context in c).
; This is a depth-first traversal, and stops with the first context
; that provides a matching extension. As usual, if more than one
; pattern in a context will match, the 'best' match will win.
; Please note that that extensions found in an included context are
; treated as if they were in the context from which the search began.
; The PBX's notion of the "current context" is not changed.
; Please note that in a context, it does not matter where an include
; directive occurs. Whether at the top, or near the bottom, the effect
; will be the same. The only thing that matters is that if there is
; more than one include directive, they will be searched for extensions
; in order, first to last.
; Also please note that pattern matches (like _9XX) are not treated
; any differently than exact matches (like 987). Also note that the
; order of extensions in a context have no affect on the outcome.
;
; Timing list for includes is
;
;   <time range>|<days of week>|<days of month>|<months>
;
; Note that ranges may be specified to wrap around the ends.  Also, minutes are
; fine-grained only down to the closest even minute.
;
;include => daytime|9:00-17:00|mon-fri|*|*
;include => weekend|*|sat-sun|*|*
;include => weeknights|17:02-8:58|mon-fri|*|*
;
; ignorepat can be used to instruct drivers to not cancel dialtone upon
; receipt of a particular pattern.  The most commonly used example is
; of course '9' like this:
;
;ignorepat => 9
;
; so that dialtone remains even after dialing a 9.
;
;
; Sample entries for extensions.conf
;
;
[dundi-e164-canonical]
;
; List canonical entries here
;
;exten => 12564286000,1,Macro(stdexten,6000,IAX2/foo)
;exten => _125642860XX,1,Dial(IAX2/otherbox/${EXTEN:7})
[dundi-e164-customers]
;
; If you are an ITSP or Reseller, list your customers here.
;
;exten => _12564286000,1,Dial(SIP/customer1)
;exten => _12564286001,1,Dial(IAX2/customer2)
[dundi-e164-via-pstn]
;
; If you are freely delivering calls to the PSTN, list them here
;
;exten => _1256428XXXX,1,Dial(Zap/G2/${EXTEN:7}) ; Expose all of 256-428
;exten => _1256325XXXX,1,Dial(Zap/G2/${EXTEN:7}) ; Ditto for 256-325
[demo1]
exten => _4XXX,1,Dial(SIP/4xxx/${EXTEN},60)
exten => _4XXX,n,Hangup
exten => _2XXX,1,Dial(SIP/${EXTEN},60)
exten => _2XXX,n,Hangup
exten => 2000,1,Answer()
exten => 2000,n,Playback(demo-thanks)
exten => 2000,n,Hangup
exten => _1XXX,1,Dial(SIP/1xxx/${EXTEN},60)
exten => _1XXX,n,Hangup
exten => _9XX,1,Dial(ZAP/G1/${EXTEN},60)
exten => _9XX,n,Hangup
LiLaLo (L3) расшифровывается как Live Lab Log.
Программа разработана для повышения эффективности обучения Unix/Linux-системам.
(c) Игорь Чубин, 2004-2008
Журнал лабораторных работ

Журнал

Суббота (11/28/09)

Воскресенье (11/29/09)

Пятница (12/04/09)

Файлы

Статистика

Справка

О программе
