281 lines
11 KiB
Plaintext
281 lines
11 KiB
Plaintext
; 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 extenpatternmatchnew is set (true, yes, etc), then a new algorithm that uses
|
|
; a Trie to find the best matching pattern is used. In dialplans
|
|
; with more than about 20-40 extensions in a single context, this
|
|
; new algorithm can provide a noticeable speedup.
|
|
; With 50 extensions, the speedup is 1.32x
|
|
; with 88 extensions, the speedup is 2.23x
|
|
; with 138 extensions, the speedup is 3.44x
|
|
; with 238 extensions, the speedup is 5.8x
|
|
; with 438 extensions, the speedup is 10.4x
|
|
; With 1000 extensions, the speedup is ~25x
|
|
; with 10,000 extensions, the speedup is 374x
|
|
; Basically, the new algorithm provides a flat response
|
|
; time, no matter the number of extensions.
|
|
;
|
|
; By default, the old pattern matcher is used.
|
|
;
|
|
; ****This is a new feature! *********************
|
|
; The new pattern matcher is for the brave, the bold, and
|
|
; the desperate. If you have large dialplans (more than about 50 extensions
|
|
; in a context), and/or high call volume, you might consider setting
|
|
; this value to "yes" !!
|
|
; Please, if you try this out, and are forced to return to the
|
|
; old pattern matcher, please report your reasons in a bug report
|
|
; on https://issues.asterisk.org. We have made good progress in providing
|
|
; something compatible with the old matcher; help us finish the job!
|
|
;
|
|
; This value can be switched at runtime using the cli command "dialplan set extenpatternmatchnew true"
|
|
; or "dialplan set extenpatternmatchnew false", so you can experiment to your hearts content.
|
|
;
|
|
;extenpatternmatchnew=no
|
|
;
|
|
; If clearglobalvars is set, global variables will be cleared
|
|
; and reparsed on a dialplan 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
|
|
;
|
|
; 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"
|
|
;#include <filename.conf>
|
|
;#include filename.conf
|
|
;
|
|
; You can execute a program or script that produces config files, and they
|
|
; will be inserted where you insert the #exec command. The #exec command
|
|
; works on all asterisk configuration files. However, you will need to
|
|
; activate them within asterisk.conf with the "execincludes" option. They
|
|
; are otherwise considered a security risk.
|
|
;#exec /opt/bin/build-extra-contexts.sh
|
|
;#exec /opt/bin/build-extra-contexts.sh --foo="bar"
|
|
;#exec </opt/bin/build-extra-contexts.sh --foo="bar">
|
|
;#exec "/opt/bin/build-extra-contexts.sh --foo=\"bar\""
|
|
;
|
|
|
|
; 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=DAHDI/1
|
|
;CONSOLE=Phone/phone0
|
|
IAXINFO=guest ; IAXtel username/password
|
|
;IAXINFO=myuser:mypass
|
|
TRUNK=DAHDI/G2 ; Trunk interface
|
|
;
|
|
; Note the 'G2' in the TRUNK variable above. It specifies which group (defined
|
|
; in chan_dahdi.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 DAHDI channel
|
|
; (aka. ascending sequential hunt group).
|
|
; G: select the highest-numbered non-busy DAHDI 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
|
|
|
|
;FREENUMDOMAIN=mydomain.com ; domain to send on outbound
|
|
; freenum calls (uses outbound-freenum
|
|
; context)
|
|
|
|
;
|
|
; WARNING WARNING WARNING WARNING
|
|
; If you load any other extension configuration engine, such as pbx_ael.so,
|
|
; your global variables may be overridden by that file. Please take care to
|
|
; use only one location to set global variables, and you will likely save
|
|
; yourself a ton of grief.
|
|
; WARNING WARNING WARNING WARNING
|
|
;
|
|
; 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 parentheses after their name which can be used in goto situations.
|
|
;
|
|
; Contexts contain several lines, one for each step of each extension. 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.
|
|
; Switches may also be included within a context. The order of matching within
|
|
; a context is always exact extensions, pattern match extensions, includes, and
|
|
; switches. Includes are always processed depth-first. So for example, if you
|
|
; would like a switch "A" to match before context "B", simply put switch "A" in
|
|
; an included context "C", where "C" is included in your original context
|
|
; before "B".
|
|
;
|
|
;[context]
|
|
;exten => someexten,{priority|label{+|-}offset}[(alias)],application(arg1,arg2,...)
|
|
;
|
|
; Timing list for includes is
|
|
;
|
|
; <time range>,<days of week>,<days of month>,<months>[,<timezone>]
|
|
;
|
|
; 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. Please note that ignorepat
|
|
; only works with channels which receive dialtone from the PBX, such as DAHDI,
|
|
; Phone, and VPB. Other channels, such as SIP and MGCP, which generate their
|
|
; own dialtone and converse with the PBX only after a number is complete, are
|
|
; generally unaffected by ignorepat (unless DISA or another method is used to
|
|
; generate a dialtone after answering the channel).
|
|
|
|
[openfest]
|
|
; Reception
|
|
exten => 301,hint,SIP/reception
|
|
exten => 301,1,Dial(SIP/reception)
|
|
; Teamroom
|
|
exten => 304,hint,SIP/teamroom
|
|
exten => 304,1,Dial(SIP/teamroom)
|
|
|
|
; Conf rooms
|
|
exten => 1001,1,Dial(SIP/room-a)
|
|
exten => 1001,hint,SIP/room-a
|
|
|
|
exten => 1002,hint,SIP/room-b
|
|
exten => 1002,1,Dial(SIP/room-b)
|
|
|
|
exten => 1003,1,Dial(SIP/room-c)
|
|
exten => 1003,hint,SIP/room-c
|
|
|
|
exten => 1004,1,Dial(SIP/room-d)
|
|
exten => 1004,hint,SIP/room-d
|
|
|
|
; NOC
|
|
exten => 303,1,Dial(SIP/noc1&SIP/noc2)
|
|
exten => 3031,1,Dial(SIP/noc1)
|
|
exten => 3032,1,Dial(SIP/noc2)
|
|
|
|
; users
|
|
exten => 401,1,Dial(SIP/user-401)
|
|
exten => 402,1,Dial(SIP/user-402)
|
|
exten => 403,1,Dial(SIP/user-403)
|
|
exten => 404,1,Dial(SIP/user-404)
|
|
exten => 405,1,Dial(SIP/user-405)
|
|
exten => 406,1,Dial(SIP/user-406)
|
|
exten => 407,1,Dial(SIP/user-407)
|
|
exten => 408,1,Dial(SIP/user-408)
|
|
exten => 409,1,Dial(SIP/user-409)
|
|
exten => 410,1,Dial(SIP/user-410)
|
|
exten => 411,1,Dial(SIP/user-411)
|
|
exten => 412,1,Dial(SIP/user-412)
|
|
exten => 413,1,Dial(SIP/user-413)
|
|
exten => 414,1,Dial(SIP/user-414)
|
|
exten => 415,1,Dial(SIP/user-415)
|
|
exten => 416,1,Dial(SIP/user-416)
|
|
exten => 417,1,Dial(SIP/user-417)
|
|
exten => 418,1,Dial(SIP/user-418)
|
|
exten => 419,1,Dial(SIP/user-419)
|
|
exten => 420,1,Dial(SIP/user-420)
|
|
|
|
exten => 666,1,Answer()
|
|
exten => 666,n,Echo()
|
|
exten => 666,n,hangup()
|
|
|
|
exten => 668,1,Answer()
|
|
exten => 668,n,Playback(vm-intro)
|
|
exten => 668,n,Hangup()
|