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

src/modules/acc/README

@@ -1,2 +1,1518 @@
+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_extra_nullable (integer)
+              6.40. cdr_start_id (string)
+              6.41. cdr_end_id (string)
+              6.42. cdr_duration_id (string)
+              6.43. cdr_log_enable (int)
+              6.44. cdrs_table (str)
+              6.45. time_mode (int)
+              6.46. time_attr (str)
+              6.47. time_exten (str)
+              6.48. time_format (str)
+              6.49. reason_from_hf (int)
+              6.50. clone_msg (int)
+              6.51. 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_extra_nullable example
+   1.40. cdr_start_id example
+   1.41. cdr_end_id example
+   1.42. cdr_duration_id example
+   1.43. cdr_log_enable example
+   1.44. cdrs_table example
+   1.45. time_mode example
+   1.46. time_attr example
+   1.47. time_exten example
+   1.48. time_format example
+   1.49. reason_from_hf
+   1.50. clone_msg
+   1.51. cdr_on_failed
+   1.52. acc_log_request usage
+   1.53. acc_db_request usage
+   1.54. acc_db_request usage
+   1.55. 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_extra_nullable (integer)
+        6.40. cdr_start_id (string)
+        6.41. cdr_end_id (string)
+        6.42. cdr_duration_id (string)
+        6.43. cdr_log_enable (int)
+        6.44. cdrs_table (str)
+        6.45. time_mode (int)
+        6.46. time_attr (str)
+        6.47. time_exten (str)
+        6.48. time_format (str)
+        6.49. reason_from_hf (int)
+        6.50. clone_msg (int)
+        6.51. 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_extra_nullable (integer)
+   6.40. cdr_start_id (string)
+   6.41. cdr_end_id (string)
+   6.42. cdr_duration_id (string)
+   6.43. cdr_log_enable (int)
+   6.44. cdrs_table (str)
+   6.45. time_mode (int)
+   6.46. time_attr (str)
+   6.47. time_exten (str)
+   6.48. time_format (str)
+   6.49. reason_from_hf (int)
+   6.50. clone_msg (int)
+   6.51. 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_extra_nullable (integer)
+
+   Should custom CDR fields be saved as NULL?
+
+   If set to 0, custom CDR fields not defined in config operation (or set
+   to $null) will be saved as empty string. If set to 1, custom CDR fields
+   not defined in config operation (or set to $null) will be saved as
+   NULL.
+
+   Default value is 0.
+
+   Example 1.39. cdr_extra_nullable example
+...
+modparam("acc", "cdr_extra_nullable", 1)
+...
+
+6.40. cdr_start_id (string)
+
+   Modifying the id which is used to store the start time.
+
+   Default value is 'start_time'
+
+   Example 1.40. cdr_start_id example
+...
+modparam("acc", "cdr_start_id", "start")
+...
+
+6.41. cdr_end_id (string)
+
+   Modifying the id which is used to store the end time.
+
+   Default value is 'end_time'
+
+   Example 1.41. cdr_end_id example
+...
+modparam("acc", "cdr_end_id", "end")
+...
+
+6.42. cdr_duration_id (string)
+
+   Modify the id which is used to store the duration.
+
+   Default value is 'duration'
+
+   Example 1.42. cdr_duration_id example
+...
+modparam("acc", "cdr_duration_id", "d")
+...
+
+6.43. cdr_log_enable (int)
+
+   Control if CDR-based accounting should be written to syslog.
+
+   0 - off. 1 - on (default).
+
+   Example 1.43. cdr_log_enable example
+...
+modparam("acc", "cdr_log_enable", 0)
+...
+
+6.44. cdrs_table (str)
+
+   Name of db table to store dialog-based CDRs.
+
+   Default value is "" (no db storage for dialog-based CDRs).
+
+   Example 1.44. cdrs_table example
+...
+modparam("acc", "cdrs_table", "acc_cdrs")
+...
+
+6.45. 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.45. time_mode example
+...
+modparam("acc", "time_mode", 1)
+...
+
+6.46. 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.46. time_attr example
+...
+modparam("acc", "time_attr", "seconds")
+...
+
+6.47. 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.47. time_exten example
+...
+modparam("acc", "time_exten", "microsecs")
+...
+
+6.48. 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.48. time_format example
+...
+modparam("acc", "time_format", "%Y/%m/%d %H:%M:%S")
+...
+
+6.49. 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.49. reason_from_hf
+...
+modparam("acc", "reason_from_hf", 1)
+...
+
+6.50. 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.50. clone_msg
+...
+modparam("acc", "clone_msg", 0)
+...
+
+6.51. 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.51. 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.52. 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.53. 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.54. 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.55. 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.