Browse code

spell-checked using aspell.

Jan Janak authored on 29/09/2002 10:33:51
Showing 1 changed files
... ...
@@ -90,7 +90,7 @@
90 90
 	    <title>Installation Of New Signal Handlers</title>
91 91
 	    <para>
92 92
 		The first step in the initialization process is the installation of new signal handlers. We need
93
-		our own signal handlers to be able to do gracefull shutdown, print server statistics and so on. There is
93
+		our own signal handlers to be able to do graceful shutdown, print server statistics and so on. There is
94 94
 		only one signal handler function which is function <function moreinfo="none">sig_usr</function> in
95 95
 		file <filename moreinfo="none">main.c</filename>.
96 96
 	    </para>
... ...
@@ -131,7 +131,7 @@
131 131
 	<section id="malloc-init">
132 132
 	    <title>Malloc Initialization</title>
133 133
 	    <para>
134
-		To make <acronym>SER</acronym> even faster we decided to reimplement memory allocation routines. The new 
134
+		To make <acronym>SER</acronym> even faster we decided to re-implement memory allocation routines. The new 
135 135
 		<function moreinfo="none">malloc</function>
136 136
 		better fits our needs and speeds up the server a lot. The memory management subsystem needs
137 137
 		to be initialized upon server startup. The initialization mainly creates internal data
... ...
@@ -166,7 +166,7 @@
166 166
 	    <para>
167 167
 		<acronym>SER</acronym> has built-in support for <acronym>FIFO</acronym> control. It means that the 
168 168
 		running server can accept
169
-		commands over a fifo special file (a named pipe). Function <function moreinfo="none">register_core_fifo</function> 
169
+		commands over a FIFO special file (a named pipe). Function <function moreinfo="none">register_core_fifo</function> 
170 170
 		initializes <acronym>FIFO</acronym> subsystem and registers basic commands, that are processed by the core
171 171
 		itself. The function can be found in file <filename moreinfo="none">fifo_server.c</filename>.
172 172
 	    </para>
... ...
@@ -186,10 +186,10 @@
186 186
 			parameters are offered by the module.
187 187
 		    </para>
188 188
 		</footnote>
189
-		immediatelly with the 
189
+		immediately with the 
190 190
 		core. When the module is compiled in statically, the registration<footnoteref linkend="regfoot"> 
191 191
 		must be performed during the server startup. Function 
192
-		<function moreinfo="none">register_buildin_modules</function> does the job.
192
+		<function moreinfo="none">register_builtin_modules</function> does the job.
193 193
 	    </para>
194 194
 	</section> <!-- builtin-mod-reg -->
195 195
 
... ...
@@ -287,7 +287,7 @@
287 287
 			    at the beginning
288 288
 			    of the main <quote>route</quote> statement. Additional <quote>route</quote> statements can be 
289 289
 			    called from the main
290
-			    one or another additional <quote>route</quote> statements (It it simmilar to function calling).
290
+			    one or another additional <quote>route</quote> statements (It it similar to function calling).
291 291
 			</para>
292 292
 		    </listitem>
293 293
 		    <listitem>
... ...
@@ -300,7 +300,7 @@
300 300
 		    </listitem>
301 301
 		    <listitem>
302 302
 			<para>
303
-			    <emphasis>Module Statement</emphasis> - Additional funcionality of the server is 
303
+			    <emphasis>Module Statement</emphasis> - Additional functionality of the server is 
304 304
 			    available through separate
305 305
 			    modules. Each module is a shared object that can be loaded at runtime. Modules can
306 306
 			    export functions, that can be called from the configuration file and variables, that
... ...
@@ -474,7 +474,7 @@ module_stm = "loadmodule" STRING
474 474
 			statement in curly braces.
475 475
 			The statement will call <function moreinfo="none">load_module</function> function.
476 476
 			The function will load the specified filename using <function moreinfo="none">dlopen</function>.
477
-			If <function moreinfo="none">dlopen</function> was successfull, the server will look for
477
+			If <function moreinfo="none">dlopen</function> was successful, the server will look for
478 478
 			<structname>exports</structname> structure describing the module's interface and register the 
479 479
 			module. For more details see <link linkend="module-interface">module section</link>.
480 480
 		    </para>
... ...
@@ -518,7 +518,7 @@ module_stm = "loadmodule" STRING
518 518
 	    <itemizedlist>
519 519
 		<listitem>
520 520
 		    <para>
521
-			<emphasis>chroot</emphasis> is performed if neccessary. That ensures that the server will have
521
+			<emphasis>chroot</emphasis> is performed if necessary. That ensures that the server will have
522 522
 			access to a particular directory and its subdirectories only.
523 523
 		    </para>
524 524
 		</listitem>
... ...
@@ -592,7 +592,7 @@ module_stm = "loadmodule" STRING
592 592
 		append a new header field after the last one. In this case, the function needs to know length 
593 593
 		of the string parameter. It could call <function moreinfo="none">strlen</function> every time it is
594 594
 		called, but that is not a very good idea because <function moreinfo="none">strlen</function> would
595
-		be called every time a message is processed and that is not neccessary.
595
+		be called every time a message is processed and that is not necessary.
596 596
 	    </para>
597 597
 	    <para>
598 598
 		Instead of that the length of the string parameter could be precalculated upon server startup, saved
... ...
@@ -641,7 +641,7 @@ module_stm = "loadmodule" STRING
641 641
 	    <para>
642 642
 		The rest of the initialization process depends on value of <varname>dont_fork</varname> variable. 
643 643
 		<varname>dont_fork</varname> is a global variable defined in <filename moreinfo="none">main.c</filename>.
644
-		We will describe both variants separatelly.
644
+		We will describe both variants separately.
645 645
 	    </para>
646 646
 
647 647
 	    <section id="dont-fork-set">
... ...
@@ -649,7 +649,7 @@ module_stm = "loadmodule" STRING
649 649
 		<para>
650 650
 		    If <varname>dont_fork</varname> variable is set, the server will be operating in special mode. 
651 651
 		    There will be only one process processing incoming requests. This is very slow and was intended mainly 
652
-		    for debugging purposes. The main process will be proccessing all incoming requests itself.
652
+		    for debugging purposes. The main process will be processing all incoming requests itself.
653 653
 		</para>
654 654
 		<para>
655 655
 		    The server still needs additional children:
... ...
@@ -664,7 +664,7 @@ module_stm = "loadmodule" STRING
664 664
 		    <listitem>
665 665
 			<para>
666 666
 			    <acronym>FIFO</acronym> server will spawn another child if enabled. The child will be 
667
-			    processing all commands comming through the fifo interface.
667
+			    processing all commands coming through the fifo interface.
668 668
 			</para>
669 669
 		    </listitem>
670 670
 		    <listitem>
... ...
@@ -699,7 +699,7 @@ module_stm = "loadmodule" STRING
699 699
 			</para>
700 700
 			<para>
701 701
 			    If there is anything, that needs to be initialized in every child separately (for example
702
-			    if each child needs to open its own filedescriptor), it cannot be done in 
702
+			    if each child needs to open its own file descriptor), it cannot be done in 
703 703
 			    <function>mod_init</function>.
704 704
 			    To make such initialization possible, a module can export another initialization function
705 705
 			    called <function moreinfo="none">init_child</function>. The function will be called in
... ...
@@ -732,7 +732,7 @@ module_stm = "loadmodule" STRING
732 732
 		<title><varname>dont_fork</varname> is not set (zero)</title>
733 733
 		<para>
734 734
 		    <varname>dont_fork</varname> is not set. That means that the server will fork children and the children
735
-		    will be processing incoming requests. How many childrens will be created depends on
735
+		    will be processing incoming requests. How many children will be created depends on
736 736
 		    the configuration (<varname>children</varname> variable). The main process will be sleeping and 
737 737
 		    handling signals only.
738 738
 		</para>
... ...
@@ -744,12 +744,12 @@ module_stm = "loadmodule" STRING
744 744
 		</para>
745 745
 
746 746
 		<para>
747
-		    Then the main process will perform another fork for the timer attendand. The child will
747
+		    Then the main process will perform another fork for the timer attendant. The child will
748 748
 		    take care of timer lists and execute specified function when a timer hits.
749 749
 		</para>
750 750
 		<para>
751 751
 		    The main process is now completely initialized, it will sleep in <function moreinfo="none">pause</function>
752
-		    function untill a signal comes and call <function moreinfo="none">handle_sigs</function> when such
752
+		    function until a signal comes and call <function moreinfo="none">handle_sigs</function> when such
753 753
 		    condition occurs.
754 754
 		</para>
755 755
 		
... ...
@@ -761,10 +761,10 @@ module_stm = "loadmodule" STRING
761 761
 		    will sequentially call <function moreinfo="none">child_init</function> functions of all loaded modules.
762 762
 		</para>
763 763
 		<para>
764
-		    Becuase the function is called in each child separately, it can initialize per-child
764
+		    Because the function is called in each child separately, it can initialize per-child
765 765
 		    specific data. For example if a module needs to communicate with database, it must open
766 766
 		    a database connection. If the connection would be opened in <function moreinfo="none">mod_init</function>
767
-		    function, all the children would share the same connection and locking would be neccessary
767
+		    function, all the children would share the same connection and locking would be necessary
768 768
 		    to avoid conflicts. On the other hand if the connection was opened in
769 769
 		    <function moreinfo="none">child_init</function> function, each child will have its own
770 770
 		    connection and concurrency conflicts will be handled by the database server.
... ...
@@ -843,7 +843,7 @@ module_stm = "loadmodule" STRING
843 843
 		    <para>
844 844
 			A module may register callbacks. Each callback have associated an event, that
845 845
 			will trigger the callback. One such callback is <emphasis>pre-script</emphasis> callback. Such
846
-			callback will be called immediatelly before the routing part of the config file will be executed. 
846
+			callback will be called immediately before the routing part of the config file will be executed. 
847 847
 			If there are such callbacks registered, they will be executed now.
848 848
 		    </para>
849 849
 		</listitem>
... ...
@@ -851,7 +851,7 @@ module_stm = "loadmodule" STRING
851 851
 		    <para>
852 852
 			As the next step we will determine type of the message. If the message being processed is a REQUEST
853 853
 			then basic sanity checks will be performed (make sure that there is the first Via and parsing was
854
-			successfull) and the message will be passed to routing engine.
854
+			successful) and the message will be passed to routing engine.
855 855
 			The routing engine is one of the most complicated parts of the server and will be in detail
856 856
 			described in chapter <link linkend="routing-engine">The Routing Engine</link>.
857 857
 		    </para>
... ...
@@ -925,13 +925,13 @@ module_stm = "loadmodule" STRING
925 925
 	<para>
926 926
 	    When <varname>dont_fork</varname> is set, all the cleanup will be done directly from the signal handler, 
927 927
 	    because there is only one process - the main process. This is not so safe as the previous case, but this mode 
928
-	    should be  used for debugging only and such shortcomming doesn't harm in that case.
928
+	    should be  used for debugging only and such shortcoming doesn't harm in that case.
929 929
 	</para>
930 930
 	<para>
931 931
 	    Upon receipt of SIGINT, SIGPIPE or SIGTERM <function moreinfo="none">destroy_modules</function> will be called.
932 932
 	    Each module may register so-called <function moreinfo="none">destroy</function> function if it needs to do some 
933 933
 	    cleanup when the server is terminating (flush of cache to disk  for example). 
934
-	    <function moreinfo="none">destroy_modules</function> will call destroy funtion of all loaded modules.
934
+	    <function moreinfo="none">destroy_modules</function> will call destroy function of all loaded modules.
935 935
 	</para>
936 936
 
937 937
 	<para>
... ...
@@ -973,8 +973,8 @@ module_stm = "loadmodule" STRING
973 973
 	    <para>
974 974
 		One of our main goals was to make <acronym>SER</acronym> really fast. There are many functions across
975 975
 		the server that need to work with strings. Usually these functions need to know string length. We wanted
976
-		to avoid using of <function moreinfo="none">strlen</function> becase the function is relatively slow. It
977
-		must scan the whole string and find the first occurence of zero character. To avoid this, we created
976
+		to avoid using of <function moreinfo="none">strlen</function> because the function is relatively slow. It
977
+		must scan the whole string and find the first occurrence of zero character. To avoid this, we created
978 978
 		<type>str</type> type. The type has 2 fields, field <structfield>s</structfield> is pointer
979 979
 		to the beginning of the string and field <structfield>len</structfield> is length of the string. We then
980 980
 		calculate length of the string only once and later reuse saved value.
... ...
@@ -1004,7 +1004,7 @@ typedef struct _str str;
1004 1004
 	    <warning>
1005 1005
 		<para>
1006 1006
 		    Because we store string lengths, there is no need to zero terminate them. Some strings in the
1007
-		    server are still zero terminated, some are not. Be carefull when using functions like 
1007
+		    server are still zero terminated, some are not. Be careful when using functions like 
1008 1008
 		    <function moreinfo="none">snprintf</function> that rely on the ending zero. You can print 
1009 1009
 		    variable of type <type>str</type> this way:
1010 1010
 		    <programlisting format="linespecific">printf("%.*s", mystring->len, mystring->s);</programlisting>
... ...
@@ -1054,7 +1054,7 @@ struct hdr_field {
1054 1054
 			HDR_UNSUPPORTED, HDR_ALLOW, HDR_EVENT, HDR_OTHER.
1055 1055
 		    </para>
1056 1056
 		    <para>
1057
-			Their meaning is selfexplanatory. HDR_OTHER marks header field not recognized by the parser.
1057
+			Their meaning is self explanatory. HDR_OTHER marks header field not recognized by the parser.
1058 1058
 		    </para>
1059 1059
 		</listitem>
1060 1060
 		<listitem>
... ...
@@ -1256,7 +1256,7 @@ struct ip_addr{
1256 1256
     unsigned int af;     /* address family: AF_INET6 or AF_INET */
1257 1257
     unsigned int len;    /* address len, 16 or 4 */
1258 1258
 		
1259
-    /* 64 bits alligned address */
1259
+    /* 64 bits aligned address */
1260 1260
     union {
1261 1261
         unsigned int   addr32[4];
1262 1262
         unsigned short addr16[8];
... ...
@@ -1286,7 +1286,7 @@ struct ip_addr{
1286 1286
 	    </para>
1287 1287
 	    <para>
1288 1288
 		The structure will be described in more detail later in chapter
1289
-		SIP Message MOdifications.
1289
+		SIP Message Modifications.
1290 1290
 	    </para>
1291 1291
 	</section> <!-- lump-rpl -->
1292 1292
 
... ...
@@ -1407,7 +1407,7 @@ struct sip_msg {
1407 1407
     int parsed_flag;               /* Already parsed header field types */
1408 1408
 
1409 1409
     /* Via, To, CSeq, Call-Id, From, end of header*/
1410
-    /* first occurance of it; subsequent occurances 
1410
+    /* first occurrence of it; subsequent occurrences 
1411 1411
      * saved in 'headers' 
1412 1412
      */
1413 1413
 
... ...
@@ -1441,7 +1441,7 @@ struct sip_msg {
1441 1441
     struct ip_addr dst_ip;
1442 1442
 		
1443 1443
     char* orig;       /* original message copy */
1444
-    char* buf;        /* scratch pad, holds a modfied message,
1444
+    char* buf;        /* scratch pad, holds a modified message,
1445 1445
                        *  via, etc. point into it 
1446 1446
 		       */
1447 1447
     unsigned int len; /* message len (orig) */
... ...
@@ -1455,7 +1455,7 @@ struct sip_msg {
1455 1455
     struct lump* add_rm;         /* used for all the forwarded 
1456 1456
                                   * requests */
1457 1457
     struct lump* repl_add_rm;    /* used for all the forwarded replies */
1458
-    struct lump_rpl *reply_lump; /* only for localy generated replies !!!*/
1458
+    struct lump_rpl *reply_lump; /* only for locally generated replies !!!*/
1459 1459
 
1460 1460
     char add_to_branch_s[MAX_BRANCH_PARAM_LEN];
1461 1461
     int add_to_branch_len;
... ...
@@ -1517,7 +1517,7 @@ struct sip_msg {
1517 1517
 	    <para>
1518 1518
 		The following fields are set to zero if the corresponding header field was not found in the
1519 1519
 		message or hasn't been parsed yet. (These fields are called hooks - they always point to the first
1520
-		occurence if there is more than one header field of the same type).
1520
+		occurrence if there is more than one header field of the same type).
1521 1521
 	    </para>
1522 1522
 	    <itemizedlist>
1523 1523
 		<listitem>
... ...
@@ -1703,7 +1703,7 @@ struct sip_msg {
1703 1703
 		<listitem>
1704 1704
 		    <para>
1705 1705
 			<structfield>add_rm</structfield> - Linked list describing all modifications that will be made to
1706
-			<emphasis>REQEST</emphasis> before it will be forwarded. The list will be processed when the request
1706
+			<emphasis>REQUEST</emphasis> before it will be forwarded. The list will be processed when the request
1707 1707
 			is being converted to character array (i.e. immediately before the request will be send out).
1708 1708
 		    </para>
1709 1709
 		</listitem>
... ...
@@ -1718,7 +1718,7 @@ struct sip_msg {
1718 1718
 		<listitem>
1719 1719
 		    <para>
1720 1720
 			<structfield>reply_lump</structfield> - This is list of data chunks that should be appended to 
1721
-			localy generated reply, i.e. when the server is generating local reply out of the request. A local
1721
+			locally generated reply, i.e. when the server is generating local reply out of the request. A local
1722 1722
 			reply is reply generated by the server. For example, when processing of a request fails for some
1723 1723
 			reason, the server might generate an error reply and send it back to sender.
1724 1724
 		    </para>
... ...
@@ -2125,7 +2125,7 @@ struct sip_msg {
2125 2125
 		    </para>
2126 2126
 		    <para>
2127 2127
 			There is an expression associated with the command and one or two linked lists of
2128
-			comands. The expression is a regular expression compiled into binary form
2128
+			commands. The expression is a regular expression compiled into binary form
2129 2129
 			in the fixup when the config file was compiled.
2130 2130
 		    </para>
2131 2131
 		    <para>
... ...
@@ -2136,7 +2136,7 @@ struct sip_msg {
2136 2136
 		    </para>
2137 2137
 		    <para>
2138 2138
 			Otherwise, if there is the second list, it will be executed in the same way. The
2139
-			second list represents commads of <function moreinfo="none">else</function>
2139
+			second list represents commands of <function moreinfo="none">else</function>
2140 2140
 			statement.
2141 2141
 		    </para>
2142 2142
 		</listitem>
... ...
@@ -2329,7 +2329,7 @@ struct sip_msg {
2329 2329
 		    The parser is 32-bit, it means, that it processes 4 characters of header field name at time. 4
2330 2330
 		    characters of a header field name are converted to an integer and the integer is then compared. This
2331 2331
 		    is much faster than comparing byte by byte. Because the server is compiled on at least 32-bit architectures,
2332
-		    such comparsion will be compiled into one instruction instead of 4 instructions.
2332
+		    such comparison will be compiled into one instruction instead of 4 instructions.
2333 2333
 		</para>
2334 2334
 		<para>
2335 2335
 		    We did some performance measurement and 32-bit parsing is about 3 times faster for a typical 
... ...
@@ -2650,7 +2650,7 @@ struct to_body{
2650 2650
 		    </para>
2651 2651
 		    <para>
2652 2652
 			If the main parser finds a From header field, it will not parse the header field body
2653
-			automaticaly. It is up to you to call the 
2653
+			automatically. It is up to you to call the 
2654 2654
 			<function moreinfo="none">parse_from_header</function> when you want to parse a From
2655 2655
 			header field body.
2656 2656
 		    </para>
... ...
@@ -2805,7 +2805,7 @@ typedef struct event {
2805 2805
 		    <para>
2806 2806
 			The parser can be found in file <filename moreinfo="none">parse_expires.c</filename> under
2807 2807
 			<filename moreinfo="none">parser</filename> subdirectory. Main function is
2808
-			<function moreinfo="none">parse_expires</function>. The function is not called automaticaly
2808
+			<function moreinfo="none">parse_expires</function>. The function is not called automatically
2809 2809
 			when an Expires header field was found. It is up to you to call the function if you need the body
2810 2810
 			to be parsed.
2811 2811
 		    </para>
... ...
@@ -2885,7 +2885,7 @@ typedef struct exp_body {
2885 2885
 		    <title>Contact HF Body Parser</title>
2886 2886
 		    <para>
2887 2887
 			The parser is located under <filename moreinfo="none">parser/contact</filename> subdirectory. The
2888
-			parser is not called automaticaly when the main parser finds a Contact header field. It is your
2888
+			parser is not called automatically when the main parser finds a Contact header field. It is your
2889 2889
 			responsibility to call the parser if you want a Contact header field body to be parsed.
2890 2890
 		    </para>
2891 2891
 		    <para>
... ...
@@ -2919,7 +2919,7 @@ typedef struct exp_body {
2919 2919
 		    </para>
2920 2920
 		    <note>
2921 2921
 			<para>
2922
-			    Mind that none of string in the following structures is zero terminated ! Be very carefull
2922
+			    Mind that none of string in the following structures is zero terminated ! Be very careful
2923 2923
 			    when processing the strings with functions that require zero termination (printf for example) !
2924 2924
 			</para>
2925 2925
 		    </note>
... ...
@@ -3066,7 +3066,7 @@ typedef struct cparam {
3066 3066
 			can be used for all of them.
3067 3067
 		    </para>
3068 3068
 		    <para>
3069
-			The parser is not called automaticaly when by the main parser. It is your responsibility to call the
3069
+			The parser is not called automatically when by the main parser. It is your responsibility to call the
3070 3070
 			parser when you want a digest response to be parsed.
3071 3071
 		    </para>
3072 3072
 		    <para>
... ...
@@ -3086,7 +3086,7 @@ typedef struct cparam {
3086 3086
 		    </para>
3087 3087
 
3088 3088
 		    <para>
3089
-			Description of digest related stuctures follows:
3089
+			Description of digest related structures follows:
3090 3090
 		    </para>
3091 3091
 
3092 3092
 		    <programlisting format="linespecific">			
... ...
@@ -3109,7 +3109,7 @@ typedef struct auth_body {
3109 3109
 } auth_body_t;
3110 3110
 </programlisting>
3111 3111
 		    <para>
3112
-			This is the <quote>main</quote> stucture. Pointer to the structure will be stored in
3112
+			This is the <quote>main</quote> structure. Pointer to the structure will be stored in
3113 3113
 			<structfield>parsed</structfield> field of <structname>hdr_field</structname> structure. Detailed
3114 3114
 			description of its fields follows:
3115 3115
 			<itemizedlist>
... ...
@@ -3131,13 +3131,13 @@ typedef struct auth_body {
3131 3131
 				    there might be other functions interested in knowing which credentials are authorized.
3132 3132
 				</para>
3133 3133
 				<para>
3134
-				    That is what is this field for. A function that sucessfully authorized credentials
3135
-				    (currenty there is only one such function in the server, it is function 
3134
+				    That is what is this field for. A function that successfully authorized credentials
3135
+				    (currently there is only one such function in the server, it is function 
3136 3136
 				    <function moreinfo="none">authorize</function> in auth module) will put pointer to header
3137 3137
 				    field containing the authorized credentials in this field. Because there might be several
3138 3138
 				    header field containing credentials, the pointer will be put in 
3139 3139
 				    <structfield>authorized</structfield> field in the first header field in the message
3140
-				    containg credentials. That means that it will be either header field whose pointer is
3140
+				    containing credentials. That means that it will be either header field whose pointer is
3141 3141
 				    in <structfield>www_auth</structfield> or <structfield>proxy_auth</structfield> field
3142 3142
 				    of <structname>sip_msg</structname> structure representing the message.
3143 3143
 				</para>
... ...
@@ -3295,7 +3295,7 @@ typedef enum qop_type {
3295 3295
 			    </listitem>
3296 3296
 			    <listitem>
3297 3297
 				<para>
3298
-				    <emphasis>QOP_OTHER</emphasis> - Unknow qop parameter value was found in digest response.
3298
+				    <emphasis>QOP_OTHER</emphasis> - Unknown qop parameter value was found in digest response.
3299 3299
 				</para>
3300 3300
 			    </listitem>
3301 3301
 			</itemizedlist>
... ...
@@ -3446,7 +3446,7 @@ typedef struct dig_cred {
3446 3446
 			
3447 3447
 			<para>
3448 3448
 			    This function performs some basic sanity check over parsed digest credentials. The following
3449
-			    conditions must be met for the checks to be successfull:
3449
+			    conditions must be met for the checks to be successful:
3450 3450
 			    <itemizedlist>
3451 3451
 				<listitem>
3452 3452
 				    <para>
... ...
@@ -3513,7 +3513,7 @@ typedef struct dig_cred {
3513 3513
 			
3514 3514
 			<para>
3515 3515
 			    This is convenience function. The function will retrieve pointer to authorized credentials 
3516
-			    previously saved  using <function moreinfo="none">mark_authoized_cred</function> function.
3516
+			    previously saved  using <function moreinfo="none">mark_authorized_cred</function> function.
3517 3517
 			    If there is no such credentials, 0 will be stored in variable pointed to by the second
3518 3518
 			    parameter. The function returns always zero. For more information see description of
3519 3519
 			    <structfield>authorized</structfield> field in <structname>auth_body</structname> structure.
... ...
@@ -3622,7 +3622,7 @@ struct module_exports{
3622 3622
                               * memory locations */
3623 3623
     int par_no;              /* number of registered parameters */
3624 3624
 
3625
-    init_function init_f;         /* Initilization function */
3625
+    init_function init_f;         /* Initialization function */
3626 3626
     response_function response_f; /* function used for responses,
3627 3627
                                    * returns yes or no; can be null 
3628 3628
                                    */
... ...
@@ -3674,7 +3674,7 @@ struct module_exports{
3674 3674
 		    </para>
3675 3675
 		    <para>
3676 3676
 			The function should return number &gt; 0 if everything went OK and processing of the message should
3677
-			contine. The function should return 0 if processing of the message should be stopped.
3677
+			continue. The function should return 0 if processing of the message should be stopped.
3678 3678
 			The function should return number &lt; 0 on an error.
3679 3679
 		    </para>
3680 3680
 		</listitem>
... ...
@@ -3716,7 +3716,7 @@ struct module_exports{
3716 3716
 			    <structfield>cmd_names</structfield>, <structfield>cmd_pointers</structfield>,
3717 3717
 			    <structfield>param_no</structfield> and <structfield>fixup_pointer</structfield> arrays must
3718 3718
 			    have at least <structfield>cmd_no</structfield> elements ! (It might even kill your cat if you
3719
-			    fail to fullfill this condition).
3719
+			    fail to fulfill this condition).
3720 3720
 			</para>
3721 3721
 		    </important>
3722 3722
 		</listitem>
... ...
@@ -3784,7 +3784,7 @@ struct module_exports{
3784 3784
 			</funcprototype>
3785 3785
 		    </funcsynopsis>
3786 3786
 		    <para>
3787
-			The function accepts one parameter which is stucture representing the response currently
3787
+			The function accepts one parameter which is structure representing the response currently
3788 3788
 			being processed.
3789 3789
 		    </para>
3790 3790
 		    <para>
... ...
@@ -3918,7 +3918,7 @@ struct module_exports{
3918 3918
 		    </listitem>
3919 3919
 		    <listitem>
3920 3920
 			<para>
3921
-			    <structfield>handle</structfield> field will be set to handle previously retuned by
3921
+			    <structfield>handle</structfield> field will be set to handle previously returned by
3922 3922
 			    <function moreinfo="none">dlopen</function>.
3923 3923
 			</para>
3924 3924
 		    </listitem>
... ...
@@ -3971,7 +3971,7 @@ struct module_exports{
3971 3971
 				<emphasis>value</emphasis> - New value of the variable. There are two types of variables:
3972 3972
 				string and integer. If the last parameter (value) of 
3973 3973
 				<function moreinfo="none">modparam</function>
3974
-				function is enclosed in quotes, it is string paramater and server will try to find the
3974
+				function is enclosed in quotes, it is string parameter and server will try to find the
3975 3975
 				corresponding variable among string parameters only.
3976 3976
 			    </para>
3977 3977
 			    <para>
... ...
@@ -4035,7 +4035,7 @@ struct module_exports{
4035 4035
 		</para>
4036 4036
 		<para>
4037 4037
 		    The function will search list of all modules until it finds module with given name.
4038
-		    Then it will search throught all module's exported parameters until it finds parameter
4038
+		    Then it will search through all module's exported parameters until it finds parameter
4039 4039
 		    with corresponding name and type. If such parameter was found, pointer to variable holding
4040 4040
 		    the parameter's value will be returned. If the function failed to find either module or
4041 4041
 		    parameter with given name and type then zero will be returned.
... ...
@@ -4066,7 +4066,7 @@ struct module_exports{
4066 4066
 		</itemizedlist>
4067 4067
 	    </para>
4068 4068
 	    <para>
4069
-		The function will search throught list of all loaded modules and in each module through
4069
+		The function will search through list of all loaded modules and in each module through
4070 4070
 		array of all exported functions until it finds function with given name and number of
4071 4071
 		parameters. If such exported function was found, <function moreinfo="none">find_exported</function>
4072 4072
 		will return pointer to the function, otherwise zero will be returned.
... ...
@@ -4593,7 +4593,7 @@ int n = RES_ROW_N(res);
4593 4593
 		names start with db_ prefix, except <function moreinfo="none">bind_dbmod</function>. 
4594 4594
 		<function moreinfo="none">bind_dbmod</function> is implemented in <filename moreinfo="none">db.c</filename>
4595 4595
 		file, all other functions are implemented in a standalone module.
4596
-		Detaileddescription of functions follows.
4596
+		Detailed description of functions follows.
4597 4597
 	    </para>
4598 4598
 
4599 4599
 	    <section id="bind-dbmod">
... ...
@@ -4648,7 +4648,7 @@ int n = RES_ROW_N(res);
4648 4648
 			</listitem>
4649 4649
 			<listitem>
4650 4650
 			    <para>
4651
-				<emphasis>host</emphasis> -  Hosname or IP address of the host 
4651
+				<emphasis>host</emphasis> -  Hostname or IP address of the host 
4652 4652
 				where database server lives (mandatory).
4653 4653
 			    </para>
4654 4654
 			</listitem>
... ...
@@ -4762,7 +4762,7 @@ int n = RES_ROW_N(res);
4762 4762
 		    If _c is NULL and _nc is zero, you will get all table columns in the result
4763 4763
 		</para>
4764 4764
 		<para>
4765
-		    _r will point to a dynamically allocated structure, it is neccessary to call
4765
+		    _r will point to a dynamically allocated structure, it is necessary to call
4766 4766
 		    db_free_query function once you are finished with the result.
4767 4767
 		</para>
4768 4768
 		<para>
... ...
@@ -4781,7 +4781,7 @@ int n = RES_ROW_N(res);
4781 4781
 		<title><function moreinfo="none">db_free_query</function></title>
4782 4782
 		<para>
4783 4783
 		    This function frees all memory allocated previously in <function moreinfo="none">db_query</function>, 
4784
-		    it is neccessary to call this function for a <type>db_res_t</type> structure if you don't need the
4784
+		    it is necessary to call this function for a <type>db_res_t</type> structure if you don't need the
4785 4785
 		    structure anymore. You must call this function <emphasis>BEFORE</emphasis> you call 
4786 4786
 		    <function moreinfo="none">db_query</function> again !
4787 4787
 		</para>
... ...
@@ -5101,7 +5101,7 @@ int n = RES_ROW_N(res);
5101 5101
 			    macro is set in defs.h header file. The column of this name contains
5102 5102
 			    alternate ha1 strings calculated from username containing also
5103 5103
 			    domain, for example username="jan@iptel.org". This hack is 
5104
-			    neccessary for some broken user agents. The parameter has no
5104
+			    necessary for some broken user agents. The parameter has no
5105 5105
 			    meaning if "calculate_ha1" is set to true.
5106 5106
 			</para>
5107 5107
 			<para>
... ...
@@ -5282,7 +5282,7 @@ if (!proxy_authorize( "iptel.org", "subscriber" )) {
5282 5282
 			    Challenges a user agent using WWW-Authenticate header
5283 5283
 			    field. The second parameter specifies if qop parameter
5284 5284
 			    (according to rfc2617) should be used or not.
5285
-			    (Turning off is useful primarly to make UAC happy, which
5285
+			    (Turning off is useful primarily to make UAC happy, which
5286 5286
 			    have a broken qop implementation, particularly M$ Messenger 4.6).
5287 5287
 			</para>
5288 5288
 			<para>
... ...
@@ -5308,7 +5308,7 @@ if (!proxy_authorize( "iptel.org", "subscriber" )) {
5308 5308
 			    Challenges a user agent using Proxy-Authenticate header
5309 5309
 			    field. The second parameter specifies if qop parameter
5310 5310
 			    (according to rfc2617) should be used or not.
5311
-			    (Turning off is useful primarly to make UAC happy, which
5311
+			    (Turning off is useful primarily to make UAC happy, which
5312 5312
 			    have a broken qop implementation, particularly M$ Messenger 4.6).
5313 5313
 			</para>
5314 5314
 			<para>
... ...
@@ -5516,16 +5516,16 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5516 5516
 		    </funcprototype>
5517 5517
 		</funcsynopsis>
5518 5518
 		<para>
5519
-		    If no Max-Forward header is present in the received request, a header will be
5519
+		    If no Max-Forwards header is present in the received request, a header will be
5520 5520
 		    added having the original value equal with "max_value". An OK code is returned
5521 5521
 		    by the function.
5522 5522
 		</para>
5523 5523
 		<para>
5524
-		    If a Max-Forward header is already present, its value will be decremented. If
5524
+		    If a Max-Forwards header is already present, its value will be decremented. If
5525 5525
 		    after this operation its value will be positive non-zero, an OK code will be
5526 5526
 		    returned. Otherwise (for a zero value) an error code will be returned.
5527 5527
 		    Note that an error code will be also returned if the SIP message couldn't
5528
-		    be parsed or if the Max-Forwrd header's body invalid (non numerical string or
5528
+		    be parsed or if the Max-Forwards header's body invalid (non numerical string or
5529 5529
 		    negative numerical value)
5530 5530
 		</para>
5531 5531
 		<para>
... ...
@@ -5592,7 +5592,7 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5592 5592
 			<para>
5593 5593
 			    <varname>append_branches</varname> - The parameter controls how lookup function processes 
5594 5594
 			    multiple contacts. If there are multiple contacts for the given username in usrloc and this
5595
-			    parametr is set to 1, Request-URI will be overwritten with the highest-q
5595
+			    parameter is set to 1, Request-URI will be overwritten with the highest-q
5596 5596
 			    rated contact and the rest will be appended to sip_msg structure and can 
5597 5597
 			    be later used by tm for forking. If the parameter is set to 0, only 
5598 5598
 			    Request-URI will be overwritten with the highest-q rated contact and the 
... ...
@@ -5772,7 +5772,7 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5772 5772
 			<para>
5773 5773
 			    For the current request, a reply is sent back having the given code and text
5774 5774
 			    reason. The reply is sent stateless, totally independent of the Transaction
5775
-			    module and with no retranssmision for the INVITE's replies.
5775
+			    module and with no retransmission for the INVITE's replies.
5776 5776
 			</para>
5777 5777
 			<para>
5778 5778
 			    <varname>code</varname> - Reply code to be used.
... ...
@@ -5842,14 +5842,14 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5842 5842
 		memory and CPU, is some services inherently need state.
5843 5843
 		For example, transaction-based accounting (module acc) needs
5844 5844
 		to process transaction state as opposed to individual messages,
5845
-		and any kinds of forking must be implemented statefuly.
5845
+		and any kinds of forking must be implemented statefully.
5846 5846
 		Other use of stateful processing is it trading CPU caused by 
5847 5847
 		retransmission processing for memory. That makes however only
5848 5848
 		sense if CPU consumption per request is huge. For example,
5849 5849
 		if you want to avoid costly DNS resolution for every retransmission
5850
-		of a request to an unresolveable destination, use stateful mode.
5850
+		of a request to an unresolvable destination, use stateful mode.
5851 5851
 		Then, only the initial message burdens server by DNS queries,
5852
-		subsequent retranmissions will be dropped and will not result in
5852
+		subsequent retransmissions will be dropped and will not result in
5853 5853
 		more processes blocked by DNS resolution. The price is more 
5854 5854
 		memory consumption and higher processing latency.
5855 5855
 	    </para>
... ...
@@ -5868,13 +5868,13 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5868 5868
 		time (memcpys, lookups, shmem locks, etc.) Note that non-TM
5869 5869
 		functions operate over the received message in private memory,
5870 5870
 		that means that any core operations will have no effect on
5871
-		statefuly processed messages after creating the transactional
5871
+		statefully processed messages after creating the transactional
5872 5872
 		state. For example, calling addRecordRoute *after* t_relay
5873 5873
 		is pretty useless, as the RR is added to privately held message
5874 5874
 		whereas its TM clone is being forwarded.
5875 5875
 	    </para>
5876 5876
 	    <para>
5877
-		TM is quite big and uneasy to programm -- lot of mutexes, shared
5877
+		TM is quite big and uneasy to program -- lot of mutexes, shared
5878 5878
 		memory access, malloc & free, timers -- you really need to be careful
5879 5879
 		when you do anything. To simplify TM programming, there is the
5880 5880
 		instrument of callbacks. The callback mechanisms allow programmers
... ...
@@ -5883,7 +5883,7 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5883 5883
 	    </para>
5884 5884
 	    <para>
5885 5885
 		Other things programmers may want to know is UAC -- it is 
5886
-		a very simplictic code which allows you to generate your own
5886
+		a very simplistic code which allows you to generate your own
5887 5887
 		transactions. Particularly useful for things like NOTIFYs or
5888 5888
 		IM gateways. The UAC takes care of all the transaction
5889 5889
 		machinery: retransmissions , FR timeouts, forking, etc.
... ...
@@ -5895,11 +5895,11 @@ if (method=="REGISTER" & proxy_authorize("iptel.org", "subscriber" ) {
5895 5895
 		<title>External Usage of TM</title>
5896 5896
 		<para>
5897 5897
 		    There are applications which would like to generate SIP
5898
-		    transactions without too big onvolvement in SIP stack, transaction
5898
+		    transactions without too big involvement in SIP stack, transaction
5899 5899
 		    management, etc. An example of such an application
5900 5900
 		    is sending instant messages from a website. To address needs
5901 5901
 		    of such apps, SER accepts requests for new transactions via
5902
-		    fifo pipes too. If you want to enable this feature, statrt
5902
+		    fifo pipes too. If you want to enable this feature, start
5903 5903
 		    FIFO server by configuration option
5904 5904
 		    fifo=<quote>/tmp/filename</quote>
5905 5905
 		    Then, an application can easily launch a new transaction by
... ...
@@ -5983,7 +5983,7 @@ end of body
5983 5983
 			    <varname>wt_timer</varname> - Time for which a transaction stays in memory to absorb
5984 5984
 			    delayed messages after it completed; also, when this
5985 5985
 			    timer hits, retransmission of local cancels is stopped
5986
-			    (a puristic but complex behviour would be not to enter
5986
+			    (a puristic but complex behaviour would be not to enter
5987 5987
 			    wait state until local branches are finished by a final
5988 5988
 			    reply or FR timer -- we simplified)
5989 5989
 			</para>
... ...
@@ -6067,7 +6067,7 @@ end of body
6067 6067
 			    </funcprototype>
6068 6068
 			</funcsynopsis>
6069 6069
 			<para>
6070
-			    Relay a message statefuly to a fixed destination; this along with
6070
+			    Relay a message statefully to a fixed destination; this along with
6071 6071
 			    t_relay is the function most users want to use -- all other are
6072 6072
 			    mostly for programming; programmers interested in writing TM
6073 6073
 			    logic should review how t_relay is implemented in tm.c and how
... ...
@@ -6100,7 +6100,7 @@ if (!t_relay_to("1.2.3.4", "5060")) {
6100 6100
 			    </funcprototype>
6101 6101
 			</funcsynopsis>
6102 6102
 			<para>
6103
-			    Relay a message statefuly to destination indicated in current URI;
6103
+			    Relay a message statefully to destination indicated in current URI;
6104 6104
 			    (if the original URI was rewritten by UsrLoc, RR, strip/prefix,
6105 6105
 			    etc., the new URI will be taken); returns a negative value on
6106 6106
 			    failure -- you may still want to send a negative reply upstream
... ...
@@ -6138,13 +6138,13 @@ if (!t_relay()) {
6138 6138
 			<para>
6139 6139
 			    Sets reply routing block, to which control is passed after
6140 6140
 			    a transaction completed with a negative result but before
6141
-			    sending a final reply; In the refered block, you can
6141
+			    sending a final reply; In the referred block, you can
6142 6142
 			    either start a new branch (good for services such as
6143 6143
 			    forward_on_no_reply) or send a final reply on your own
6144 6144
 			    (good for example for message silo, which received 
6145 6145
 			    a negative reply from upstream and wants to tell
6146 6146
 			    upstream "202 I will take care of it"); Note that the
6147
-			    set of command which are useable within reply_routes is
6147
+			    set of command which are usable within reply_routes is
6148 6148
 			    strictly limited to rewriting URI, initiating new branches,
6149 6149
 			    logging, and sending 'unsafe' replies (t_reply_unsafe). Any 
6150 6150
 			    other commands may result in unpredictable behaviour and 
... ...
@@ -6246,7 +6246,7 @@ if (t_newtran()) {
6246 6246
 			<para>
6247 6247
 			    Checks if a transaction exists; returns a positive value
6248 6248
 			    if so, negative otherwise; most likely you will not want
6249
-			    to use it, as a typicall application of a looku-up is to
6249
+			    to use it, as a typical application of a look-up is to
6250 6250
 			    introduce a new transaction if none was found; however
6251 6251
 			    this is safely (atomically) done using t_newtran.
6252 6252
 			</para>
... ...
@@ -6311,7 +6311,7 @@ if (t_newtran()) {
6311 6311
 			    </funcprototype>
6312 6312
 			</funcsynopsis>
6313 6313
 			<para>
6314
-			    Mainly for internal -- forward a non-ACK request statefuly.
6314
+			    Mainly for internal -- forward a non-ACK request statefully.
6315 6315
 			</para>
6316 6316
 			<para>
6317 6317
 			    <varname>ip</varname> - IP address.
... ...
@@ -6440,7 +6440,7 @@ if (t_newtran()) {
6440 6440
 		    <listitem>
6441 6441
 			<para>
6442 6442
 			    Make UAC session-aware (as opposed to just transaction aware) -- needed
6443
-			    for keeing SUB-NOT dialog state, etc. Currently, there are only
6443
+			    for keeping SUB-NOT dialog state, etc. Currently, there are only
6444 6444
 			    place-holders for in in TM.
6445 6445
 			</para>
6446 6446
 		    </listitem>
... ...
@@ -6454,7 +6454,7 @@ if (t_newtran()) {
6454 6454
 	<section id="usrloc">
6455 6455
 	    <title>User Location Module</title>
6456 6456
 	    <para>Support for location of users.</para>
6457
-	    <para>Module depends on: Optionaly mysql (if configured for persistence)</para>
6457
+	    <para>Module depends on: Optionally mysql (if configured for persistence)</para>
6458 6458
 
6459 6459
 	    <important>
6460 6460
 		<para>
... ...
@@ -6596,7 +6596,7 @@ if (t_newtran()) {
6596 6596
 					0 - This disables database completely. Only memory
6597 6597
 					will be used. Contacts will not survive restart.
6598 6598
 					Use this value if you need a really fast usrloc
6599
-					and contact persistence is not necessarry or is
6599
+					and contact persistence is not necessary or is
6600 6600
 					provided by other means.
6601 6601
 				    </para>
6602 6602
 				</listitem>
... ...
@@ -6660,7 +6660,7 @@ if (t_newtran()) {
6660 6660
 			    for table used in registrar. The function is called from fixups
6661 6661
 			    in registrar. It gets name of the domain as a parameter and returns
6662 6662
 			    pointer to a new domain structure. The fixup than 'fixes' the
6663
-			    parametr in registrar so that it will pass the pointer instead of
6663
+			    parameter in registrar so that it will pass the pointer instead of
6664 6664
 			    the name every time save() or lookup() is called. Some usrloc functions
6665 6665
 			    get the pointer as parameter when called. For more details see 
6666 6666
 			    implementation of save function in registrar.