2004-10-05 06:46:11 +00:00
|
|
|
;
|
|
|
|
|
; Static and realtime external configuration
|
|
|
|
|
; engine configuration
|
|
|
|
|
;
|
2023-11-09 21:26:46 +00:00
|
|
|
; See https://docs.asterisk.org/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration/
|
2011-02-02 18:59:29 +00:00
|
|
|
; for basic table formatting information.
|
2004-10-08 05:36:23 +00:00
|
|
|
;
|
2004-06-11 00:12:35 +00:00
|
|
|
[settings]
|
2004-10-05 06:46:11 +00:00
|
|
|
;
|
2009-05-28 14:39:21 +00:00
|
|
|
; Static configuration files:
|
2004-10-05 06:46:11 +00:00
|
|
|
;
|
2010-07-23 16:19:21 +00:00
|
|
|
; file.conf => driver,database[,table[,priority]]
|
2004-10-05 06:46:11 +00:00
|
|
|
;
|
|
|
|
|
; maps a particular configuration file to the given
|
|
|
|
|
; database driver, database and table (or uses the
|
|
|
|
|
; name of the file as the table if not specified)
|
|
|
|
|
;
|
app_queue: Add RealTime support for queue rules
This patch gives the optional ability to keep queue rules in RealTime. It is
important to note that with this patch:
(a) Queue rules in RealTime are only examined on module load/reload
(b) Queue rules are loaded both from the queuerules.conf file as well as the
RealTime backend
To inform app_queue to examine RealTime for queue rules, a new setting has been
added to queuerules.conf's general section "realtime_rules". RealTime queue
rules will only be used when this setting is set to "yes".
The schema for the database table supports a rule_name, time, min_penalty, and
max_penalty columns. min_penalty and max_penalty can be relative, if a '-' or
'+' literal is provided. Otherwise, the penalties are treated as constants.
For example:
rule_name, time, min_penalty, max_penalty
'default', '10', '20', '30'
'test2', '20', '30', '55'
'test2', '25', '-11', '+1111'
'test2', '400', '112', '333'
'test3', '0', '4564', '46546'
'test_rule', '40', '15', '50'
which would result in :
Rule: default
- After 10 seconds, adjust QUEUE_MAX_PENALTY to 30 and adjust
QUEUE_MIN_PENALTY to 20
Rule: test2
- After 20 seconds, adjust QUEUE_MAX_PENALTY to 55 and adjust
QUEUE_MIN_PENALTY to 30
- After 25 seconds, adjust QUEUE_MAX_PENALTY by 1111 and adjust
QUEUE_MIN_PENALTY by -11
- After 400 seconds, adjust QUEUE_MAX_PENALTY to 333 and adjust
QUEUE_MIN_PENALTY to 112
Rule: test3
- After 0 seconds, adjust QUEUE_MAX_PENALTY to 46546 and adjust
QUEUE_MIN_PENALTY to 4564
Rule: test_rule
- After 40 seconds, adjust QUEUE_MAX_PENALTY to 50 and adjust
QUEUE_MIN_PENALTY to 15
If you use RealTime, the queue rules will be always reloaded on a module
reload, even if the underlying file did not change. With the option disabled,
the rules will only be reloaded if the file was modified.
Review: https://reviewboard.asterisk.org/r/3607/
ASTERISK-23823 #close
Reported by: Michael K
patches:
app_queue.c_realtime_trunk.patch uploaded by Michael K (License 6621)
........
Merged revisions 420624 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-11 00:14:53 +00:00
|
|
|
; Uncomment to load queues.conf via the odbc engine.
|
2004-10-05 06:46:11 +00:00
|
|
|
;
|
|
|
|
|
;queues.conf => odbc,asterisk,ast_config
|
2007-03-13 21:22:33 +00:00
|
|
|
;extensions.conf => sqlite,asterisk,ast_config
|
2005-07-05 22:11:43 +00:00
|
|
|
;
|
|
|
|
|
; The following files CANNOT be loaded from Realtime storage:
|
|
|
|
|
; asterisk.conf
|
|
|
|
|
; extconfig.conf (this file)
|
|
|
|
|
; logger.conf
|
|
|
|
|
;
|
|
|
|
|
; Additionally, the following files cannot be loaded from
|
|
|
|
|
; Realtime storage unless the storage driver is loaded
|
|
|
|
|
; early using 'preload' statements in modules.conf:
|
|
|
|
|
; manager.conf
|
|
|
|
|
; cdr.conf
|
|
|
|
|
; rtp.conf
|
|
|
|
|
;
|
2012-07-11 18:33:36 +00:00
|
|
|
; Named ACLs specified in realtime also can not be used
|
|
|
|
|
; from manager.conf unless the storage driver is preloaded.
|
|
|
|
|
; Attempting to use a realtime stored named ACL before the
|
|
|
|
|
; driver is loaded will result in an invalid ACL which
|
|
|
|
|
; rejects all addresses.
|
2004-10-05 06:46:11 +00:00
|
|
|
;
|
|
|
|
|
; Realtime configuration engine
|
|
|
|
|
;
|
|
|
|
|
; maps a particular family of realtime
|
|
|
|
|
; configuration to a given database driver,
|
|
|
|
|
; database and table (or uses the name of
|
|
|
|
|
; the family if the table is not specified
|
|
|
|
|
;
|
2010-07-23 16:19:21 +00:00
|
|
|
;example => odbc,asterisk,alttable,1
|
|
|
|
|
;example => mysql,asterisk,alttable,2
|
2005-12-27 06:42:29 +00:00
|
|
|
;example2 => ldap,"dc=oxymium,dc=net",example2
|
|
|
|
|
;
|
2010-07-23 16:19:21 +00:00
|
|
|
; Additionally, priorities are now supported for use as failover methods
|
|
|
|
|
; for retrieving realtime data. If one connection fails to retrieve any
|
|
|
|
|
; information, the next sequential priority will be tried next. This
|
|
|
|
|
; especially works well with ODBC connections, since res_odbc now caches
|
|
|
|
|
; when connection failures occur and prevents immediately retrying those
|
|
|
|
|
; connections until after a specified timeout. Note: priorities must
|
|
|
|
|
; start at 1 and be sequential (i.e. if you have only priorities 1, 2,
|
|
|
|
|
; and 4, then 4 will be ignored, because there is no 3).
|
|
|
|
|
;
|
2013-04-08 23:38:08 +00:00
|
|
|
;
|
|
|
|
|
; Possible driver backends:
|
|
|
|
|
;
|
2007-03-13 21:22:33 +00:00
|
|
|
; "odbc" is shown in the examples below, but is not the only valid realtime
|
2013-04-08 23:38:08 +00:00
|
|
|
; engine. Here are several of the possible options:
|
2007-03-13 21:22:33 +00:00
|
|
|
; odbc ... res_config_odbc
|
2013-10-04 18:13:37 +00:00
|
|
|
; sqlite3 ... res_config_sqlite3
|
2007-03-13 21:22:33 +00:00
|
|
|
; pgsql ... res_config_pgsql
|
2010-07-23 16:19:21 +00:00
|
|
|
; curl ... res_config_curl
|
|
|
|
|
; ldap ... res_config_ldap
|
2013-04-08 23:38:08 +00:00
|
|
|
; mysql ... res_config_mysql (available via add-ons in menuselect)
|
2007-03-13 21:22:33 +00:00
|
|
|
;
|
2022-02-24 19:33:05 +00:00
|
|
|
; Note: The res_config_pgsql backend configures the database used in their
|
|
|
|
|
; respective configuration files and ignore the database name configured in
|
|
|
|
|
; this file.
|
2012-02-13 17:25:41 +00:00
|
|
|
;
|
2005-02-10 21:14:11 +00:00
|
|
|
;iaxusers => odbc,asterisk
|
|
|
|
|
;iaxpeers => odbc,asterisk
|
|
|
|
|
;sippeers => odbc,asterisk
|
2011-11-01 21:02:56 +00:00
|
|
|
;sipregs => odbc,asterisk ; (avoid sipregs if possible, e.g. by using a view)
|
2013-10-04 18:13:37 +00:00
|
|
|
;ps_endpoints => odbc,asterisk
|
|
|
|
|
;ps_auths => odbc,asterisk
|
|
|
|
|
;ps_aors => odbc,asterisk
|
|
|
|
|
;ps_domain_aliases => odbc,asterisk
|
|
|
|
|
;ps_endpoint_id_ips => odbc,asterisk
|
2017-04-07 13:35:33 +00:00
|
|
|
;ps_outbound_publishes => odbc,asterisk
|
|
|
|
|
;ps_inbound_publications = odbc,asterisk
|
|
|
|
|
;ps_asterisk_publications = odbc,asterisk
|
Stir/Shaken Refactor
Why do we need a refactor?
The original stir/shaken implementation was started over 3 years ago
when little was understood about practical implementation. The
result was an implementation that wouldn't actually interoperate
with any other stir-shaken implementations.
There were also a number of stir-shaken features and RFC
requirements that were never implemented such as TNAuthList
certificate validation, sending Reason headers in SIP responses
when verification failed but we wished to continue the call, and
the ability to send Media Key(mky) grants in the Identity header
when the call involved DTLS.
Finally, there were some performance concerns around outgoing
calls and selection of the correct certificate and private key.
The configuration was keyed by an arbitrary name which meant that
for every outgoing call, we had to scan the entire list of
configured TNs to find the correct cert to use. With only a few
TNs configured, this wasn't an issue but if you have a thousand,
it could be.
What's changed?
* Configuration objects have been refactored to be clearer about
their uses and to fix issues.
* The "general" object was renamed to "verification" since it
contains parameters specific to the incoming verification
process. It also never handled ca_path and crl_path
correctly.
* A new "attestation" object was added that controls the
outgoing attestation process. It sets default certificates,
keys, etc.
* The "certificate" object was renamed to "tn" and had it's key
change to telephone number since outgoing call attestation
needs to look up certificates by telephone number.
* The "profile" object had more parameters added to it that can
override default parameters specified in the "attestation"
and "verification" objects.
* The "store" object was removed altogther as it was never
implemented.
* We now use libjwt to create outgoing Identity headers and to
parse and validate signatures on incoming Identiy headers. Our
previous custom implementation was much of the source of the
interoperability issues.
* General code cleanup and refactor.
* Moved things to better places.
* Separated some of the complex functions to smaller ones.
* Using context objects rather than passing tons of parameters
in function calls.
* Removed some complexity and unneeded encapsuation from the
config objects.
Resolves: #351
Resolves: #46
UserNote: Asterisk's stir-shaken feature has been refactored to
correct interoperability, RFC compliance, and performance issues.
See https://docs.asterisk.org/Deployment/STIR-SHAKEN for more
information.
UpgradeNote: The stir-shaken refactor is a breaking change but since
it's not working now we don't think it matters. The
stir_shaken.conf file has changed significantly which means that
existing ones WILL need to be changed. The stir_shaken.conf.sample
file in configs/samples/ has quite a bit more information. This is
also an ABI breaking change since some of the existing objects
needed to be changed or removed, and new ones added. Additionally,
if res_stir_shaken is enabled in menuselect, you'll need to either
have the development package for libjwt v1.15.3 installed or use
the --with-libjwt-bundled option with ./configure.
(cherry picked from commit e6c7f1aee0e54733709c5e41bf8305b6dc3e3dc3)
2023-10-26 16:27:35 +00:00
|
|
|
;stir_tn => odbc,asterisk
|
2004-10-08 05:36:23 +00:00
|
|
|
;voicemail => odbc,asterisk
|
2004-11-28 21:28:30 +00:00
|
|
|
;extensions => odbc,asterisk
|
2009-08-18 19:25:09 +00:00
|
|
|
;meetme => mysql,general
|
2005-06-02 21:42:49 +00:00
|
|
|
;queues => odbc,asterisk
|
|
|
|
|
;queue_members => odbc,asterisk
|
app_queue: Add RealTime support for queue rules
This patch gives the optional ability to keep queue rules in RealTime. It is
important to note that with this patch:
(a) Queue rules in RealTime are only examined on module load/reload
(b) Queue rules are loaded both from the queuerules.conf file as well as the
RealTime backend
To inform app_queue to examine RealTime for queue rules, a new setting has been
added to queuerules.conf's general section "realtime_rules". RealTime queue
rules will only be used when this setting is set to "yes".
The schema for the database table supports a rule_name, time, min_penalty, and
max_penalty columns. min_penalty and max_penalty can be relative, if a '-' or
'+' literal is provided. Otherwise, the penalties are treated as constants.
For example:
rule_name, time, min_penalty, max_penalty
'default', '10', '20', '30'
'test2', '20', '30', '55'
'test2', '25', '-11', '+1111'
'test2', '400', '112', '333'
'test3', '0', '4564', '46546'
'test_rule', '40', '15', '50'
which would result in :
Rule: default
- After 10 seconds, adjust QUEUE_MAX_PENALTY to 30 and adjust
QUEUE_MIN_PENALTY to 20
Rule: test2
- After 20 seconds, adjust QUEUE_MAX_PENALTY to 55 and adjust
QUEUE_MIN_PENALTY to 30
- After 25 seconds, adjust QUEUE_MAX_PENALTY by 1111 and adjust
QUEUE_MIN_PENALTY by -11
- After 400 seconds, adjust QUEUE_MAX_PENALTY to 333 and adjust
QUEUE_MIN_PENALTY to 112
Rule: test3
- After 0 seconds, adjust QUEUE_MAX_PENALTY to 46546 and adjust
QUEUE_MIN_PENALTY to 4564
Rule: test_rule
- After 40 seconds, adjust QUEUE_MAX_PENALTY to 50 and adjust
QUEUE_MIN_PENALTY to 15
If you use RealTime, the queue rules will be always reloaded on a module
reload, even if the underlying file did not change. With the option disabled,
the rules will only be reloaded if the file was modified.
Review: https://reviewboard.asterisk.org/r/3607/
ASTERISK-23823 #close
Reported by: Michael K
patches:
app_queue.c_realtime_trunk.patch uploaded by Michael K (License 6621)
........
Merged revisions 420624 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-11 00:14:53 +00:00
|
|
|
;queue_rules => odbc,asterisk
|
2012-07-11 18:33:36 +00:00
|
|
|
;acls => odbc,asterisk
|
2009-08-18 19:25:09 +00:00
|
|
|
;musiconhold => mysql,general
|
2019-09-18 11:56:05 +00:00
|
|
|
;musiconhold_entry => mysql,general
|
2009-08-18 19:25:09 +00:00
|
|
|
;queue_log => mysql,general
|
2008-12-15 21:17:07 +00:00
|
|
|
;
|
|
|
|
|
;
|
|
|
|
|
; While most dynamic realtime engines are automatically used when defined in
|
|
|
|
|
; this file, 'extensions', distinctively, is not. To activate dynamic realtime
|
|
|
|
|
; extensions, you must turn them on in each respective context within
|
|
|
|
|
; extensions.conf with a switch statement. The syntax is:
|
|
|
|
|
; switch => Realtime/[[db_context@]tablename]/<opts>
|
|
|
|
|
; The only option available currently is the 'p' option, which disallows
|
|
|
|
|
; extension pattern queries to the database. If you have no patterns defined
|
|
|
|
|
; in a particular context, this will save quite a bit of CPU time. However,
|
|
|
|
|
; note that using dynamic realtime extensions is not recommended anymore as a
|
|
|
|
|
; best practice; instead, you should consider writing a static dialplan with
|
|
|
|
|
; proper data abstraction via a tool like func_odbc.
|
