asterisk/configs/manager.conf.sample

145 lines
5.8 KiB
Plaintext
Raw Normal View History

;
; AMI - The Asterisk Manager Interface
;
; Third party application call management support and PBX event supervision
;
; This configuration file is read every time someone logs in
;
; Use the "manager show commands" at the CLI to list available manager commands
; and their authorization levels.
;
; "manager show command <command>" will show a help text.
;
; ---------------------------- SECURITY NOTE -------------------------------
; Note that you should not enable the AMI on a public IP address. If needed,
; block this TCP port with iptables (or another FW software) and reach it
; with IPsec, SSH, or SSL vpn tunnel. You can also make the manager
; interface available over http/https if Asterisk's http server is enabled in
; http.conf and if both "enabled" and "webenabled" are set to yes in
; this file. Both default to no. httptimeout provides the maximum
; timeout in seconds before a web based session is discarded. The
; default is 60 seconds.
;
[general]
enabled = no
;webenabled = yes
port = 5038
bindaddr = 0.0.0.0
; Parameters that control AMI over TLS. ("enabled" must be set too).
; You can open a connection to this socket with e.g.
;
; openssl s_client -connect my_host:5039
;
;tlsenable=no ; set to YES to enable it
;tlsbindport=5039 ; the port to bind to
;tlsbindaddr=0.0.0.0 ; address to bind to, default to bindaddr
;tlscertfile=/tmp/asterisk.pem ; path to the certificate.
;tlsprivatekey=/tmp/private.pem ; path to the private key, if no private given,
; if no tlsprivatekey is given, default is to search
; tlscertfile for private key.
;tlscipher=<cipher string> ; string specifying which SSL ciphers to use or not use
;
;allowmultiplelogin = yes ; IF set to no, rejects manager logins that are already in use.
; ; The default is yes.
;
;displayconnects = yes
;
; Add a Unix epoch timestamp to events (not action responses)
;
;timestampevents = yes
;brokeneventsaction = yes ; Restore previous behavior that caused the events
; action to not return a response in certain
; circumstances. Defaults to 'no'.
;
; Display certain channel variables every time a channel-oriented
; event is emitted:
;
;channelvars = var1,var2,var3
; debug = on ; enable some debugging info in AMI messages (default off).
; Also accessible through the "manager debug" CLI command.
; authtimeout specifies the maximum number of seconds a client has to
; authenticate. If the client does not authenticate beofre this timeout
; expires, the client will be disconnected. (default: 30 seconds)
;authtimeout = 30
; authlimit specifies the maximum number of unauthenticated sessions that will
; be allowed to connect at any given time.
;authlimit = 50
;httptimeout = 60
; a) httptimeout sets the Max-Age of the http cookie
; b) httptimeout is the amount of time the webserver waits
; on a action=waitevent request (actually its httptimeout-10)
; c) httptimeout is also the amount of time the webserver keeps
; a http session alive after completing a successful action
;[mark]
;secret = mysecret
;deny=0.0.0.0/0.0.0.0
;permit=209.16.236.73/255.255.255.0
;
;eventfilter=Event: Newchannel
;eventfilter=!Channel: DAHDI*
; The eventfilter option is used to whitelist or blacklist events per user to be
; reported with regular expressions and are allowed if both the regex matches
; and the user has read access set below. Filters are assumed to be for whitelisting
; unless preceeded by an exclamation point, which marks it as being black.
; Evaluation of the filters is as follows:
; - If no filters are configured all events are reported as normal.
; - If there are white filters only: implied black all filter processed first,
; then white filters.
; - If there are black filters only: implied white all filter processed first,
; then black filters.
; - If there are both white and black filters: implied black all filter processed
; first, then white filters, and lastly black filters.
;
; If the device connected via this user accepts input slowly,
; the timeout for writes to it can be increased to keep it
; from being disconnected (value is in milliseconds)
;
; writetimeout = 100
;
;displayconnects = yes ; Display on CLI user login/logoff
;
; Authorization for various classes
;
; Read authorization permits you to receive asynchronous events, in general.
; Write authorization permits you to send commands and get back responses. The
; following classes exist:
;
Merge Call completion support into trunk. From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
; all - All event classes below (including any we may have missed).
; system - General information about the system and ability to run system
; management commands, such as Shutdown, Restart, and Reload.
; call - Information about channels and ability to set information in a
; running channel.
; log - Logging information. Read-only. (Defined but not yet used.)
; verbose - Verbose information. Read-only. (Defined but not yet used.)
; agent - Information about queues and agents and ability to add queue
; members to a queue.
; user - Permission to send and receive UserEvent.
; config - Ability to read and write configuration files.
; command - Permission to run CLI commands. Write-only.
; dtmf - Receive DTMF events. Read-only.
; reporting - Ability to get information about the system.
; cdr - Output of cdr_manager, if loaded. Read-only.
; dialplan - Receive NewExten and VarSet events. Read-only.
; originate - Permission to originate new calls. Write-only.
Merge Call completion support into trunk. From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
; agi - Output AGI commands executed. Input AGI command to execute.
; cc - Call Completion events. Read-only.
; aoc - Permission to send Advice Of Charge messages and receive Advice
; - Of Charge events.
;
;read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan
;write = system,call,agent,user,config,command,reporting,originate