Browse code

acc: documented acc_request() function

Daniel-Constantin Mierla authored on 09/08/2017 07:12:50
Showing 1 changed files
... ...
@@ -11,9 +11,9 @@
11 11
 <!-- Acc Module User's Guide -->
12 12
 
13 13
 <chapter>
14
-	
14
+
15 15
 	<title>&adminguide;</title>
16
-	
16
+
17 17
 	<section>
18 18
 	<title>Overview</title>
19 19
 	<para>
... ...
@@ -22,32 +22,32 @@
22 22
 		<acronym>radius</acronym> support is enabled.
23 23
 	</para>
24 24
 	<para>
25
-		There is some very early support of 
25
+		There is some very early support of
26 26
 		the <acronym>Diameter</acronym> protocol in the code which is no longer included
27 27
 		by default and will be deleted in coming releases.
28 28
 		This support is not up to date with the current Diameter protocols and
29 29
 		is disabled. If you need Diameter support, please use the <acronym>ims_charging</acronym> module.
30 30
 	</para>
31 31
 	<para>
32
-		To account a transaction and to choose which set of backends to be 
32
+		To account a transaction and to choose which set of backends to be
33 33
 		used, the script writer just has to set some flags (see the module
34 34
 		parameters section for flag definitions <xref linkend="acc.i.params"/>).
35
-		If the accounting flag for a specific backend is set, the acc module 
36
-		will then report on completed transaction. A typical usage of the 
37
-		module takes no acc-specific script command -- the functionality 
38
-		binds invisibly through transaction processing. Script writers just 
39
-		need to mark the transaction for accounting with proper setflag. 
40
-		Even so, the module allows the script writter to force accounting in 
35
+		If the accounting flag for a specific backend is set, the acc module
36
+		will then report on completed transaction. A typical usage of the
37
+		module takes no acc-specific script command -- the functionality
38
+		binds invisibly through transaction processing. Script writers just
39
+		need to mark the transaction for accounting with proper setflag.
40
+		Even so, the module allows the script writter to force accounting in
41 41
 		special cases via some script functions.
42 42
 	</para>
43 43
 	<para>
44
-		The accounting module will log by default a fixed set of attributes 
44
+		The accounting module will log by default a fixed set of attributes
45 45
 		for the transaction - if you customize your accounting by adding more
46 46
 		information to be logged, please see the next chapter about extra
47 47
 		accounting - <xref linkend="acc.i.extra-accounting"/>.
48 48
 	</para>
49 49
 	<para>
50
-		The fixed minimal accounting information is: 
50
+		The fixed minimal accounting information is:
51 51
 		<itemizedlist>
52 52
 		<listitem>
53 53
 			<para>Request Method name</para>
... ...
@@ -71,7 +71,7 @@
71 71
 			<para>Time stamp when transaction was completed</para>
72 72
 		</listitem>
73 73
 		</itemizedlist>
74
-		If a value is not present in request, the empty string is accounted 
74
+		If a value is not present in request, the empty string is accounted
75 75
 		instead.
76 76
 	</para>
77 77
 	<para>
... ...
@@ -92,10 +92,10 @@
92 92
 		</listitem>
93 93
 		<listitem>
94 94
 			<para>
95
-			If a UA fails in middle of conversation, a proxy will never 
96
-			find out about it. In general, a better practice is to account from an 
97
-			end-device (such as PSTN gateway), which best knows about call 
98
-			status (including media status and PSTN status in case of the 
95
+			If a UA fails in middle of conversation, a proxy will never
96
+			find out about it. In general, a better practice is to account from an
97
+			end-device (such as PSTN gateway), which best knows about call
98
+			status (including media status and PSTN status in case of the
99 99
 			gateway). However, CDR-base logging has the option to log existing
100 100
 			information from expired dialogs (the dlg_vars in cdr_extra)
101 101
 			Please see cdr_expired_dlg_enable parameter - <xref linkend="acc.p.cdr_expired_dlg_enable"/>.
... ...
@@ -104,16 +104,16 @@
104 104
 		</itemizedlist>
105 105
 	</para>
106 106
 	<para>
107
-		The SQL backend support is compiled in the module. For 
107
+		The SQL backend support is compiled in the module. For
108 108
 		DIAMETER you need to enable it by recompiling the module with properly
109 109
 		set defines: uncomment the DDIAM_ACC lines in
110
-		modules/acc/Makefile. 
110
+		modules/acc/Makefile.
111 111
         </para>
112 112
 	<para>
113
-		NOTE: diameter support was developed for DISC (DIameter Server Client 
114
-		project at http://developer.berlios.de/projects/disc/). This project 
113
+		NOTE: diameter support was developed for DISC (DIameter Server Client
114
+		project at http://developer.berlios.de/projects/disc/). This project
115 115
 		seems to be no longer maintained and DIAMETER specifications were updated
116
-		in the meantime. Thus, the DIAMETER part in the module is obsolete and 
116
+		in the meantime. Thus, the DIAMETER part in the module is obsolete and
117 117
 		needs rework to be usable with opendiameter or other DIAMETER servers.
118 118
 	</para>
119 119
 	<section>
... ...
@@ -147,18 +147,18 @@ if (uri=~"sip:+40") /* calls to Romania */ {
147 147
 		<section>
148 148
 			<title>Overview</title>
149 149
 			<para>
150
-			Along the static default information, ACC modules 
151
-			allows dynamical selection of extra information to be logged. 
152
-			This allows you to log any pseudo-variable (AVPs, parts of 
150
+			Along the static default information, ACC modules
151
+			allows dynamical selection of extra information to be logged.
152
+			This allows you to log any pseudo-variable (AVPs, parts of
153 153
 			the request, etc).
154 154
 			</para>
155 155
 		</section>
156 156
 		<section id="acc-def-syn">
157 157
 			<title>Definitions and syntax</title>
158 158
 			<para>
159
-			Selection of extra information is done via 
159
+			Selection of extra information is done via
160 160
 			<emphasis>xxx_extra</emphasis> parameters by specifying the names
161
-			of additional information you want to log. This information is 
161
+			of additional information you want to log. This information is
162 162
 			defined via pseudo-variables and may include headers, AVPs values
163 163
 			or other message or system values. The syntax of the parameter is:
164 164
 			</para>
... ...
@@ -172,7 +172,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
172 172
 			</itemizedlist>
173 173
 			<para>
174 174
 			The full list of supported pseudo-variables in &kamailio; is
175
-			available at: 
175
+			available at:
176 176
 			<ulink url="http://www.kamailio.org/wiki/cookbooks/devel/pseudovariables">
177 177
 			http://www.kamailio.org/wiki/cookbooks/devel/pseudovariables</ulink>
178 178
 			</para>
... ...
@@ -184,29 +184,29 @@ if (uri=~"sip:+40") /* calls to Romania */ {
184 184
 			transaction and not the AVPs setup before t_relay().
185 185
 			</para>
186 186
 			<para>
187
-			Via <emphasis>log_name</emphasis> you define how/where the 
188
-			<emphasis>data</emphasis> will be logged. Its meaning depends 
187
+			Via <emphasis>log_name</emphasis> you define how/where the
188
+			<emphasis>data</emphasis> will be logged. Its meaning depends
189 189
 			of the accounting support which is used:
190 190
 			<itemizedlist>
191 191
 				<listitem><para><emphasis>LOG accounting</emphasis> - log_name
192 192
 				will be just printed along with the data in <emphasis>
193 193
 				log_name=data</emphasis> format;
194 194
 				</para></listitem>
195
-				<listitem><para><emphasis>DB accounting</emphasis> - log_name 
196
-				will be the name of the DB column where the data will be 
197
-				stored.<emphasis>IMPORTANT</emphasis>: add in db 
198
-				<emphasis>acc</emphasis> table the columns corresponding to 
195
+				<listitem><para><emphasis>DB accounting</emphasis> - log_name
196
+				will be the name of the DB column where the data will be
197
+				stored.<emphasis>IMPORTANT</emphasis>: add in db
198
+				<emphasis>acc</emphasis> table the columns corresponding to
199 199
 				each extra data;
200 200
 				</para></listitem>
201
-				<listitem><para><emphasis>RADIUS accounting</emphasis> - 
202
-				log_name will be the AVP name used for packing the data into 
203
-				RADIUS message. The log_name will be translated to AVP number 
204
-				via the dictionary. <emphasis>IMPORTANT</emphasis>: add in 
201
+				<listitem><para><emphasis>RADIUS accounting</emphasis> -
202
+				log_name will be the AVP name used for packing the data into
203
+				RADIUS message. The log_name will be translated to AVP number
204
+				via the dictionary. <emphasis>IMPORTANT</emphasis>: add in
205 205
 				RADIUS dictionary the <emphasis>log_name</emphasis> attribute.
206 206
 				</para></listitem>
207
-				<listitem><para><emphasis>DIAMETER accounting</emphasis> - 
208
-				log_name will be the AVP code used for packing the data 
209
-				into DIAMETER message. The AVP code is given directly as 
207
+				<listitem><para><emphasis>DIAMETER accounting</emphasis> -
208
+				log_name will be the AVP code used for packing the data
209
+				into DIAMETER message. The AVP code is given directly as
210 210
 				integer, since DIAMETER has no dictionary support yet.
211 211
 				<emphasis>IMPORTANT</emphasis>:	<emphasis>log_name</emphasis>
212 212
 				must be a number.
... ...
@@ -217,7 +217,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
217 217
 		<section>
218 218
 			<title>How it works</title>
219 219
 			<para>
220
-			Some pseudo variables may return more than one value (like 
220
+			Some pseudo variables may return more than one value (like
221 221
 			headers or AVPs). In this case, the returned values are
222 222
 			embedded in a single string in a comma-separated format.
223 223
 			</para>
... ...
@@ -229,15 +229,15 @@ if (uri=~"sip:+40") /* calls to Romania */ {
229 229
 		<section>
230 230
 			<title>Overview</title>
231 231
 			<para>
232
-			A SIP call can have multiple legs due forwarding actions. For 
233
-			example user A calls user B which forwards the call to user C. 
234
-			There is only one SIP call but with 2 legs ( A to B and B to C). 
235
-			Accounting the legs of a call is required for proper billing of 
236
-			the calls (if C is a PSTN number and the call is billed, user B 
237
-			must pay for the call - as last party modifing the call 
238
-			destination-, and not A - as initiator of the call. Call 
239
-			forwarding on server is only one example which shows the 
240
-			necessity of the having an accounting engine with multiple legs 
232
+			A SIP call can have multiple legs due forwarding actions. For
233
+			example user A calls user B which forwards the call to user C.
234
+			There is only one SIP call but with 2 legs ( A to B and B to C).
235
+			Accounting the legs of a call is required for proper billing of
236
+			the calls (if C is a PSTN number and the call is billed, user B
237
+			must pay for the call - as last party modifing the call
238
+			destination-, and not A - as initiator of the call. Call
239
+			forwarding on server is only one example which shows the
240
+			necessity of the having an accounting engine with multiple legs
241 241
 			support.
242 242
 			</para>
243 243
 		</section>
... ...
@@ -247,28 +247,28 @@ if (uri=~"sip:+40") /* calls to Romania */ {
247 247
 			First how it works: The idea is to have a set of AVPs and for each
248 248
 			call leg to store a set of values in the AVPs. The meaning of
249 249
 			the AVP content is stricly decided by the script writer - it can
250
-			be the origin and source of the leg, its status or any other 
250
+			be the origin and source of the leg, its status or any other
251 251
 			related information. If you have a set of 4 AVPS (AVP1, AVP2, AVP3,
252
-			AVP4), then for the "A call B and B forwards to C" example, 
252
+			AVP4), then for the "A call B and B forwards to C" example,
253 253
 			you need to set a different set of values for the AVPs
254 254
 			for each leg ([A,B] and [B,C]) .
255
-			The script writer must take care and properly insert all 
255
+			The script writer must take care and properly insert all
256 256
 			these AVP from the script (in proper order and with the correct type).
257 257
 			</para>
258 258
 			<para>
259
-			When the accounting information for the call will be written/sent, 
259
+			When the accounting information for the call will be written/sent,
260 260
 			all the call-leg pairs will be added (based on the found AVP sets).
261 261
 			</para>
262 262
 			<para>
263 263
 			By default, the multiple call-leg support is disabled - it can be
264
-			enabled just be setting the per-leg set of AVPs via the 
264
+			enabled just be setting the per-leg set of AVPs via the
265 265
 			<varname>multi_leg_info</varname> module parameter.
266 266
 			</para>
267 267
 		</section>
268 268
 		<section>
269 269
 			<title>Logged data</title>
270 270
 			<para>
271
-			For each call, all the values of the AVP set (which defines a 
271
+			For each call, all the values of the AVP set (which defines a
272 272
 			call-leg) will be logged. How the information will be actually
273 273
 			logged, depends of the data backend:
274 274
 			</para>
... ...
@@ -279,9 +279,9 @@ if (uri=~"sip:+40") /* calls to Romania */ {
279 279
 				</para>
280 280
 				</listitem>
281 281
 				<listitem>
282
-				<para><emphasis>database</emphasis> -- each pair will be 
282
+				<para><emphasis>database</emphasis> -- each pair will be
283 283
 				separately logged (due DB data structure constraints); several
284
-				records will be written, the difference between them being 
284
+				records will be written, the difference between them being
285 285
 				only the fields corresponding to the call-leg info.
286 286
 				</para>
287 287
 				<note><para>You will need to add in your DB (all acc related
... ...
@@ -293,7 +293,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
293 293
 				<para><emphasis>Radius</emphasis> -- all sets will be added
294 294
 				to the same Radius accounting message as RADIUS AVPs - for each
295 295
 				call-leg a set of RADIUS AVPs will be added (corresponding
296
-				to the per-leg AVP set). Note that Radius support is in a 
296
+				to the per-leg AVP set). Note that Radius support is in a
297 297
 				separate module - acc_radius.
298 298
 				</para>
299 299
 				<note><para>You will need to add in your dictionary the
... ...
@@ -376,8 +376,8 @@ if (uri=~"sip:+40") /* calls to Romania */ {
376 376
 				<para>
377 377
 				As mentioned in <xref linkend="acc.i.multi-call-legs"/>, a leg represents a parallel
378 378
 				or forwarded call. In contrast to the normal accounting the cdr logging uses dialogs
379
-				instead of transaction to log data. This may reduce the amount of information 
380
-				but it also make it possible to combine all important data in one cdr at 
379
+				instead of transaction to log data. This may reduce the amount of information
380
+				but it also make it possible to combine all important data in one cdr at
381 381
 				once. A second mechanism to process multiple data-sets into one cdr is not further
382 382
 				necessary.
383 383
 				</para>
... ...
@@ -438,18 +438,18 @@ $dlg_var(callee) = $avp(callee); #callee='C'
438 438
 		<section>
439 439
 			<title>&kamailio; Modules</title>
440 440
 			<para>
441
-			The module depends on the following modules (in the other words 
441
+			The module depends on the following modules (in the other words
442 442
 			the listed modules must be loaded before this module):
443 443
 			<itemizedlist>
444 444
 				<listitem>
445 445
 				<para><emphasis>tm</emphasis> -- Transaction Manager</para>
446 446
 				</listitem>
447 447
 				<listitem>
448
-				<para><emphasis>a database module</emphasis> -- If SQL 
448
+				<para><emphasis>a database module</emphasis> -- If SQL
449 449
 				support is used.</para>
450 450
 				</listitem>
451 451
 				<listitem>
452
-				<para><emphasis>rr</emphasis> -- Record Route, if 
452
+				<para><emphasis>rr</emphasis> -- Record Route, if
453 453
 				<quote>detect_direction</quote> module parameter is enabled.
454 454
 				</para>
455 455
 				</listitem>
... ...
@@ -464,7 +464,7 @@ $dlg_var(callee) = $avp(callee); #callee='C'
464 464
 		<section>
465 465
 			<title>External Libraries or Applications</title>
466 466
 			<para>
467
-			The following libraries or applications must be installed 
467
+			The following libraries or applications must be installed
468 468
 			before running &kamailio; with this module loaded:
469 469
 			</para>
470 470
 			<itemizedlist>
... ...
@@ -498,7 +498,7 @@ modparam("acc", "early_media", 1)
498 498
 	<section id="acc.p.failed_transaction_flag">
499 499
 		<title><varname>failed_transaction_flag</varname> (integer)</title>
500 500
 		<para>
501
-		Per transaction flag which says if the transaction should be 
501
+		Per transaction flag which says if the transaction should be
502 502
 		accounted also in case of failure (status>=300).
503 503
 		</para>
504 504
 		<para>
... ...
@@ -519,7 +519,7 @@ modparam("acc", "failed_transaction_flag", 4)
519 519
 		A string of failure response codes from 300 to 999
520 520
 		separated by commas. Failed transaction will not be accounted
521 521
 		if its response code is in the list even when
522
-		failed_transaction_flag is set. 
522
+		failed_transaction_flag is set.
523 523
 		</para>
524 524
 		<para>
525 525
 		Default value is not-set (failure filtering is off).
... ...
@@ -536,9 +536,9 @@ modparam("acc", "failed_filter", "404,407")
536 536
 	<section id="acc.p.report_ack">
537 537
 		<title><varname>report_ack</varname> (integer)</title>
538 538
 		<para>
539
-		Shall acc attempt to account e2e ACKs too ? Note that this is really 
540
-		only an attempt, as e2e ACKs may take a different path 
541
-		(unless RR enabled) and mismatch original INVITE (e2e ACKs are 
539
+		Shall acc attempt to account e2e ACKs too ? Note that this is really
540
+		only an attempt, as e2e ACKs may take a different path
541
+		(unless RR enabled) and mismatch original INVITE (e2e ACKs are
542 542
 		a separate transaction). The flag for accounting has to be set
543 543
 		for each ACK as well.
544 544
 		</para>
... ...
@@ -576,13 +576,13 @@ modparam("acc", "report_cancels", 1)
576 576
 	<section id="acc.p.detect_direction">
577 577
 		<title><varname>detect_direction</varname> (integer)</title>
578 578
 		<para>
579
-		Controlles the direction detection for sequential requests. If 
579
+		Controlles the direction detection for sequential requests. If
580 580
 		enabled (non zero value), for sequential requests with upstream
581 581
 		direction (from callee to caller), the FROM and TO will be swapped
582 582
 		(the direction will be preserved as in the original request).
583 583
 		</para>
584 584
 		<para>
585
-		It affects all values related to TO and FROM headers (body, URI, 
585
+		It affects all values related to TO and FROM headers (body, URI,
586 586
 		username, domain, TAG).
587 587
 		</para>
588 588
 		<para>
... ...
@@ -640,7 +640,7 @@ modparam("acc", "acc_prepare_always", 1)
640 640
 		<title><varname>multi_leg_info</varname> (string)</title>
641 641
 		<para>
642 642
 		Defines the AVP set to be used in per-call-leg accounting.
643
-		See <xref linkend="acc.i.multi-call-legs"/> for a 
643
+		See <xref linkend="acc.i.multi-call-legs"/> for a
644 644
 		detailed description of the Multi Call-Legs accounting.
645 645
 		</para>
646 646
 		<para>
... ...
@@ -759,7 +759,7 @@ modparam("acc", "log_extra", "ua=$hdr(User-Agent);uuid=$avp(i:123)")
759 759
 	<section id="acc.p.db_flag">
760 760
 		<title><varname>db_flag</varname> (integer)</title>
761 761
 		<para>
762
-		Request flag which needs to be set to account a 
762
+		Request flag which needs to be set to account a
763 763
 		transaction -- database specific.
764 764
 		</para>
765 765
 		<para>
... ...
@@ -777,7 +777,7 @@ modparam("acc", "db_flag", 2)
777 777
 	<section id="acc.p.db_missed_flag">
778 778
 		<title><varname>db_missed_flag</varname> (integer)</title>
779 779
 		<para>
780
-		Request flag which needs to be set to account missed 
780
+		Request flag which needs to be set to account missed
781 781
 		calls -- database specific.
782 782
 		</para>
783 783
 		<para>
... ...
@@ -955,7 +955,7 @@ modparam("acc", "acc_sip_reason_column", "sip_reason")
955 955
 	<section id="acc.p.acc_time_column">
956 956
 		<title><varname>acc_time_column</varname> (string)</title>
957 957
 		<para>
958
-		Column name in accounting table to store the time stamp of the 
958
+		Column name in accounting table to store the time stamp of the
959 959
 		transaction completion in date-time format.
960 960
 		</para>
961 961
 		<para>
... ...
@@ -999,7 +999,8 @@ modparam("acc", "db_extra", "ct=$hdr(Content-type); email=$avp(s:email)")
999 999
 		</para>
1000 1000
 		<para>
1001 1001
 		If set to 2, async insert is used if the db driver module has
1002
-		support for it and if async_workers core parameter value is greater than 0. If not, then standard INSERT is used.
1002
+		support for it and if async_workers core parameter value is greater
1003
+		than 0. If not, then standard INSERT is used.
1003 1004
 		</para>
1004 1005
 		<para>
1005 1006
 		Default value is 0 (no INSERT DELAYED nor async insert).
... ...
@@ -1017,7 +1018,7 @@ modparam("acc", "db_insert_mode", 1)
1017 1018
 	<section id="acc.p.diameter_flag">
1018 1019
 		<title><varname>diameter_flag</varname> (integer)</title>
1019 1020
 		<para>
1020
-		Request flag which needs to be set to account a 
1021
+		Request flag which needs to be set to account a
1021 1022
 		transaction -- DIAMETER specific.
1022 1023
 		</para>
1023 1024
 		<para>
... ...
@@ -1035,7 +1036,7 @@ modparam("acc", "diameter_flag", 2)
1035 1036
 	<section id="acc.p.diameter_missed_flag">
1036 1037
 		<title><varname>diameter_missed_flag</varname> (integer)</title>
1037 1038
 		<para>
1038
-		Request flag which needs to be set to account missed 
1039
+		Request flag which needs to be set to account missed
1039 1040
 		calls -- DIAMETER specific.
1040 1041
 		</para>
1041 1042
 		<para>
... ...
@@ -1053,7 +1054,7 @@ modparam("acc", "diameter_missed_flag", 3)
1053 1054
 	<section id="acc.p.diameter_client_host">
1054 1055
 		<title><varname>diameter_client_host</varname> (string)</title>
1055 1056
 		<para>
1056
-		Hostname of the machine where the DIAMETER Client is 
1057
+		Hostname of the machine where the DIAMETER Client is
1057 1058
 		running -- DIAMETER specific.
1058 1059
 		</para>
1059 1060
 		<para>
... ...
@@ -1071,7 +1072,7 @@ modparam("acc", "diameter_client_host", "3a_server.net")
1071 1072
 	<section id="acc.p.diameter_client_port">
1072 1073
 		<title><varname>diameter_client_port</varname> (int)</title>
1073 1074
 		<para>
1074
-		Port number where the Diameter Client is 
1075
+		Port number where the Diameter Client is
1075 1076
 		listening -- DIAMETER specific.
1076 1077
 		</para>
1077 1078
 		<para>
... ...
@@ -1467,12 +1468,12 @@ modparam("acc", "cdr_on_failed", 0)
1467 1468
 			<function moreinfo="none">acc_log_request(comment)</function>
1468 1469
 		</title>
1469 1470
 		<para>
1470
-		<function moreinfo="none">acc_request</function> reports on a request, 
1471
-		for example, it can be used to report on missed calls to off-line users 
1472
-		who are replied 404 - Not Found. To avoid multiple reports on UDP 
1471
+		<function moreinfo="none">acc_request</function> reports on a request,
1472
+		for example, it can be used to report on missed calls to off-line users
1473
+		who are replied 404 - Not Found. To avoid multiple reports on UDP
1473 1474
 		request retransmission, you would need to embed the
1474 1475
 		action in stateful processing.
1475
-		</para> 
1476
+		</para>
1476 1477
 		<para>
1477 1478
 		Meaning of the parameters is as follows:</para>
1478 1479
 		<itemizedlist>
... ...
@@ -1502,9 +1503,9 @@ acc_log_request("$var(code) Error: $avp(reason)");
1502 1503
 			<function moreinfo="none">acc_db_request(comment, table)</function>
1503 1504
 		</title>
1504 1505
 		<para>
1505
-		Like <function moreinfo="none">acc_log_request</function>, 
1506
-		<function moreinfo="none">acc_db_request</function> reports on a 
1507
-		request. The report is sent to database at <quote>db_url</quote>, in 
1506
+		Like <function moreinfo="none">acc_log_request</function>,
1507
+		<function moreinfo="none">acc_db_request</function> reports on a
1508
+		request. The report is sent to database at <quote>db_url</quote>, in
1508 1509
 		the table referred to in the second action parameter.
1509 1510
 		</para>
1510 1511
 		<para>
... ...
@@ -1532,6 +1533,49 @@ acc_db_request("Some comment", "SomeTable");
1532 1533
 acc_db_request("Some comment", "acc_$time(year)_$time(mon)");
1533 1534
 acc_db_request("$var(code) Error: $avp(reason)", "SomeTable");
1534 1535
 ...
1536
+</programlisting>
1537
+		</example>
1538
+	</section>
1539
+	<section id="acc.f.acc_request">
1540
+		<title>
1541
+			<function moreinfo="none">acc_request(comment, table)</function>
1542
+		</title>
1543
+		<para>
1544
+		Warapper around <function moreinfo="none">acc_log_request</function>
1545
+		and <function moreinfo="none">acc_db_request</function> functions,
1546
+		writing the accounting record to LOG and DATABASE backends. If
1547
+		<quote>db_url</quote> parameter is not set, the acc record is written
1548
+		only to LOG backend.
1549
+		</para>
1550
+		<para>
1551
+		Meaning of the parameters is as follows:
1552
+		</para>
1553
+		<itemizedlist>
1554
+		<listitem>
1555
+			<para><emphasis>comment</emphasis> - Comment to be used for
1556
+			generating the SIP response code and text fields, if in the
1557
+			format <quote>CODE TEXT</quote>. The CODE should be a valid
1558
+			SIP response code (100..699). The TEXT can be one or many words.
1559
+			If CODE is missing, then 0 is used.
1560
+			The parameter can contain pseudo-variables.
1561
+			</para>
1562
+		</listitem>
1563
+		<listitem>
1564
+			<para><emphasis>table</emphasis> - Database table to be used. It
1565
+			can contain config variables that are evaluated at runtime.</para>
1566
+		</listitem>
1567
+		</itemizedlist>
1568
+		<para>
1569
+		This function can be used from ANY_ROUTE.
1570
+		</para>
1571
+		<example>
1572
+		<title>acc_db_request usage</title>
1573
+		<programlisting format="linespecific">
1574
+...
1575
+acc_request("100 Received", "acc");
1576
+acc_request("100 Received", "acc_$time(year)_$time(mon)");
1577
+acc_db_request("$var(code) $avp(reason)", "acc");
1578
+...
1535 1579
 </programlisting>
1536 1580
 		</example>
1537 1581
 	</section>
... ...
@@ -1540,10 +1584,10 @@ acc_db_request("$var(code) Error: $avp(reason)", "SomeTable");
1540 1584
 			<function moreinfo="none">acc_diam_request(comment)</function>
1541 1585
 		</title>
1542 1586
 		<para>
1543
-		Like <function moreinfo="none">acc_log_request</function>, 
1544
-		<function moreinfo="none">acc_diam_request</function> reports on 
1587
+		Like <function moreinfo="none">acc_log_request</function>,
1588
+		<function moreinfo="none">acc_diam_request</function> reports on
1545 1589
 		a request. It reports to the configured Diameter server.
1546
-		</para> 
1590
+		</para>
1547 1591
 		<para>
1548 1592
 		Meaning of the parameters is as follows:</para>
1549 1593
 		<itemizedlist>