kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2025-09-04 11:58:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Add version information to configObject and configOption XML elements

Browse Source 
Most of the configObjects and configOptions that are implemented with
ACO or Sorcery now have `<since>/<version>` elements added.  There are
probably some that the script I used didn't catch.  The version tags were
determined by the following...
 * Do a git blame on the API call that created the object or option.
 * From the commit hash, grab the summary line.
 * Do a `git log --grep <summary>` to find the cherry-pick commits in all
   branches that match.
 * Do a `git patch-id` to ensure the commits are all related and didn't get
   a false match on the summary.
 * Do a `git tag --contains <commit>` to find the tags that contain each
   commit.
 * Weed out all tags not <major>.<minor>.0.
 * Sort and discard any <major>.0.0 and following tags where the commit
   appeared in an earlier branch.
 * The result is a single tag for each branch where the API was last touched.

configObjects and configOptions elements implemented with the base
ast_config APIs were just not possible to find due to the non-deterministic
way they are accessed.

Also note that if the API call was on modified after it was added, the
version will be the one it was last modified in.

Final note:  The configObject and configOption elements were introduced in
12.0.0 so options created before then may not have any XML documentation.
This commit is contained in:
George Joseph
2025-01-16 14:54:35 -07:00
committed by asterisk-org-access-app[bot]
parent 0c272429e6
commit f70670841b
31 changed files with 649 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
main/cdr.c
View File

@@ -82,8 +82,10 @@
</description>
<configFile name="cdr.conf">
<configObject name="general">
<since><version>12.0.0</version></since>
<synopsis>Global settings applied to the CDR engine.</synopsis>
<configOption name="debug">
<since><version>12.0.0</version></since>
<synopsis>Enable/disable verbose CDR debugging.</synopsis>
<description><para>When set to <literal>True</literal>, verbose updates
of changes in CDR information will be logged. Note that this is only
@@ -91,12 +93,14 @@
</description>
</configOption>
<configOption name="enable" default="yes">
<since><version>12.0.0</version></since>
<synopsis>Enable/disable CDR logging.</synopsis>
<description><para>Define whether or not to use CDR logging. Setting this to "no" will override
any loading of backend CDR modules.</para>
</description>
</configOption>
<configOption name="channeldefaultenabled" default="yes">
<since><version>16.24.0</version><version>18.10.0</version><version>19.2.0</version></since>
<synopsis>Whether CDR is enabled on a channel by default</synopsis>
<description><para>Define whether or not CDR should be enabled on a channel by default.
Setting this to "yes" will enable CDR on every channel unless it is explicitly disabled.
@@ -112,6 +116,7 @@
</description>
</configOption>
<configOption name="ignorestatechanges" default="no">
<since><version>16.30.0</version><version>18.16.0</version><version>19.8.0</version><version>20.1.0</version></since>
<synopsis>Whether CDR is updated or forked by bridging changes.</synopsis>
<description><para>Define whether or not CDR should be updated by bridging changes.
This includes entering and leaving bridges and call parking.</para>
@@ -122,6 +127,7 @@
</description>
</configOption>
<configOption name="ignoredialchanges" default="no">
<since><version>16.30.0</version><version>18.16.0</version><version>19.8.0</version><version>20.1.0</version></since>
<synopsis>Whether CDR is updated or forked by dial updates.</synopsis>
<description><para>Define whether or not CDR should be updated by dial updates.</para>
<para>If this is set to "no", a single CDR will be used for the channel, even if
@@ -135,6 +141,7 @@
</description>
</configOption>
<configOption name="unanswered">
<since><version>12.0.0</version></since>
<synopsis>Log calls that are never answered and don't set an outgoing party.</synopsis>
<description><para>
Define whether or not to log unanswered calls that don't involve an outgoing party. Setting
@@ -147,12 +154,14 @@
</description>
</configOption>
<configOption name="congestion">
<since><version>12.0.0</version></since>
<synopsis>Log congested calls.</synopsis>
<description><para>Define whether or not to log congested calls. Setting this to "yes" will
report each call that fails to complete due to congestion conditions.</para>
</description>
</configOption>
<configOption name="endbeforehexten">
<since><version>12.0.0</version></since>
<synopsis>Don't produce CDRs while executing hangup logic</synopsis>
<description>
<para>As each CDR for a channel is finished, its end time is updated
@@ -167,6 +176,7 @@
</description>
</configOption>
<configOption name="initiatedseconds">
<since><version>12.0.0</version></since>
<synopsis>Count microseconds for billsec purposes</synopsis>
<description><para>Normally, the <literal>billsec</literal> field logged to the CDR backends
is simply the end time (hangup time) minus the answer time in seconds. Internally,
@@ -178,6 +188,7 @@
</description>
</configOption>
<configOption name="batch">
<since><version>12.0.0</version></since>
<synopsis>Submit CDRs to the backends for processing in batches</synopsis>
<description><para>Define the CDR batch mode, where instead of posting the CDR at the end of
every call, the data will be stored in a buffer to help alleviate load on the
@@ -188,12 +199,14 @@
</description>
</configOption>
<configOption name="size">
<since><version>12.0.0</version></since>
<synopsis>The maximum number of CDRs to accumulate before triggering a batch</synopsis>
<description><para>Define the maximum number of CDRs to accumulate in the buffer before posting
them to the backend engines. batch must be set to <literal>yes</literal>.</para>
</description>
</configOption>
<configOption name="time">
<since><version>13.22.0</version><version>15.5.0</version></since>
<synopsis>The maximum time to accumulate CDRs before triggering a batch</synopsis>
<description><para>Define the maximum time to accumulate CDRs before posting them in a batch to the
backend engines. If this time limit is reached, then it will post the records, regardless of the value
@@ -202,6 +215,7 @@
</description>
</configOption>
<configOption name="scheduleronly">
<since><version>12.0.0</version></since>
<synopsis>Post batched CDRs on their own thread instead of the scheduler</synopsis>
<description><para>The CDR engine uses the internal asterisk scheduler to determine when to post
records. Posting can either occur inside the scheduler thread, or a new
@@ -212,6 +226,7 @@
</description>
</configOption>
<configOption name="safeshutdown">
<since><version>12.0.0</version></since>
<synopsis>Block shutdown of Asterisk until CDRs are submitted</synopsis>
<description><para>When shutting down asterisk, you can block until the CDRs are submitted. If
you don't, then data will likely be lost. You can always check the size of