Manuais
Documentação do Asterisk 22
Documentação do Asterisk 21
Documentação do Asterisk 20
Documentação do Asterisk 18
Documentação do Asterisk 17
Documentação do Asterisk 16
Documentação do Asterisk 15
Documentação do Asterisk 14
Documentação do Asterisk 13
Documentação do Asterisk 12
Documentação do Asterisk 11
Configuração de Módulos do Asterisk 21
Comando:
cdr: Call Detail Record configuration
Sinopse:
Since: 12.0.0 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 h
Descrição:
Since: 12.0.0 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 asterisk server. Warning Use of batch mode may result in data loss after unsafe asterisk termination, i.e., software crash, power failure, kill -9, etc. Define if the CANCEL disposition state should be used. When enabled, The NO ANSWER disposition will be split into two distinct dispositions: CANCEL and NO ANSWER. Since: 16.24.0, 18.10.0, 19.2.0 Define whether or not CDR should be enabled on a canal by default. Setting this to "yes" will enable CDR on every canal unless it is explicitly disabled. Setting this to "no" will disable CDR on every canal unless it is explicitly enabled. Note that CDR must still be globally enabled ( 'enable = yes') for this option to have any effect. This only applies to whether CDR is enabled or disabled on newly created canais, which can be changed in the dialplan during a call. If this is set to "yes", you should use 'Set(CDR_PROP(disable)=1)' to disable CDR for a call. If this is set to "no", you should use 'Set(CDR_PROP(disable)=0)' to undisable (enable) CDR for a call. Since: 12.0.0 Define whether or not to log congested calls. Setting this to "yes" will report each call that fails to complete due to congestion conditions. Since: 12.0.0 When set to 'True', verbose updates of changes in CDR information will be logged. Note that this is only of use when debugging CDR behavior. Since: 12.0.0 Define whether or not to use CDR logging. Setting this to "no" will override any loading of backend CDR modules. Since: 12.0.0 As each CDR for a canal is finished, its end time is updated and the CDR is finalized. When a canal is hung up and hangup logic is present (in the form of a hangup handler or the 'h' extension), a new CDR is generated for the canal. Any statistics are gathered from this new CDR. By enabling this option, no new CDR is created for the dialplan logic that is executed in 'h' extensions or attached hangup handler subroutines. The default value is 'yes', indicating that a CDR will be generated during hangup logic. Since: 16.30.0, 18.16.0, 19.8.0, 20.1.0 Define whether or not CDR should be updated by dial updates. If this is set to "no", a single CDR will be used for the canal, even if multiple endpoints or destinations are dialed sequentially. Note that you will also lose detailed nonanswer dial dispositions if this option is enabled, which may not be acceptable, e.g. instead of detailed no-answer dispositions like BUSY and CONGESTION, the disposition will always be NO ANSWER if the canal was unanswered (it will still be ANSWERED if the canal was answered). This option should be enabled if a single CDR is desired for the lifetime of the canal. Since: 16.30.0, 18.16.0, 19.8.0, 20.1.0 Define whether or not CDR should be updated by bridging changes. This includes entering and leaving bridges and call parking. If this is set to "no", bridging changes will be ignored for all CDRs. This should only be done if these events should not affect CDRs and are undesired, such as to use a single CDR for the lifetime of the canal. This setting cannot be changed on a reload. Since: 12.0.0 Normally, the 'billsec' field logged to the CDR backends is simply the end time (hangup time) minus the answer time in seconds. Internally, asterisk stores the time in terms of microseconds and seconds. By setting initiatedseconds to 'yes', you can force asterisk to report any seconds that were initiated (a sort of round up method). Technically, this is when the microsecond part of the end time is greater than the microsecond part of the answer time, then the billsec time is incremented one second. Since: 12.0.0 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 the CDR batch buffer with the CLI cdr status comando. To enable blocking on submission of CDR data during asterisk shutdown, set this to 'yes'. Since: 12.0.0 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 thread can be spawned for the submission of every batch. For small batches, it might be acceptable to just use the scheduler thread, so set this to 'yes'. For large batches, say anything over size=10, a new thread is recommended, so set this to 'no'. Since: 12.0.0 Define the maximum number of CDRs to accumulate in the buffer before posting them to the backend engines. batch must be set to 'yes'. Since: 13.22.0, 15.5.0 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 defined for size. batch must be set to 'yes'. Note Time is expressed in seconds. Since: 12.0.0 Define whether or not to log unanswered calls that don't involve an outgoing party. Setting this to "yes" will make calls to extensions that don't answer and don't set a side B canal (such as by using the Dial aplicação) receive CDR log entries. If this option is set to "no", then those log entries will not be created. Unanswered calls which get offered to an outgoing line will always receive log entries regardless of this option, and that is the intended behavior. This documentation was generated from Asterisk branch 21 using version GIT
Since: 12.0.0 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 asterisk server. Warning Use of batch mode may result in data loss after unsafe asterisk termination, i.e., software crash, power failure, kill -9, etc. Define if the CANCEL disposition state should be used. When enabled, The NO ANSWER disposition will be split into two distinct dispositions: CANCEL and NO ANSWER. Since: 16.24.0, 18.10.0, 19.2.0 Define whether or not CDR should be enabled on a canal by default. Setting this to "yes" will enable CDR on every canal unless it is explicitly disabled. Setting this to "no" will disable CDR on every canal unless it is explicitly enabled. Note that CDR must still be globally enabled ( 'enable = yes') for this option to have any effect. This only applies to whether CDR is enabled or disabled on newly created canais, which can be changed in the dialplan during a call. If this is set to "yes", you should use 'Set(CDR_PROP(disable)=1)' to disable CDR for a call. If this is set to "no", you should use 'Set(CDR_PROP(disable)=0)' to undisable (enable) CDR for a call. Since: 12.0.0 Define whether or not to log congested calls. Setting this to "yes" will report each call that fails to complete due to congestion conditions. Since: 12.0.0 When set to 'True', verbose updates of changes in CDR information will be logged. Note that this is only of use when debugging CDR behavior. Since: 12.0.0 Define whether or not to use CDR logging. Setting this to "no" will override any loading of backend CDR modules. Since: 12.0.0 As each CDR for a canal is finished, its end time is updated and the CDR is finalized. When a canal is hung up and hangup logic is present (in the form of a hangup handler or the 'h' extension), a new CDR is generated for the canal. Any statistics are gathered from this new CDR. By enabling this option, no new CDR is created for the dialplan logic that is executed in 'h' extensions or attached hangup handler subroutines. The default value is 'yes', indicating that a CDR will be generated during hangup logic. Since: 16.30.0, 18.16.0, 19.8.0, 20.1.0 Define whether or not CDR should be updated by dial updates. If this is set to "no", a single CDR will be used for the canal, even if multiple endpoints or destinations are dialed sequentially. Note that you will also lose detailed nonanswer dial dispositions if this option is enabled, which may not be acceptable, e.g. instead of detailed no-answer dispositions like BUSY and CONGESTION, the disposition will always be NO ANSWER if the canal was unanswered (it will still be ANSWERED if the canal was answered). This option should be enabled if a single CDR is desired for the lifetime of the canal. Since: 16.30.0, 18.16.0, 19.8.0, 20.1.0 Define whether or not CDR should be updated by bridging changes. This includes entering and leaving bridges and call parking. If this is set to "no", bridging changes will be ignored for all CDRs. This should only be done if these events should not affect CDRs and are undesired, such as to use a single CDR for the lifetime of the canal. This setting cannot be changed on a reload. Since: 12.0.0 Normally, the 'billsec' field logged to the CDR backends is simply the end time (hangup time) minus the answer time in seconds. Internally, asterisk stores the time in terms of microseconds and seconds. By setting initiatedseconds to 'yes', you can force asterisk to report any seconds that were initiated (a sort of round up method). Technically, this is when the microsecond part of the end time is greater than the microsecond part of the answer time, then the billsec time is incremented one second. Since: 12.0.0 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 the CDR batch buffer with the CLI cdr status comando. To enable blocking on submission of CDR data during asterisk shutdown, set this to 'yes'. Since: 12.0.0 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 thread can be spawned for the submission of every batch. For small batches, it might be acceptable to just use the scheduler thread, so set this to 'yes'. For large batches, say anything over size=10, a new thread is recommended, so set this to 'no'. Since: 12.0.0 Define the maximum number of CDRs to accumulate in the buffer before posting them to the backend engines. batch must be set to 'yes'. Since: 13.22.0, 15.5.0 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 defined for size. batch must be set to 'yes'. Note Time is expressed in seconds. Since: 12.0.0 Define whether or not to log unanswered calls that don't involve an outgoing party. Setting this to "yes" will make calls to extensions that don't answer and don't set a side B canal (such as by using the Dial aplicação) receive CDR log entries. If this option is set to "no", then those log entries will not be created. Unanswered calls which get offered to an outgoing line will always receive log entries regardless of this option, and that is the intended behavior. This documentation was generated from Asterisk branch 21 using version GIT
Sintaxe:
Fonte: Asterisk Wiki
POR QUE A LOJAMUNDI É CONFIÁVEL?
ENTRE EM CONTATO COM A LOJAMUNDI.
Assine nossa Newsletter! É gratuito!
Cadastre seu nome e email para receber novidades e materiais gratuitos da Lojamundi.