modules: readme files regenerated - acc ... [skip ci]

src/modules/acc/README

@@ -1,1498 +1,2 @@
-Acc Module
 
-Jiri Kuthan
 
-   iptel.org
-   <[email protected]>
-
-Bogdan-Andrei Iancu
-
-   Voice Sistem SRL
-   <[email protected]>
-
-Ramona-Elena Modroiu
-
-   rosdev.ro
-   <[email protected]>
-
-Edited by
-
-Bogdan-Andrei Iancu
-
-   Voice Sistem SRL
-   <[email protected]>
-
-Edited by
-
-Sven Knoblich
-
-   1&1 Internet AG
-   <[email protected]>
-
-   Copyright © 2002, 2003 FhG FOKUS
-
-   Copyright © 2004, 2006 Voice Sistem SRL
-
-   Copyright © 2011 1&1 Internet AG
-     __________________________________________________________________
-
-   Table of Contents
-
-   1. Admin Guide
-
-        1. Overview
-
-              1.1. General Example
-
-        2. Extra accounting
-
-              2.1. Overview
-              2.2. Definitions and syntax
-              2.3. How it works
-
-        3. Multi Call-Legs accounting
-
-              3.1. Overview
-              3.2. Configuration
-              3.3. Logged data
-
-        4. Call Data Record generation
-
-              4.1. Overview
-              4.2. CDR Extra
-
-                    4.2.1. Definitions and syntax
-
-              4.3. CDR with Multi Call-Legs
-
-                    4.3.1. Overview
-                    4.3.2. Configuration
-
-                          4.3.2.1. Example for a spiraled Proxy
-
-                    4.3.3. Logged data
-
-        5. Dependencies
-
-              5.1. Kamailio Modules
-              5.2. External Libraries or Applications
-
-        6. Parameters
-
-              6.1. early_media (integer)
-              6.2. failed_transaction_flag (integer)
-              6.3. failed_filter (string)
-              6.4. report_ack (integer)
-              6.5. report_cancels (integer)
-              6.6. detect_direction (integer)
-              6.7. acc_prepare_flag (integer)
-              6.8. acc_prepare_always (integer)
-              6.9. multi_leg_info (string)
-              6.10. log_flag (integer)
-              6.11. log_missed_flag (integer)
-              6.12. log_level (integer)
-              6.13. log_facility (string)
-              6.14. log_extra (string)
-              6.15. db_flag (integer)
-              6.16. db_missed_flag (integer)
-              6.17. db_table_acc (string)
-              6.18. db_table_missed_calls (string)
-              6.19. db_url (string)
-              6.20. acc_method_column (string)
-              6.21. acc_from_tag_column (string)
-              6.22. acc_to_tag_column (string)
-              6.23. acc_callid_column (string)
-              6.24. acc_sip_code_column (string)
-              6.25. acc_sip_reason_column (string)
-              6.26. acc_time_column (string)
-              6.27. db_extra (string)
-              6.28. db_insert_mode (integer)
-              6.29. diameter_flag (integer)
-              6.30. diameter_missed_flag (integer)
-              6.31. diameter_client_host (string)
-              6.32. diameter_client_port (int)
-              6.33. diameter_extra (string)
-              6.34. cdr_enable (integer)
-              6.35. cdr_expired_dlg_enable (integer)
-              6.36. cdr_start_on_confirmed (integer)
-              6.37. cdr_facility (integer)
-              6.38. cdr_extra (string)
-              6.39. cdr_start_id (string)
-              6.40. cdr_end_id (string)
-              6.41. cdr_duration_id (string)
-              6.42. cdr_log_enable (int)
-              6.43. cdrs_table (str)
-              6.44. time_mode (int)
-              6.45. time_attr (str)
-              6.46. time_exten (str)
-              6.47. time_format (str)
-              6.48. reason_from_hf (int)
-              6.49. clone_msg (int)
-              6.50. cdr_on_failed (int)
-
-        7. Functions
-
-              7.1. acc_log_request(comment)
-              7.2. acc_db_request(comment, table)
-              7.3. acc_request(comment, table)
-              7.4. acc_diam_request(comment)
-
-   2. Frequently Asked Questions
-
-   List of Examples
-
-   1.1. early_media example
-   1.2. failed_transaction_flag example
-   1.3. failed_filter example
-   1.4. report_ack example
-   1.5. report_cancels example
-   1.6. detect_direction example
-   1.7. acc_prepare_flag example
-   1.8. acc_prepare_flag example
-   1.9. multi_leg_info example
-   1.10. log_flag example
-   1.11. log_missed_flag example
-   1.12. log_level example
-   1.13. log_facility example
-   1.14. log_extra example
-   1.15. db_flag example
-   1.16. db_missed_flag example
-   1.17. db_table_acc example
-   1.18. db_table_missed_calls example
-   1.19. db_url example
-   1.20. acc_method_column example
-   1.21. acc_from_tag_column example
-   1.22. acc_to_tag_column example
-   1.23. acc_callid_column example
-   1.24. acc_sip_code_column example
-   1.25. acc_sip_reason_column example
-   1.26. acc_time_column example
-   1.27. db_extra example
-   1.28. db_insert_mode example
-   1.29. diameter_flag example
-   1.30. diameter_missed_flag example
-   1.31. diameter_client_host example
-   1.32. diameter_client_host example
-   1.33. diameter_extra example
-   1.34. cdr_enable example
-   1.35. cdr_expired_dlg_enable example
-   1.36. cdr_start_on_confirmed example
-   1.37. cdr_facility example
-   1.38. cdr_extra example
-   1.39. cdr_start_id example
-   1.40. cdr_end_id example
-   1.41. cdr_duration_id example
-   1.42. cdr_log_enable example
-   1.43. cdrs_table example
-   1.44. time_mode example
-   1.45. time_attr example
-   1.46. time_exten example
-   1.47. time_format example
-   1.48. reason_from_hf
-   1.49. clone_msg
-   1.50. cdr_on_failed
-   1.51. acc_log_request usage
-   1.52. acc_db_request usage
-   1.53. acc_db_request usage
-   1.54. acc_diam_request usage
-
-Chapter 1. Admin Guide
-
-   Table of Contents
-
-   1. Overview
-
-        1.1. General Example
-
-   2. Extra accounting
-
-        2.1. Overview
-        2.2. Definitions and syntax
-        2.3. How it works
-
-   3. Multi Call-Legs accounting
-
-        3.1. Overview
-        3.2. Configuration
-        3.3. Logged data
-
-   4. Call Data Record generation
-
-        4.1. Overview
-        4.2. CDR Extra
-
-              4.2.1. Definitions and syntax
-
-        4.3. CDR with Multi Call-Legs
-
-              4.3.1. Overview
-              4.3.2. Configuration
-
-                    4.3.2.1. Example for a spiraled Proxy
-
-              4.3.3. Logged data
-
-   5. Dependencies
-
-        5.1. Kamailio Modules
-        5.2. External Libraries or Applications
-
-   6. Parameters
-
-        6.1. early_media (integer)
-        6.2. failed_transaction_flag (integer)
-        6.3. failed_filter (string)
-        6.4. report_ack (integer)
-        6.5. report_cancels (integer)
-        6.6. detect_direction (integer)
-        6.7. acc_prepare_flag (integer)
-        6.8. acc_prepare_always (integer)
-        6.9. multi_leg_info (string)
-        6.10. log_flag (integer)
-        6.11. log_missed_flag (integer)
-        6.12. log_level (integer)
-        6.13. log_facility (string)
-        6.14. log_extra (string)
-        6.15. db_flag (integer)
-        6.16. db_missed_flag (integer)
-        6.17. db_table_acc (string)
-        6.18. db_table_missed_calls (string)
-        6.19. db_url (string)
-        6.20. acc_method_column (string)
-        6.21. acc_from_tag_column (string)
-        6.22. acc_to_tag_column (string)
-        6.23. acc_callid_column (string)
-        6.24. acc_sip_code_column (string)
-        6.25. acc_sip_reason_column (string)
-        6.26. acc_time_column (string)
-        6.27. db_extra (string)
-        6.28. db_insert_mode (integer)
-        6.29. diameter_flag (integer)
-        6.30. diameter_missed_flag (integer)
-        6.31. diameter_client_host (string)
-        6.32. diameter_client_port (int)
-        6.33. diameter_extra (string)
-        6.34. cdr_enable (integer)
-        6.35. cdr_expired_dlg_enable (integer)
-        6.36. cdr_start_on_confirmed (integer)
-        6.37. cdr_facility (integer)
-        6.38. cdr_extra (string)
-        6.39. cdr_start_id (string)
-        6.40. cdr_end_id (string)
-        6.41. cdr_duration_id (string)
-        6.42. cdr_log_enable (int)
-        6.43. cdrs_table (str)
-        6.44. time_mode (int)
-        6.45. time_attr (str)
-        6.46. time_exten (str)
-        6.47. time_format (str)
-        6.48. reason_from_hf (int)
-        6.49. clone_msg (int)
-        6.50. cdr_on_failed (int)
-
-   7. Functions
-
-        7.1. acc_log_request(comment)
-        7.2. acc_db_request(comment, table)
-        7.3. acc_request(comment, table)
-        7.4. acc_diam_request(comment)
-
-1. Overview
-
-   1.1. General Example
-
-   ACC module is used to account transactions information to different
-   backends like syslog and SQL. With the separate module, radius support
-   is enabled.
-
-   There is some very early support of the Diameter protocol in the code
-   which is no longer included by default and will be deleted in coming
-   releases. This support is not up to date with the current Diameter
-   protocols and is disabled. If you need Diameter support, please use the
-   ims_charging module.
-
-   To account a transaction and to choose which set of backends to be
-   used, the script writer just has to set some flags (see the module
-   parameters section for flag definitions Section 6, “Parameters”). If
-   the accounting flag for a specific backend is set, the acc module will
-   then report on completed transaction. A typical usage of the module
-   takes no acc-specific script command -- the functionality binds
-   invisibly through transaction processing. Script writers just need to
-   mark the transaction for accounting with proper setflag. Even so, the
-   module allows the script writter to force accounting in special cases
-   via some script functions.
-
-   The accounting module will log by default a fixed set of attributes for
-   the transaction - if you customize your accounting by adding more
-   information to be logged, please see the next chapter about extra
-   accounting - Section 2, “Extra accounting”.
-
-   The fixed minimal accounting information is:
-     * Request Method name
-     * From header TAG parameter
-     * To header TAG parameter
-     * Call-Id
-     * 3-digit Status code from final reply
-     * Reason phrase from final reply
-     * Time stamp when transaction was completed
-
-   If a value is not present in request, the empty string is accounted
-   instead.
-
-   Note that:
-     * A single INVITE may produce multiple accounting reports -- that's
-       due to SIP forking feature.
-     * All flags related to accounting need to be set in request
-       processing route - only the "missed-call" flag may be toggled from
-       other types of routes.
-     * If a UA fails in middle of conversation, a proxy will never find
-       out about it. In general, a better practice is to account from an
-       end-device (such as PSTN gateway), which best knows about call
-       status (including media status and PSTN status in case of the
-       gateway). However, CDR-base logging has the option to log existing
-       information from expired dialogs (the dlg_vars in cdr_extra) Please
-       see cdr_expired_dlg_enable parameter - Section 6.35,
-       “cdr_expired_dlg_enable (integer)”.
-
-   The SQL backend support is compiled in the module. For DIAMETER you
-   need to enable it by recompiling the module with properly set defines:
-   uncomment the DDIAM_ACC lines in modules/acc/Makefile.
-
-   NOTE: diameter support was developed for DISC (DIameter Server Client
-   project at http://developer.berlios.de/projects/disc/). This project
-   seems to be no longer maintained and DIAMETER specifications were
-   updated in the meantime. Thus, the DIAMETER part in the module is
-   obsolete and needs rework to be usable with opendiameter or other
-   DIAMETER servers.
-
-1.1. General Example
-
-loadmodule "modules/acc/acc.so"
-modparam("acc", "log_level", 1)
-modparam("acc", "log_flag", 1)
-
-if (uri=~"sip:+40") /* calls to Romania */ {
-    if (!proxy_authorize("sip_domain.net" /* realm */,
-    "subscriber" /* table name */))  {
-        proxy_challenge("sip_domain.net" /* realm */, "0" /* no qop */ );
-        exit;
-    }
-
-    if (method=="INVITE" && !check_from()) {
-        log("from!=digest\n");
-        sl_send_reply("403","Forbidden");
-    }
-
-    setflag(1); /* set for accounting (the same value as in log_flag!)
-    t_relay();  /* enter stateful mode now */
-};
-
-2. Extra accounting
-
-   2.1. Overview
-   2.2. Definitions and syntax
-   2.3. How it works
-
-2.1. Overview
-
-   Along the static default information, ACC modules allows dynamical
-   selection of extra information to be logged. This allows you to log any
-   pseudo-variable (AVPs, parts of the request, etc).
-
-2.2. Definitions and syntax
-
-   Selection of extra information is done via xxx_extra parameters by
-   specifying the names of additional information you want to log. This
-   information is defined via pseudo-variables and may include headers,
-   AVPs values or other message or system values. The syntax of the
-   parameter is:
-     * xxx_extra = extra_definition (';'extra_definition)*
-     * extra_definition = log_name '=' pseudo_variable
-
-   The full list of supported pseudo-variables in Kamailio is available
-   at: http://www.kamailio.org/wiki/cookbooks/devel/pseudovariables
-
-   Note: For all the ACK processed by tm, the registered callbacks (like
-   acc module) will be called with the corresponding INVITE transaction
-   contexts as long as this is still available. This means that the ACK
-   callbacks will see the AVPs setup for the INVITE transaction and not
-   the AVPs setup before t_relay().
-
-   Via log_name you define how/where the data will be logged. Its meaning
-   depends of the accounting support which is used:
-     * LOG accounting - log_name will be just printed along with the data
-       in log_name=data format;
-     * DB accounting - log_name will be the name of the DB column where
-       the data will be stored.IMPORTANT: add in db acc table the columns
-       corresponding to each extra data;
-     * RADIUS accounting - log_name will be the AVP name used for packing
-       the data into RADIUS message. The log_name will be translated to
-       AVP number via the dictionary. IMPORTANT: add in RADIUS dictionary
-       the log_name attribute.
-     * DIAMETER accounting - log_name will be the AVP code used for
-       packing the data into DIAMETER message. The AVP code is given
-       directly as integer, since DIAMETER has no dictionary support yet.
-       IMPORTANT: log_name must be a number.
-
-2.3. How it works
-
-   Some pseudo variables may return more than one value (like headers or
-   AVPs). In this case, the returned values are embedded in a single
-   string in a comma-separated format.
-
-3. Multi Call-Legs accounting
-
-   3.1. Overview
-   3.2. Configuration
-   3.3. Logged data
-
-3.1. Overview
-
-   A SIP call can have multiple legs due forwarding actions. For example
-   user A calls user B which forwards the call to user C. There is only
-   one SIP call but with 2 legs ( A to B and B to C). Accounting the legs
-   of a call is required for proper billing of the calls (if C is a PSTN
-   number and the call is billed, user B must pay for the call - as last
-   party modifing the call destination-, and not A - as initiator of the
-   call. Call forwarding on server is only one example which shows the
-   necessity of the having an accounting engine with multiple legs
-   support.
-
-3.2. Configuration
-
-   First how it works: The idea is to have a set of AVPs and for each call
-   leg to store a set of values in the AVPs. The meaning of the AVP
-   content is stricly decided by the script writer - it can be the origin
-   and source of the leg, its status or any other related information. If
-   you have a set of 4 AVPS (AVP1, AVP2, AVP3, AVP4), then for the "A call
-   B and B forwards to C" example, you need to set a different set of
-   values for the AVPs for each leg ([A,B] and [B,C]) . The script writer
-   must take care and properly insert all these AVP from the script (in
-   proper order and with the correct type).
-
-   When the accounting information for the call will be written/sent, all
-   the call-leg pairs will be added (based on the found AVP sets).
-
-   By default, the multiple call-leg support is disabled - it can be
-   enabled just be setting the per-leg set of AVPs via the multi_leg_info
-   module parameter.
-
-3.3. Logged data
-
-   For each call, all the values of the AVP set (which defines a call-leg)
-   will be logged. How the information will be actually logged, depends of
-   the data backend:
-     * syslog -- all leg-sets will be added to one record string as
-       AVP1=xxx, AVP2=xxxx ,... sets.
-     * database -- each pair will be separately logged (due DB data
-       structure constraints); several records will be written, the
-       difference between them being only the fields corresponding to the
-       call-leg info.
-
-Note
-       You will need to add in your DB (all acc related tables) the colums
-       for call-leg info (a column for each AVP of the set).
-     * Radius -- all sets will be added to the same Radius accounting
-       message as RADIUS AVPs - for each call-leg a set of RADIUS AVPs
-       will be added (corresponding to the per-leg AVP set). Note that
-       Radius support is in a separate module - acc_radius.
-
-Note
-       You will need to add in your dictionary the RADIUS AVPs used in
-       call-leg AVP set definition.
-
-4. Call Data Record generation
-
-   4.1. Overview
-   4.2. CDR Extra
-
-        4.2.1. Definitions and syntax
-
-   4.3. CDR with Multi Call-Legs
-
-        4.3.1. Overview
-        4.3.2. Configuration
-
-              4.3.2.1. Example for a spiraled Proxy
-
-        4.3.3. Logged data
-
-4.1. Overview
-
-   In addition to transaction-based logging, it is possible to generate
-   and log Call Data Records (CDRs) directly from Kamailio. Apart from a
-   basic set of CDR fields which are always included (covering start time,
-   end time, and duration), the approach allows flexible specification of
-   additional fields that should be taken into account using the
-   configuration script. This is very similar to how transaction-based
-   logging may be customized with the exception that CDRs rely on dialogs
-   instead of transactions to store relevant information during a call.
-
-   In order to set up CDR generation, you must enable the CDR switch and
-   load the dialog module. You probably also want to specify a set of
-   pseudo-variables that define more relevant CDR fields. Pseudo-variables
-   may be assigned arbitrarily during script execution, and the module
-   will make sure that the variable content will be transformed into a CDR
-   by the end of the dialog.
-
-   To use CDR logging in a correct manner, you should only use the
-   dialog-based pseudo-variables (dlg_var) from the dialog module. This
-   allows you to save values right from the beginning through all requests
-   and replies until termination of the call. While not recommended, it is
-   still possible to use other pseudo-variables as well. Except for
-   pseudo-variables valid in the call-final transaction, however,
-   information given will not be stored in the CDR as they cannot be
-   accessed by the end of the call when the CDR is logged.
-
-   Sometimes, dialogs expire because the UA has a problem and a final
-   message is never transmitted. You can toggle on/off the generation of
-   CDR-based logging in such cases with only the dlg_vars showing by using
-   the cdr_expired_dlg_enable parameter - Section 6.35,
-   “cdr_expired_dlg_enable (integer)”. Default behavior is not logging.
-
-4.2. CDR Extra
-
-   This section is similar to the “LOG accounting” part of Section 2,
-   “Extra accounting”.
-
-4.2.1. Definitions and syntax
-
-   Selection of extra information is done similar to the transaction extra
-   Section 2.2, “Definitions and syntax”.
-     * cdr_extra = cdr_extra_definition (';'cdr_extra_definition)*
-     * cdr_extra_definition = cdr_log_name '=' pseudo_variable
-
-   See also Section 6.38, “cdr_extra (string)”.
-
-   The full list of supported pseudo-variables in Sip-Router is available
-   at: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel
-
-4.3. CDR with Multi Call-Legs
-
-4.3.1. Overview
-
-   As mentioned in Section 3, “Multi Call-Legs accounting”, a leg
-   represents a parallel or forwarded call. In contrast to the normal
-   accounting the cdr logging uses dialogs instead of transaction to log
-   data. This may reduce the amount of information but it also make it
-   possible to combine all important data in one cdr at once. A second
-   mechanism to process multiple data-sets into one cdr is not further
-   necessary.
-
-4.3.2. Configuration
-
-   When you route messages multiple times through your proxy (e.g. to
-   handle “call-forwardings”) you have to use detect_spirals from the
-   dialog modules. Otherwise the proxy can't identify and reuse existing
-   dialogs.
-
-   To get the correct call-forwarding-chain you have to store each cf*
-   with the corresponding caller and callee in a dialog based
-   pseudo-variable (dlg_var) (e.g. chain=B;cfa;C|C;cfnr;D). Additionally
-   it is necessary to store the caller and callee for each leg. All this
-   helps to identify the involved phone parners and forwarding chain. When
-   you route such calls multiple times to the same Proxy, you could store
-   the caller and callee within an transaction based avp and write it into
-   the dialog based dlg_var pv during a 200 INVITE.
-
-4.3.2.1. Example for a spiraled Proxy
-
-...
-# A calls B (transaction 1)
-$avp(caller)='A'
-$avp(callee)='B';
-$dlg_var(chain)='';
-
-# B cfa C (transaction 2)
-$avp(caller)='B'
-$avp(callee)='C';
-$dlg_var(chain)='B;cfu;C';
-
-# C cfnr D (transaction 3)
-$avp(caller)='C'
-$avp(callee)='D';
-$dlg_var(chain)=$dlg_var(chain) + "|" + "C;cfnr;D";
-
-# C confirms call (200 reply of transaction 2)
-$dlg_var(caller) = $avp(caller); #caller='B'
-$dlg_var(callee) = $avp(callee); #callee='C'
-...
-
-4.3.3. Logged data
-
-   For each call, all dialog corresponding variables will be logged. After
-   a call is finished, the generated call data record information will be
-   logged as string (VAR1=xxx,VAR2=xxxx,...) to the syslog.
-
-5. Dependencies
-
-   5.1. Kamailio Modules
-   5.2. External Libraries or Applications
-
-5.1. Kamailio Modules
-
-   The module depends on the following modules (in the other words the
-   listed modules must be loaded before this module):
-     * tm -- Transaction Manager
-     * a database module -- If SQL support is used.
-     * rr -- Record Route, if “detect_direction” module parameter is
-       enabled.
-     * dialog -- Dialog, if “cdr_enable” module parameter is enabled.
-
-5.2. External Libraries or Applications
-
-   The following libraries or applications must be installed before
-   running Kamailio with this module loaded:
-     * None
-
-6. Parameters
-
-   6.1. early_media (integer)
-   6.2. failed_transaction_flag (integer)
-   6.3. failed_filter (string)
-   6.4. report_ack (integer)
-   6.5. report_cancels (integer)
-   6.6. detect_direction (integer)
-   6.7. acc_prepare_flag (integer)
-   6.8. acc_prepare_always (integer)
-   6.9. multi_leg_info (string)
-   6.10. log_flag (integer)
-   6.11. log_missed_flag (integer)
-   6.12. log_level (integer)
-   6.13. log_facility (string)
-   6.14. log_extra (string)
-   6.15. db_flag (integer)
-   6.16. db_missed_flag (integer)
-   6.17. db_table_acc (string)
-   6.18. db_table_missed_calls (string)
-   6.19. db_url (string)
-   6.20. acc_method_column (string)
-   6.21. acc_from_tag_column (string)
-   6.22. acc_to_tag_column (string)
-   6.23. acc_callid_column (string)
-   6.24. acc_sip_code_column (string)
-   6.25. acc_sip_reason_column (string)
-   6.26. acc_time_column (string)
-   6.27. db_extra (string)
-   6.28. db_insert_mode (integer)
-   6.29. diameter_flag (integer)
-   6.30. diameter_missed_flag (integer)
-   6.31. diameter_client_host (string)
-   6.32. diameter_client_port (int)
-   6.33. diameter_extra (string)
-   6.34. cdr_enable (integer)
-   6.35. cdr_expired_dlg_enable (integer)
-   6.36. cdr_start_on_confirmed (integer)
-   6.37. cdr_facility (integer)
-   6.38. cdr_extra (string)
-   6.39. cdr_start_id (string)
-   6.40. cdr_end_id (string)
-   6.41. cdr_duration_id (string)
-   6.42. cdr_log_enable (int)
-   6.43. cdrs_table (str)
-   6.44. time_mode (int)
-   6.45. time_attr (str)
-   6.46. time_exten (str)
-   6.47. time_format (str)
-   6.48. reason_from_hf (int)
-   6.49. clone_msg (int)
-   6.50. cdr_on_failed (int)
-
-6.1. early_media (integer)
-
-   Should be early media (any provisional reply with body) accounted too ?
-
-   Default value is 0 (no).
-
-   Example 1.1. early_media example
-...
-modparam("acc", "early_media", 1)
-...
-
-6.2. failed_transaction_flag (integer)
-
-   Per transaction flag which says if the transaction should be accounted
-   also in case of failure (status>=300).
-
-   Default value is not-set (no flag).
-
-   Example 1.2. failed_transaction_flag example
-...
-modparam("acc", "failed_transaction_flag", 4)
-...
-
-6.3. failed_filter (string)
-
-   A string of failure response codes from 300 to 999 separated by commas.
-   Failed transaction will not be accounted if its response code is in the
-   list even when failed_transaction_flag is set.
-
-   Default value is not-set (failure filtering is off).
-
-   Example 1.3. failed_filter example
-...
-modparam("acc", "failed_filter", "404,407")
-...
-
-6.4. report_ack (integer)
-
-   Shall acc attempt to account e2e ACKs too ? Note that this is really
-   only an attempt, as e2e ACKs may take a different path (unless RR
-   enabled) and mismatch original INVITE (e2e ACKs are a separate
-   transaction). The flag for accounting has to be set for each ACK as
-   well.
-
-   Default value is 0 (no).
-
-   Example 1.4. report_ack example
-...
-modparam("acc", "report_ack", 1)
-...
-
-6.5. report_cancels (integer)
-
-   By default, CANCEL reporting is disabled -- most accounting
-   applications wants to see INVITE's cancellation status. Turn on if you
-   explicitly want to account CANCEL transactions.
-
-   Default value is 0 (no).
-
-   Example 1.5. report_cancels example
-...
-modparam("acc", "report_cancels", 1)
-...
-
-6.6. detect_direction (integer)
-
-   Controlles the direction detection for sequential requests. If enabled
-   (non zero value), for sequential requests with upstream direction (from
-   callee to caller), the FROM and TO will be swapped (the direction will
-   be preserved as in the original request).
-
-   It affects all values related to TO and FROM headers (body, URI,
-   username, domain, TAG).
-
-   Default value is 0 (disabled).
-
-   Example 1.6. detect_direction example
-...
-modparam("acc", "detect_direction", 1)
-...
-
-6.7. acc_prepare_flag (integer)
-
-   Per transaction flag which says if the transaction may be accounted
-   later, with flags set in TM module specific routes (e.g., like
-   failure_route). If this flag is not set and acc or missed_call flag are
-   not set either in request route block, there is no way to mark the
-   request for transaction later unless you set acc_prepare_always. If
-   either acc or missed_call flags are set in request route block, there
-   is no need to set this flag.
-
-   Default value is not-set (no flag).
-
-   Example 1.7. acc_prepare_flag example
-...
-modparam("acc", "acc_prepare_flag", 5)
-...
-
-6.8. acc_prepare_always (integer)
-
-   Prepare all request even if acc_prepare_flag is not set to mark the
-   request for transaction later.
-
-   Default value is not-set (previous behaviour).
-
-   Example 1.8. acc_prepare_flag example
-...
-modparam("acc", "acc_prepare_always", 1)
-...
-
-6.9. multi_leg_info (string)
-
-   Defines the AVP set to be used in per-call-leg accounting. See
-   Section 3, “Multi Call-Legs accounting” for a detailed description of
-   the Multi Call-Legs accounting.
-
-   If empty, the multi-leg accounting support will be disabled.
-
-   Default value is 0 (disabled).
-
-   Example 1.9. multi_leg_info example
-...
-# for syslog-based accounting, use any text you want to be printed
-modparam("acc", "multi_leg_info",
-    "text1=$avp(src);text2=$avp(dst)")
-# for mysql-based accounting, use the names of the columns
-modparam("acc", "multi_leg_info",
-    "leg_src=$avp(src);leg_dst=$avp(dst)")
-# for DIAMETER-based accounting, use the DIAMETER AVP ID (as integer)
-modparam("acc", "multi_leg_info",
-    "2345=$avp(src);2346=$avp(dst)")
-...
-
-6.10. log_flag (integer)
-
-   Request flag which needs to be set to account a transaction via syslog.
-
-   Default value is not-set (no flag).
-
-   Example 1.10. log_flag example
-...
-modparam("acc", "log_flag", 2)
-...
-
-6.11. log_missed_flag (integer)
-
-   Request flag which needs to be set to account missed calls via syslog.
-
-   Default value is not-set (no flag).
-
-   Example 1.11. log_missed_flag example
-...
-modparam("acc", "log_missed_flag", 3)
-...
-
-6.12. log_level (integer)
-
-   Log level at which accounting messages are issued to syslog.
-
-   Default value is 1 (L_NOTICE).
-
-   Example 1.12. log_level example
-...
-modparam("acc", "log_level", 2)   # Set log_level to 2 (L_INFO)
-...
-
-6.13. log_facility (string)
-
-   Log facility to which accounting messages are issued to syslog. This
-   allows to easily seperate the accounting specific logging from the
-   other log messages.
-
-   Default value is LOG_DAEMON.
-
-   Example 1.13. log_facility example
-...
-modparam("acc", "log_facility", "LOG_DAEMON")
-...
-
-6.14. log_extra (string)
-
-   Extra values to be logged. See section Section 2, “Extra accounting”
-   for more details.
-
-   Default value is NULL.
-
-   Example 1.14. log_extra example
-...
-modparam("acc", "log_extra", "ua=$hdr(User-Agent);uuid=$avp(i:123)")
-...
-
-6.15. db_flag (integer)
-
-   Request flag which needs to be set to account a transaction -- database
-   specific.
-
-   Default value is not-set (no flag).
-
-   Example 1.15. db_flag example
-...
-modparam("acc", "db_flag", 2)
-...
-
-6.16. db_missed_flag (integer)
-
-   Request flag which needs to be set to account missed calls -- database
-   specific.
-
-   Default value is not-set (no flag).
-
-   Example 1.16. db_missed_flag example
-...
-modparam("acc", "db_missed_flag", 3)
-...
-
-6.17. db_table_acc (string)
-
-   Table name of accounting successfull calls -- database specific. It can
-   contain config variables that will be evaluated at runtime.
-
-   Default value is “acc”
-
-   Example 1.17. db_table_acc example
-...
-modparam("acc", "db_table_acc", "myacc_table")
-modparam("acc", "db_table_acc", "acc_$time(year)_$time(mon)")
-...
-
-6.18. db_table_missed_calls (string)
-
-   Table name for accounting missed calls -- database specific. It can
-   contain config variables that will be evaluated at runtime.
-
-   Default value is “missed_calls”
-
-   Example 1.18. db_table_missed_calls example
-...
-modparam("acc", "db_table_missed_calls", "myMC_table")
-...
-
-6.19. db_url (string)
-
-   SQL address -- database specific. If is set to NULL or emty string, the
-   SQL support is disabled.
-
-   Default value is “NULL” (SQL disabled).
-
-   Example 1.19. db_url example
-...
-modparam("acc", "db_url", "mysql://user:password@localhost/kamailio")
-...
-
-6.20. acc_method_column (string)
-
-   Column name in accounting table to store the request's method name as
-   string.
-
-   Default value is “method”.
-
-   Example 1.20. acc_method_column example
-...
-modparam("acc", "acc_method_column", "method")
-...
-
-6.21. acc_from_tag_column (string)
-
-   Column name in accounting table to store the From header TAG parameter.
-
-   Default value is “from_tag”.
-
-   Example 1.21. acc_from_tag_column example
-...
-modparam("acc", "acc_from_tag_column", "from_tag")
-...
-
-6.22. acc_to_tag_column (string)
-
-   Column name in accounting table to store the To header TAG parameter.
-
-   Default value is “to_tag”.
-
-   Example 1.22. acc_to_tag_column example
-...
-modparam("acc", "acc_to_tag_column", "to_tag")
-...
-
-6.23. acc_callid_column (string)
-
-   Column name in accounting table to store the request's Callid value.
-
-   Default value is “callid”.
-
-   Example 1.23. acc_callid_column example
-...
-modparam("acc", "acc_callid_column", "callid")
-...
-
-6.24. acc_sip_code_column (string)
-
-   Column name in accounting table to store the final reply's numric code
-   value in string format.
-
-   Default value is “sip_code”.
-
-   Example 1.24. acc_sip_code_column example
-...
-modparam("acc", "acc_sip_code_column", "sip_code")
-...
-
-6.25. acc_sip_reason_column (string)
-
-   Column name in accounting table to store the final reply's reason
-   phrase value.
-
-   Default value is “sip_reason”.
-
-   Example 1.25. acc_sip_reason_column example
-...
-modparam("acc", "acc_sip_reason_column", "sip_reason")
-...
-
-6.26. acc_time_column (string)
-
-   Column name in accounting table to store the time stamp of the
-   transaction completion in date-time format.
-
-   Default value is “time”.
-
-   Example 1.26. acc_time_column example
-...
-modparam("acc", "acc_time_column", "time")
-...
-
-6.27. db_extra (string)
-
-   Extra values to be logged into database - DB specific. See section
-   Section 2, “Extra accounting” for more details.
-
-   Default value is NULL.
-
-   Example 1.27. db_extra example
-...
-modparam("acc", "db_extra", "ct=$hdr(Content-type); email=$avp(s:email)")
-...
-
-6.28. db_insert_mode (integer)
-
-   If set to 1, use INSERT DELAYED to add records to accounting tables
-   when the DB driver has support for it. If no INSERT DELAYED support is
-   offered by DB driver, then standard INSERT is used. Beware that MySQL
-   InnoDB engine doesn't support INSERT DELAYED, thus be sure the acc
-   tables are defined with different type (e.g., MyISAM).
-
-   If set to 2, async insert is used if the db driver module has support
-   for it and if async_workers core parameter value is greater than 0. If
-   not, then standard INSERT is used.
-
-   Default value is 0 (no INSERT DELAYED nor async insert).
-
-   Example 1.28. db_insert_mode example
-...
-modparam("acc", "db_insert_mode", 1)
-...
-
-6.29. diameter_flag (integer)
-
-   Request flag which needs to be set to account a transaction -- DIAMETER
-   specific.
-
-   Default value is not-set (no flag).
-
-   Example 1.29. diameter_flag example
-...
-modparam("acc", "diameter_flag", 2)
-...
-
-6.30. diameter_missed_flag (integer)
-
-   Request flag which needs to be set to account missed calls -- DIAMETER
-   specific.
-
-   Default value is not-set (no flag).
-
-   Example 1.30. diameter_missed_flag example
-...
-modparam("acc", "diameter_missed_flag", 3)
-...
-
-6.31. diameter_client_host (string)
-
-   Hostname of the machine where the DIAMETER Client is running --
-   DIAMETER specific.
-
-   Default value is “localhost”.
-
-   Example 1.31. diameter_client_host example
-...
-modparam("acc", "diameter_client_host", "3a_server.net")
-...
-
-6.32. diameter_client_port (int)
-
-   Port number where the Diameter Client is listening -- DIAMETER
-   specific.
-
-   Default value is 3000.
-
-   Example 1.32. diameter_client_host example
-...
-modparam("acc", "diameter_client_port", 3000)
-...
-
-6.33. diameter_extra (string)
-
-   Extra values to be logged via DIAMETER - DIAMETER specific. See section
-   Section 2, “Extra accounting” for more details.
-
-   Default value is NULL.
-
-   Example 1.33. diameter_extra example
-...
-modparam("acc", "diameter_extra", "7846=$hdr(Content-type);7847=$avp(s:email)")
-...
-
-6.34. cdr_enable (integer)
-
-   Should CDR-based logging be enabled?
-
-   0 - off (default). 1 - on.
-
-   Example 1.34. cdr_enable example
-...
-modparam("acc", "cdr_enable", 1)
-...
-
-6.35. cdr_expired_dlg_enable (integer)
-
-   Should CDR-based logging be enabled in case of expired dialogs?
-
-   0 - off (default). 1 - on.
-
-   Example 1.35. cdr_expired_dlg_enable example
-...
-modparam("acc", "cdr_expired_dlg_enable", 1)
-...
-
-6.36. cdr_start_on_confirmed (integer)
-
-   Should the start time be taken from the time when the dialog is
-   created, or when the dialog is confirmed?
-
-   0 - use time of dialog creation (default). 1 - use time of dialog
-   confirmation.
-
-   Example 1.36. cdr_start_on_confirmed example
-...
-modparam("acc", "cdr_start_on_confirmed", 1)
-...
-
-6.37. cdr_facility (integer)
-
-   Log facility to which CDR messages are issued to syslog. This allows to
-   easily seperate CDR-specific logging from the other log messages.
-
-   Default value is LOG_DAEMON.
-
-   Example 1.37. cdr_facility example
-...
-modparam("acc", "cdr_facility", "LOG_DAEMON")
-...
-
-6.38. cdr_extra (string)
-
-   Set of pseudo-variables defining custom CDR fields. See Section 4.2,
-   “CDR Extra” for more details.
-
-   Default value is NULL.
-
-   Example 1.38. cdr_extra example
-...
-modparam("acc", "cdr_extra", "c1=$dlg_var(caller);c2=$dlg_var(callee)"
-...
-
-6.39. cdr_start_id (string)
-
-   Modifying the id which is used to store the start time.
-
-   Default value is 'start_time'
-
-   Example 1.39. cdr_start_id example
-...
-modparam("acc", "cdr_start_id", "start")
-...
-
-6.40. cdr_end_id (string)
-
-   Modifying the id which is used to store the end time.
-
-   Default value is 'end_time'
-
-   Example 1.40. cdr_end_id example
-...
-modparam("acc", "cdr_end_id", "end")
-...
-
-6.41. cdr_duration_id (string)
-
-   Modify the id which is used to store the duration.
-
-   Default value is 'duration'
-
-   Example 1.41. cdr_duration_id example
-...
-modparam("acc", "cdr_duration_id", "d")
-...
-
-6.42. cdr_log_enable (int)
-
-   Control if CDR-based accounting should be written to syslog.
-
-   0 - off. 1 - on (default).
-
-   Example 1.42. cdr_log_enable example
-...
-modparam("acc", "cdr_log_enable", 0)
-...
-
-6.43. cdrs_table (str)
-
-   Name of db table to store dialog-based CDRs.
-
-   Default value is "" (no db storage for dialog-based CDRs).
-
-   Example 1.43. cdrs_table example
-...
-modparam("acc", "cdrs_table", "acc_cdrs")
-...
-
-6.44. time_mode (int)
-
-   Store additional value related to the time of event.
-
-   Values can be:
-     * 0 - (default), save only unix timestamp for syslog and datetime for
-       database.
-     * 1 - save seconds in time_attr and microseconds in time_exten.
-     * 2 - save seconds.milliseconds in time_attr.
-     * 3 - save formatted time according to time_format parameter, using
-       the output of localtime(). Used for cdr entries too.
-     * 4 - save formatted time according to time_format parameter, using
-       the output of gmtime(). Used for cdr entries too.
-
-   Example 1.44. time_mode example
-...
-modparam("acc", "time_mode", 1)
-...
-
-6.45. time_attr (str)
-
-   Name of the syslog attribute or database column where to store
-   additional value related to the time of event.
-
-   For db accounting, the column has to be of different types, depending
-   on time_mode value. When time_mode is:
-     * 1 - time_attr column has to be int.
-     * 2 - time_attr column has to be double.
-     * 3 - time_attr column has to be varchar(128).
-     * 4 - time_attr column has to be varchar(128).
-
-   For time_mode=1, this attribute is not written in syslog, because time
-   value is already unix timestamp, but in db accounting time value is
-   datetime and requires a function to get the timestamp.
-
-   Example 1.45. time_attr example
-...
-modparam("acc", "time_attr", "seconds")
-...
-
-6.46. time_exten (str)
-
-   Name of the syslog attribute or database column where to store extended
-   value related to the time of event.
-
-   It is used now only for time_mode=1 and database column has to be int:
-
-   Example 1.46. time_exten example
-...
-modparam("acc", "time_exten", "microsecs")
-...
-
-6.47. time_format (str)
-
-   Specify the format to print the time for time_mode 3 or 4.
-
-   Default value is %Y-%m-%d %H:%M:%S".
-
-   Example 1.47. time_format example
-...
-modparam("acc", "time_format", "%Y/%m/%d %H:%M:%S")
-...
-
-6.48. reason_from_hf (int)
-
-   Tells where to take sip_reason from. If value is 0, sip_reason is taken
-   from status line. Otherwise, sip_reason is taken from Reason header
-   field(s) if present. Currently only the first Reason header is used.
-
-   Default value is 0.
-
-   Example 1.48. reason_from_hf
-...
-modparam("acc", "reason_from_hf", 1)
-...
-
-6.49. clone_msg (int)
-
-   If set to 1, request structure from transaction is cloned temporarily
-   in the callback to get acc attributes. It is required if you account
-   values from SIP headers to avoid concurent access to the shared memory
-   transaction structure, specially when accounting 1xx events. If set to
-   0, it uses directly the shared memory structure, be sure you store all
-   needed attributes in AVPs/XAVPs inside request route.
-
-   Default value is 1.
-
-   Example 1.49. clone_msg
-...
-modparam("acc", "clone_msg", 0)
-...
-
-6.50. cdr_on_failed (int)
-
-   If set to 1, the module stores the CDR for a failed dialog (calls not
-   answered). If set to 0, those records are not stored, only those for
-   answered calls.
-
-   Default value is 1.
-
-   Example 1.50. cdr_on_failed
-...
-modparam("acc", "cdr_on_failed", 0)
-...
-
-7. Functions
-
-   7.1. acc_log_request(comment)
-   7.2. acc_db_request(comment, table)
-   7.3. acc_request(comment, table)
-   7.4. acc_diam_request(comment)
-
-7.1.  acc_log_request(comment)
-
-   acc_request reports on a request, for example, it can be used to report
-   on missed calls to off-line users who are replied 404 - Not Found. To
-   avoid multiple reports on UDP request retransmission, you would need to
-   embed the action in stateful processing.
-
-   Meaning of the parameters is as follows:
-     * comment - Comment to be appended. The string can contain any number
-       of pseudo-variables.
-
-   This function can be used from ANY_ROUTE.
-
-   Example 1.51. acc_log_request usage
-...
-acc_log_request("Some comment");
-$var(code) = 404;
-$avp(reason) = "Not found";
-acc_log_request("$var(code) Error: $avp(reason)");
-...
-
-7.2.  acc_db_request(comment, table)
-
-   Like acc_log_request, acc_db_request reports on a request. The report
-   is sent to database at “db_url”, in the table referred to in the second
-   action parameter.
-
-   Meaning of the parameters is as follows:
-     * comment - Comment to be appended. The string can contain any number
-       of pseudo-variables.
-     * table - Database table to be used. It can contain config variables
-       that are evaluated at runtime.
-
-   This function can be used from ANY_ROUTE.
-
-   Example 1.52. acc_db_request usage
-...
-acc_db_request("Some comment", "SomeTable");
-acc_db_request("Some comment", "acc_$time(year)_$time(mon)");
-acc_db_request("$var(code) Error: $avp(reason)", "SomeTable");
-...
-
-7.3.  acc_request(comment, table)
-
-   Wrapper around acc_log_request and acc_db_request functions, writing
-   the accounting record to LOG and DATABASE backends. If “db_url”
-   parameter is not set, the acc record is written only to LOG backend.
-
-   Meaning of the parameters is as follows:
-     * comment - Comment to be used for generating the SIP response code
-       and text fields, if in the format “CODE TEXT”. The CODE should be a
-       valid SIP response code (100..699). The TEXT can be one or many
-       words. If CODE is missing, then 0 is used. The parameter can
-       contain pseudo-variables.
-     * table - Database table to be used. It can contain config variables
-       that are evaluated at runtime.
-
-   This function can be used from ANY_ROUTE.
-
-   Example 1.53. acc_db_request usage
-...
-acc_request("100 Received", "acc");
-acc_request("100 Received", "acc_$time(year)_$time(mon)");
-acc_db_request("$var(code) $avp(reason)", "acc");
-...
-
-7.4.  acc_diam_request(comment)
-
-   Like acc_log_request, acc_diam_request reports on a request. It reports
-   to the configured Diameter server.
-
-   Meaning of the parameters is as follows:
-     * comment - Comment to be appended. The string can contain any number
-       of pseudo-variables.
-
-   This function can be used from ANY_ROUTE.
-
-   Example 1.54. acc_diam_request usage
-...
-acc_diam_request("Some comment");
-acc_diam_request("$var(code) Error: $avp(reason)");
-...
-
-Chapter 2. Frequently Asked Questions
-
-   2.1. What happened with old log_fmt parameter
-   2.2. What happened with old multi_leg_enabled parameter
-   2.3. What happened with old src_leg_avp_id and dst_leg_avp_id
-          parameters
-
-   2.4. Where can I find more about Kamailio?
-   2.5. Where can I post a question about this module?
-   2.6. How can I report a bug?
-
-   2.1.
-
-       What happened with old log_fmt parameter
-
-       The parameter became obsolete with the restructure of the data logged
-       by ACC module (refer to the Overview chapter). For similar behaviour
-       you can use the extra accouting (see the coresponding chapter).
-
-   2.2.
-
-       What happened with old multi_leg_enabled parameter
-
-       The parameter becaome obsolete by the addition of the new
-       multi_leg_info parameter. The multi-leg accouting is automatically
-       enabled when multi_leg_info is defined.
-
-   2.3.
-
-       What happened with old src_leg_avp_id and dst_leg_avp_id parameters
-
-       The parameter was replaced by the more generic new parameter
-       multi_leg_info. This allows logging (per-leg) of more information than
-       just dst and src.
-
-   2.4.
-
-       Where can I find more about Kamailio?
-
-       Take a look at https://www.kamailio.org/.
-
-   2.5.
-
-       Where can I post a question about this module?
-
-       First at all check if your question was already answered on one of our
-       mailing lists:
-         * User Mailing List -
-           https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-         * Developer Mailing List -
-           https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
-       E-mails regarding any stable Kamailio release should be sent to
-       <[email protected]> and e-mails regarding development
-       versions should be sent to <[email protected]>.
-
-       If you want to keep the mail private, send it to
-       <[email protected]>.
-
-   2.6.
-
-       How can I report a bug?
-
-       Please follow the guidelines provided at:
-       https://github.com/kamailio/kamailio/issues.