2002-09-02 15:20:28 +00:00
|
|
|
;
|
2005-03-17 15:56:55 +00:00
|
|
|
; AMI - The Asterisk Manager Interface
|
2009-05-28 14:39:21 +00:00
|
|
|
;
|
2005-10-04 22:51:59 +00:00
|
|
|
; Third party application call management support and PBX event supervision
|
2005-03-17 15:56:55 +00:00
|
|
|
;
|
2006-11-04 01:20:38 +00:00
|
|
|
; Use the "manager show commands" at the CLI to list available manager commands
|
2005-10-04 22:51:59 +00:00
|
|
|
; and their authorization levels.
|
2005-03-17 15:56:55 +00:00
|
|
|
;
|
2006-10-04 16:48:07 +00:00
|
|
|
; "manager show command <command>" will show a help text.
|
2005-03-17 15:56:55 +00:00
|
|
|
;
|
2005-10-04 22:51:59 +00:00
|
|
|
; ---------------------------- 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
|
2009-05-28 14:39:21 +00:00
|
|
|
; with IPsec, SSH, or SSL vpn tunnel. You can also make the manager
|
2006-11-04 01:20:38 +00:00
|
|
|
; interface available over http/https if Asterisk's http server is enabled in
|
2006-04-01 08:49:54 +00:00
|
|
|
; http.conf and if both "enabled" and "webenabled" are set to yes in
|
2009-05-28 14:39:21 +00:00
|
|
|
; this file. Both default to no. httptimeout provides the maximum
|
|
|
|
; timeout in seconds before a web based session is discarded. The
|
2006-04-01 08:49:54 +00:00
|
|
|
; default is 60 seconds.
|
2002-09-02 15:20:28 +00:00
|
|
|
;
|
|
|
|
[general]
|
|
|
|
enabled = no
|
2006-04-01 08:49:54 +00:00
|
|
|
;webenabled = yes
|
2007-05-04 20:11:03 +00:00
|
|
|
|
2010-08-26 12:26:46 +00:00
|
|
|
port = 5038
|
2002-09-02 15:20:28 +00:00
|
|
|
bindaddr = 0.0.0.0
|
2006-12-07 16:42:29 +00:00
|
|
|
|
|
|
|
; 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
|
|
|
|
;
|
2009-04-29 14:39:48 +00:00
|
|
|
;tlsenable=no ; set to YES to enable it
|
2012-02-02 18:55:05 +00:00
|
|
|
;tlsbindaddr=0.0.0.0:5039 ; address and port to bind to, default to bindaddr and port 5039
|
2009-04-29 14:39:48 +00:00
|
|
|
;tlscertfile=/tmp/asterisk.pem ; path to the certificate.
|
|
|
|
;tlsprivatekey=/tmp/private.pem ; path to the private key, if no private given,
|
2009-05-28 14:39:21 +00:00
|
|
|
; if no tlsprivatekey is given, default is to search
|
|
|
|
; tlscertfile for private key.
|
2009-04-29 14:39:48 +00:00
|
|
|
;tlscipher=<cipher string> ; string specifying which SSL ciphers to use or not use
|
2007-05-17 17:12:23 +00:00
|
|
|
;
|
|
|
|
;allowmultiplelogin = yes ; IF set to no, rejects manager logins that are already in use.
|
|
|
|
; ; The default is yes.
|
|
|
|
;
|
2005-01-05 06:24:59 +00:00
|
|
|
;displayconnects = yes
|
2006-01-03 22:07:12 +00:00
|
|
|
;
|
|
|
|
; Add a Unix epoch timestamp to events (not action responses)
|
|
|
|
;
|
|
|
|
;timestampevents = yes
|
2002-09-02 15:20:28 +00:00
|
|
|
|
2010-04-13 18:10:30 +00:00
|
|
|
;brokeneventsaction = yes ; Restore previous behavior that caused the events
|
|
|
|
; action to not return a response in certain
|
|
|
|
; circumstances. Defaults to 'no'.
|
|
|
|
|
2009-11-13 20:42:03 +00:00
|
|
|
;
|
|
|
|
; Display certain channel variables every time a channel-oriented
|
|
|
|
; event is emitted:
|
|
|
|
;
|
2018-11-07 13:18:34 -04:00
|
|
|
; Note that this does incur a performance penalty and should be avoided if possible.
|
|
|
|
;
|
2009-11-13 20:42:03 +00:00
|
|
|
;channelvars = var1,var2,var3
|
|
|
|
|
2006-11-04 01:20:38 +00:00
|
|
|
; debug = on ; enable some debugging info in AMI messages (default off).
|
2009-05-28 14:39:21 +00:00
|
|
|
; Also accessible through the "manager debug" CLI command.
|
2010-08-26 12:26:46 +00:00
|
|
|
|
2011-04-05 14:16:21 +00:00
|
|
|
; 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
|
|
|
|
|
2010-08-26 12:26:46 +00:00
|
|
|
;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
|
2022-01-09 13:32:48 +00:00
|
|
|
;
|
|
|
|
; disabledevents specifies AMI events which should be completely globally disabled.
|
|
|
|
; These events will not be available to any AMI listeners. Use this to disable
|
|
|
|
; frequent events which are not desired for any listeners. Default
|
|
|
|
; is no events are globally disabled. Event names are case-sensitive.
|
|
|
|
; Events disabled in stasis.conf do not also need to be disabled here.
|
|
|
|
; If you don't want to completely disable an AMI event, also consider the
|
|
|
|
; filter option available on a per-manager user basis to block unwanted
|
|
|
|
; events from being received in a stream (as opposed to this option which
|
|
|
|
; would prevent specified events from being generated at all).
|
2010-08-26 12:26:46 +00:00
|
|
|
|
2022-01-09 13:32:48 +00:00
|
|
|
;disabledevents = Newexten,Varset
|
2010-08-26 12:26:46 +00:00
|
|
|
|
2002-09-02 15:20:28 +00:00
|
|
|
;[mark]
|
|
|
|
;secret = mysecret
|
2003-05-05 06:14:25 +00:00
|
|
|
;deny=0.0.0.0/0.0.0.0
|
|
|
|
;permit=209.16.236.73/255.255.255.0
|
2012-07-11 18:33:36 +00:00
|
|
|
;acl=named_acl_example ; use a named ACL from acl.conf
|
2010-06-22 16:29:18 +00:00
|
|
|
;
|
2017-12-22 09:23:22 -05:00
|
|
|
;
|
2012-07-31 21:21:57 +00:00
|
|
|
;setvar=PBXACCOUNT=edvina
|
|
|
|
; The setvar option defines channel variables that will be set when this account
|
|
|
|
; originates a call. You can define multiple setvar= commands for one manager
|
|
|
|
; user.
|
|
|
|
;
|
2024-07-31 16:05:45 -06:00
|
|
|
|
|
|
|
;--
|
|
|
|
-- eventfilter --------------------------------------------------------
|
|
|
|
Include and/or exclude events for this user.
|
|
|
|
|
|
|
|
There are two ways to use this feature... Legacy and Advanced.
|
|
|
|
|
|
|
|
Legacy Event Filtering:
|
|
|
|
|
|
|
|
This is the original method of filtering events. It's no longer
|
|
|
|
recommended but still supported for backwards compatibility. The filter
|
|
|
|
is a regular expression, optionally prefixed with an exclamation point (!).
|
|
|
|
The regular expression is applied to the entire payload of every event.
|
|
|
|
If any part of the event payload matches, the event is included. If the
|
|
|
|
first character of the filter is an exclamation point (!), the event is
|
|
|
|
excluded. On a busy system, this is a resource intensive process and the
|
|
|
|
reason it's no longer recommended.
|
|
|
|
|
|
|
|
Another issue with legacy filtering is that regexes are very sensitive to
|
|
|
|
whitespace and separators. "Event:Newchannel" will NOT work because of
|
|
|
|
the missing space after the ':'. Neither will "Event: Newchannel" or
|
|
|
|
"Event Newchannel" because of the extra space in the first expression
|
|
|
|
and the missing ':' in the second.
|
|
|
|
|
|
|
|
Advanced Event Filtering:
|
|
|
|
|
|
|
|
Advanced filtering still allows you to use regular expressions but adds
|
|
|
|
the ability to pre-select certain events and constrain the regular
|
|
|
|
expression to matching the contents of a specific event header.
|
|
|
|
The syntax is:
|
|
|
|
|
|
|
|
eventfilter(<match_criteria>) = [ <match_expression> ]
|
|
|
|
|
|
|
|
<match_criteria> : [ action(include|exclude) | name(<event_name>) |
|
|
|
|
header(<header_name>) | method(<match_method>) ][, ...]
|
|
|
|
|
|
|
|
You can specify at most one of each of the following in any order,
|
|
|
|
separated by commas.
|
|
|
|
|
|
|
|
action(include|exclude): Default: 'include'. Instead of using '!' to
|
|
|
|
exclude matching events, specify 'action(exclude)'. Although the
|
|
|
|
default is "include" if "action" isn't specified, adding
|
|
|
|
"action(include)" will help with readability.
|
|
|
|
|
|
|
|
name(<event_name>): Include only events with a name exactly matching
|
|
|
|
<event_name>. This is actually implemented using the "hash" of the
|
|
|
|
event names and is therefore much more efficient than using a regular
|
|
|
|
expression.
|
|
|
|
|
|
|
|
header(<header_name>): Include only events that have a header exactly
|
|
|
|
matching <header_name>. Additionally, the data to be searched will
|
|
|
|
be constrained to the value of this header instead of the entire
|
|
|
|
event payload.
|
|
|
|
|
|
|
|
method(regex | exact | starts_with | ends_with | contains | none ):
|
|
|
|
How should <match_expression> be applied to the event data? The data may
|
|
|
|
be the entire event payload or, if header(<header_name>) was used, the
|
|
|
|
value of that specific header. If 'action(exclude)' was specified, a
|
|
|
|
"match" here will cause the event to be excluded instead of included.
|
|
|
|
|
|
|
|
regex: As a regular expression that, if matched anywhere in the
|
|
|
|
data, constitutes a match.
|
|
|
|
|
|
|
|
exact: As a simple string that must match all of the data.
|
|
|
|
Probably only useful when the data is constrained to a specific header
|
|
|
|
and the data itself is a simple value.
|
|
|
|
|
|
|
|
starts_with: As a simple string that, if found at the beginning of the
|
|
|
|
data, constitutes a match.
|
|
|
|
|
|
|
|
ends_with: As a simple string that, if found at the end of the data,
|
|
|
|
constitutes a match.
|
|
|
|
|
|
|
|
contains: As a simple string that, if found anywhere in the data,
|
|
|
|
constitutes a match.
|
|
|
|
|
|
|
|
none: Ignore <match_expression> altogether. This is the default
|
|
|
|
because the majority of use cases for event filtering involve
|
|
|
|
including or excluding events by event name without regard to the
|
|
|
|
event payload. In this case, you can just leave <match_expression>
|
|
|
|
empty.
|
|
|
|
|
|
|
|
TIP: Although match criteria order doesn't matter to Asterisk, using the
|
|
|
|
order shown can help you read them. For instance...
|
|
|
|
eventfilter(action(exclude),name(Newchannel),header(Channel),method(starts_with)) = Local/
|
|
|
|
...means "Exclude Newchannel events with a Channel header that starts with Local/"
|
|
|
|
|
|
|
|
Event Filter Processing Ordering:
|
|
|
|
|
|
|
|
Both Legacy and Advanced filter entries are processed as follows:
|
|
|
|
- If no filters are configured, all events are reported as normal.
|
|
|
|
|
|
|
|
- If there are 'include' filters only, an event that matches ANY filter
|
|
|
|
will be reported.
|
|
|
|
|
|
|
|
- If there are 'exclude' filters only, an event that matched ANY filter
|
|
|
|
will be excluded.
|
|
|
|
|
|
|
|
- If there are both 'include' and 'exclude' filters, all 'include' filters
|
|
|
|
are matched first, then the 'exclude' filters will be applied to the
|
|
|
|
resulting set.
|
|
|
|
--;
|
|
|
|
|
|
|
|
; ----- Legacy Filter Examples:
|
|
|
|
; Every legacy filter expression results in regular expression matching
|
|
|
|
; on the entire payload of every event even if no regular expression
|
|
|
|
; meta-characters were used.
|
|
|
|
|
|
|
|
; Only include Newchannel events
|
2010-06-22 16:29:18 +00:00
|
|
|
;eventfilter=Event: Newchannel
|
2024-07-31 16:05:45 -06:00
|
|
|
|
|
|
|
; Only include events of any type with a "Channel" header that matches
|
|
|
|
; the regular expression.
|
2014-01-27 08:17:22 +00:00
|
|
|
;eventfilter=Channel: (PJ)?SIP/(james|jim|john)-
|
2024-07-31 16:05:45 -06:00
|
|
|
|
|
|
|
; Only include Newchannel events which contain a "Channel" header
|
|
|
|
; for PJSIP channels.
|
|
|
|
;eventfilter = Event: Newchannel.*Channel: PJSIP/
|
|
|
|
|
|
|
|
; Only include Newchannel or Hangup events whose "Channel" header doesn't start
|
|
|
|
; with Local/. All other events are filtered out.
|
|
|
|
;eventfilter = Event: Newchannel
|
|
|
|
;eventfilter = Event: Hangup
|
|
|
|
;eventfilter = !Channel: Local/
|
|
|
|
; This causes three regexes to be searched for on every event!
|
|
|
|
|
|
|
|
; Include ALL events EXCEPT Newchannel and Hangup events whose "Channel" header
|
|
|
|
; starts with Local/.
|
|
|
|
; Other Newchannel and Hangup events ARE reported.
|
|
|
|
;eventfilter = !Event: (Newchannel|Hangup).*Channel: Local/
|
|
|
|
; This causes one regex to be searched for but it's a fairly expensive
|
|
|
|
; one.
|
|
|
|
|
|
|
|
; Exclude any event that has a "Channel" header whose value starts with "DADHI/"
|
2014-01-27 08:17:22 +00:00
|
|
|
;eventfilter=!Channel: DAHDI/
|
2024-07-31 16:05:45 -06:00
|
|
|
|
|
|
|
; ----- Advanced Filter Examples:
|
|
|
|
; All of these examples are WAY more efficient than their legacy
|
|
|
|
; equivalents.
|
|
|
|
|
|
|
|
; Include only "Newchannel" events.
|
|
|
|
; eventfilter(name(Newchannel)) =
|
|
|
|
; Note that there's nothing to the right of the '=' because you don't care
|
|
|
|
; what's in the payload. You still need the '=' though or the config file
|
|
|
|
; parser will complain. 'action(include)' and 'method(none)' are implied.
|
|
|
|
|
|
|
|
; Only include events of any type with a "Channel" header that matches
|
|
|
|
; the regular expression.
|
|
|
|
;eventfilter(action(include),header(Channel),method(regex)) = (PJ)?SIP/(james|jim|john)-
|
|
|
|
; We're still testing every event but because we only apply the regex to the
|
|
|
|
; value of the Channel header this is still more efficient than using the
|
|
|
|
; legacy method.
|
|
|
|
|
|
|
|
; Only include Newchannel and Hangup events whose "Channel" header doesn't
|
|
|
|
; start with Local/.
|
|
|
|
;eventfilter(action(include),name(Newchannel)) =
|
|
|
|
;eventfilter(action(include),name(Hangup)) =
|
|
|
|
;eventfilter(header(Channel),action(exclude),method(starts_with)) = Local/
|
|
|
|
; No regexes at all. We do the hash match against the event names first and
|
2024-09-24 11:11:07 -06:00
|
|
|
; only matching events are passed to the next filter.
|
2024-07-31 16:05:45 -06:00
|
|
|
; Then, in only those events, we look for a Channel header by exact match, then
|
|
|
|
; look for 'Local/' at the beginning of its value.
|
|
|
|
|
|
|
|
; Include ALL events EXCEPT Newchannel and Hangup events whose "Channel" header
|
|
|
|
; starts with Local/.
|
|
|
|
; Other Newchannel and Hangup events ARE reported.
|
|
|
|
;eventfilter(action(exclude),name(Newchannel),header(Channel),method(starts_with)) = Local/
|
|
|
|
;eventfilter(action(exclude),name(Hangup),header(Channel),method(starts_with)) = Local/
|
|
|
|
; Again, no regexes. Very efficient because the filters start by looking for
|
|
|
|
; a hash match on the event name.
|
|
|
|
|
|
|
|
; Exclude any event that has a "Channel" header whose value starts with "DADHI/"
|
|
|
|
;eventfilter(action(exclude),header(Channel),method(starts_with)) = DAHDI/
|
|
|
|
; We're still testing every event but there are no regexes involved at all.
|
|
|
|
|
|
|
|
;--
|
|
|
|
-- eventfilter end ----------------------------------------------------
|
|
|
|
--;
|
2010-06-22 16:29:18 +00:00
|
|
|
|
2005-03-17 15:56:55 +00:00
|
|
|
;
|
2005-10-04 22:25:15 +00:00
|
|
|
; 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
|
|
|
|
;
|
2007-06-11 22:07:50 +00:00
|
|
|
;displayconnects = yes ; Display on CLI user login/logoff
|
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; Authorization for various classes
|
2008-01-10 00:12:35 +00:00
|
|
|
;
|
|
|
|
; 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).
|
2008-01-10 00:12:35 +00:00
|
|
|
; system - General information about the system and ability to run system
|
2016-08-15 12:17:51 +00:00
|
|
|
; management commands, such as Shutdown, Restart, and Reload. This
|
|
|
|
; class also includes dialplan manipulation actions such as
|
|
|
|
; DialplanExtensionAdd and DialplanExtensionRemove.
|
2008-01-10 00:12:35 +00:00
|
|
|
; call - Information about channels and ability to set information in a
|
|
|
|
; running channel.
|
2010-10-12 16:08:53 +00:00
|
|
|
; log - Logging information. Read-only. (Defined but not yet used.)
|
|
|
|
; verbose - Verbose information. Read-only. (Defined but not yet used.)
|
2008-01-10 00:12:35 +00:00
|
|
|
; 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.
|
2008-04-07 22:16:46 +00:00
|
|
|
; 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.
|
Generic Advice of Charge.
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-02 18:10:15 +00:00
|
|
|
; aoc - Permission to send Advice Of Charge messages and receive Advice
|
|
|
|
; - Of Charge events.
|
2011-08-22 19:19:44 +00:00
|
|
|
; test - Ability to read TestEvent notifications sent to the Asterisk Test
|
|
|
|
; Suite. Note that this is only enabled when the TEST_FRAMEWORK
|
|
|
|
; compiler flag is defined.
|
2013-11-08 19:33:48 +00:00
|
|
|
; security - Security Events. Read-only.
|
2012-06-04 20:26:12 +00:00
|
|
|
; message - Permissions to send out of call messages. Write-only
|
2008-01-10 00:12:35 +00:00
|
|
|
;
|
|
|
|
;read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan
|
2012-06-04 20:26:12 +00:00
|
|
|
;write = system,call,agent,user,config,command,reporting,originate,message
|