Skip to content
Snippets Groups Projects
Commit eafa9b0d authored by Michiel van Baak's avatar Michiel van Baak
Browse files

document var_metric usage to prevent bugreports that are actually configuration issues

(closes issue #12151)
Reported by: caio1982
Patches:
      DB_metric3.diff uploaded by caio1982 (license 22)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
parent 0890880c
No related branches found
No related tags found
No related merge requests found
...@@ -39,6 +39,20 @@ modules that read configurations, there's no difference between a static ...@@ -39,6 +39,20 @@ modules that read configurations, there's no difference between a static
file in the file system, like extensions.conf, and a configuration loaded file in the file system, like extensions.conf, and a configuration loaded
from a database. from a database.
You just have to always make sure the var\_metric values are properly set and
ordered as you expect in your database server if you're using the static mode
with ARA (either sequentially or with the same var\_metric value for everybody).
If you have an option that depends on another one in a given configuration
file (i.e, 'musiconhold' depending on 'agent' from agents.conf) but their
var\_metric are not sequential you'll probably get default values being assigned for
those options instead of the desired ones. You can still use the same
var\_metric for all entries in your DB, just make sure the entries
are recorded in an order that does not break the option dependency.
That doesn't happen when you use a static file in the file system. Although
this might be interpreted as a bug or limitation, it is not.
\subsubsection{Realtime SIP friends} \subsubsection{Realtime SIP friends}
The SIP realtime objects are users and peers that are loaded in memory The SIP realtime objects are users and peers that are loaded in memory
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment