Browse code

acc: Fix typos in module documentation

Florian Floimair authored on 26/02/2018 19:00:08 • Daniel-Constantin Mierla committed on 28/02/2018 17:00:48
Showing 2 changed files
... ...
@@ -234,7 +234,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
234 234
 			There is only one SIP call but with 2 legs ( A to B and B to C).
235 235
 			Accounting the legs of a call is required for proper billing of
236 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
237
+			must pay for the call - as last party modifying the call
238 238
 			destination-, and not A - as initiator of the call. Call
239 239
 			forwarding on server is only one example which shows the
240 240
 			necessity of the having an accounting engine with multiple legs
... ...
@@ -246,7 +246,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
246 246
 			<para>
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
-			the AVP content is stricly decided by the script writer - it can
249
+			the AVP content is strictly decided by the script writer - it can
250 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 252
 			AVP4), then for the "A call B and B forwards to C" example,
... ...
@@ -285,7 +285,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
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
288
-				tables) the colums for call-leg info (a column for each AVP
288
+				tables) the columns for call-leg info (a column for each AVP
289 289
 				of the set).
290 290
 				</para></note>
291 291
 				</listitem>
... ...
@@ -395,7 +395,7 @@ if (uri=~"sip:+40") /* calls to Romania */ {
395 395
 				corresponding caller and callee in a dialog based pseudo-variable (dlg_var)
396 396
 				(e.g. chain=B;cfa;C|C;cfnr;D). Additionally it is necessary to store the
397 397
 				caller and callee for each leg. All this helps to identify the involved
398
-				phone parners and forwarding chain. When you route such calls multiple times
398
+				phone partners and forwarding chain. When you route such calls multiple times
399 399
 				to the same Proxy, you could store the caller and callee within an transaction
400 400
 				based avp and write it into the dialog based dlg_var pv during a 200 INVITE.
401 401
 				</para>
... ...
@@ -576,7 +576,7 @@ 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
+		Controls 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).
... ...
@@ -722,7 +722,7 @@ modparam("acc", "log_level", 2)   # Set log_level to 2 (L_INFO)
722 722
 		<title><varname>log_facility</varname> (string)</title>
723 723
 		<para>
724 724
 		Log facility to which accounting messages are issued to syslog.
725
-		This allows to easily seperate the accounting specific logging
725
+		This allows to easily separate the accounting specific logging
726 726
 		from the other log messages.
727 727
 		</para>
728 728
 		<para>
... ...
@@ -795,7 +795,7 @@ modparam("acc", "db_missed_flag", 3)
795 795
 	<section  id="acc.p.db_table_acc">
796 796
 		<title><varname>db_table_acc</varname> (string)</title>
797 797
 		<para>
798
-		Table name of accounting successfull calls -- database specific. It
798
+		Table name of accounting successful calls -- database specific. It
799 799
 		can contain config variables that will be evaluated at runtime.
800 800
 		</para>
801 801
 		<para>
... ...
@@ -832,7 +832,7 @@ modparam("acc", "db_table_missed_calls", "myMC_table")
832 832
 	<section id="acc.p.db_url">
833 833
 		<title><varname>db_url</varname> (string)</title>
834 834
 		<para>
835
-		SQL address -- database specific. If is set to NULL or emty string,
835
+		SQL address -- database specific. If is set to NULL or empty string,
836 836
 		the SQL support is disabled.
837 837
 		</para>
838 838
 		<para>
... ...
@@ -919,7 +919,7 @@ modparam("acc", "acc_callid_column", "callid")
919 919
 	<section id="acc.p.acc_sip_code_column">
920 920
 		<title><varname>acc_sip_code_column</varname> (string)</title>
921 921
 		<para>
922
-		Column name in accounting table to store the final reply's numric code
922
+		Column name in accounting table to store the final reply's numeric code
923 923
 		value in string format.
924 924
 		</para>
925 925
 		<para>
... ...
@@ -1444,7 +1444,7 @@ modparam("acc", "reason_from_hf", 1)
1444 1444
 		<para>
1445 1445
 		If set to 1, request structure from transaction is cloned temporarily
1446 1446
 		in the callback to get acc attributes. It is required if you account
1447
-		values from SIP headers to avoid concurent access to the shared memory
1447
+		values from SIP headers to avoid concurrent access to the shared memory
1448 1448
 		transaction structure, specially when accounting 1xx events. If set to
1449 1449
 		0, it uses directly the shared memory structure, be sure you store all
1450 1450
 		needed attributes in AVPs/XAVPs inside request route.
... ...
@@ -23,7 +23,7 @@
23 23
 		<para>
24 24
 			The parameter became obsolete with the restructure of the data
25 25
 			logged by ACC module (refer to the Overview chapter). For similar
26
-			behaviour you can use the extra accouting (see the coresponding
26
+			behaviour you can use the extra accounting (see the corresponding
27 27
 			chapter).
28 28
 		</para>
29 29
 		</answer>
... ...
@@ -35,8 +35,8 @@
35 35
 		</question>
36 36
 		<answer>
37 37
 		<para>
38
-			The parameter becaome obsolete by the addition of the new
39
-			multi_leg_info parameter. The multi-leg accouting is automatically
38
+			The parameter became obsolete by the addition of the new
39
+			multi_leg_info parameter. The multi-leg accounting is automatically
40 40
 			enabled when multi_leg_info is defined.
41 41
 			</para>
42 42
 		</answer>