doc/tutorials: typos

doc/tutorials/dns.txt

@@ -144,7 +144,7 @@ DNS Resolver Options
 
  The maximum time a DNS request can take (before failing) is:
  (dns_retr_time*dns_retr_no) * (search_list_domains) If dns_try_ipv6 is yes,
- mutliply it again by 2.
+ multiply it again by 2.
 
  The option combination that produces the "fastest" DNS resolver config
   (the "faster" in the sense that it gives up the quickest) is:
@@ -159,7 +159,7 @@ DNS Resolver Options
  server configured in /etc/resolv.conf, set the DNS resolver options in Kamailio's
  config as in the above example and enable the DNS cache (in Kamailio).
  Pay particular attention to dns_servers_no and dns_use_search_list. It's a
- good idea to make sure you don't need / use the search list or more then one
+ good idea to make sure you don't need / use the search list or more than one
  DNS server (to avoid unnecessary extra lookups).
 
 

doc/tutorials/locking.txt

@@ -10,21 +10,21 @@ For example right now Kamailio uses the following locking methods, depending on
 target system:
 	FAST_LOCK - fast inline assembly locks, defined in fast_lock.h. They are currently available for 
 	x86, x86_64, sparc, sparc64, arm , armv6 (no smp mode supported yet), ppc, ppc64, mips, mips64 
-	and alpha . In general if the assembly code exists for a given arhitecture and the compiler 
+	and alpha . In general if the assembly code exists for a given architecture and the compiler 
 	knows inline assembly (for example sun cc does not) FAST_LOCK is prefered. The main 
 	advantage of using FAST_LOCK is very low memory overhead and extremely fast lock/unlock 
-	operations (like 20 times faster then SYSV semaphores on linux & 40 times on solaris). 
+	operations (like 20 times faster than SYSV semaphores on linux & 40 times on solaris). 
 	The only thing that comes close to them are pthread mutexes (which are about 3-4 times slower).
 
 	PTHREAD_MUTEX - uses pthread_mutex_lock/unlock. They are quite fast but they work between 
 	processes only on some systems (they do not work on linux).
 
-	POSIX_SEM  - uses posix semaphores (sem_wait/sem_post). They are slower then the previous 
-	methods but still way faster then SYSV sempahores. Unfortunately they also do not work on 
+	POSIX_SEM  - uses posix semaphores (sem_wait/sem_post). They are slower than the previous 
+	methods but still way faster than SYSV semaphores. Unfortunately they also do not work on 
 	all the systems (e.g. linux).
 	
 	SYSV_SEM - this is the most portable but also the slowest locking method. Another problem is 
-	that the number of semaphores that can be alocated by a process is limited. One also has to 
+	that the number of semaphores that can be allocated by a process is limited. One also has to 
 	free them before exiting.
 
 
@@ -33,7 +33,7 @@ target system:
 
 First of all you have to include locking.h. Then when compiling the code one or all of FAST_LOCK, 
 USE_PTHREAD_MUTEX, USE_PTHREAD_SEM or USE_SYSV_SEM must be defined (the Kamailio Makefile.defs takes 
-care of this, you should need to change it only for new arhitectures or compilers).
+care of this, you should need to change it only for new architectures or compilers).
 
 locking.h defines 2 new types: gen_lock_t and lock_set_t.
 

doc/tutorials/logging-api.txt

@@ -78,7 +78,7 @@ Source files:
           - for messages by modules:
               PROC(PID) LEVEL: MODULE [FILE:LINE]: MESSAGE
 	      
-          - for messages by log(), xlog(), xdbg() script funcitons:
+          - for messages by log(), xlog(), xdbg() script functions:
               PROC(PID) LEVEL: <script>: MESSAGE
 
 	PROC is the SER process number and PID is the linux process ID.

doc/tutorials/modules_init.txt

@@ -1,5 +1,5 @@
 
-Kamailio Module intialization description
+Kamailio Module initialization description
 ===========================================
 
 This document is a very brief overview on what possibilities are for a module

doc/tutorials/parse_headers.txt

@@ -3,7 +3,7 @@
 # 2004.02.23  created (andrei)
 
 
-Starting with the ser version 0.10.99-dev1, the parse headers api has been slighlty changed. The reason for this change was performance improvement (now gcc can optimze much better all the switches involving header types) and dramatically reducing the memory impact of switching to 64 bits flags.
+Starting with the ser version 0.10.99-dev1, the parse headers api has been slightly changed. The reason for this change was performance improvement (now gcc can optimize much better all the switches involving header types) and dramatically reducing the memory impact of switching to 64 bits flags.
 
 The header flags (HDR_xxx) have been split into header types (hdr_types_t) and header flags (hdr_flags_t). Instead of the old HDR_xxx use now HDR_xxx_T when the header type is required and HDR_xxx_F or HDR_T2F(HDR_xxx_T) when the corresponding header flag is needed (e.g. in the parse_headers() call).
 

doc/tutorials/presence/cfg/full_ps.cfg

@@ -16,7 +16,7 @@ alias="t-online.de"
 #user=ser
 #group=ser
 #open_fd_limit=1024 # sets the open file descriptors limit
-mhomed=yes  # usefull for multihomed hosts, small performance penalty
+mhomed=yes  # useful for multihomed hosts, small performance penalty
 
 #disable_tcp=yes 
 tcp_accept_aliases=yes # accepts the tcp alias via option (see NEWS)
@@ -131,7 +131,7 @@ modparam("pa", "ignore_408_on_notify", 1)
 #modparam("presence_b2b", "presence_route", "<sip:127.0.0.1;transport=tcp;lr>")
 modparam("presence_b2b", "presence_outbound_proxy", "sip:127.0.0.1;transport=tcp")
 #modparam("presence_b2b", "presence_outbound_proxy", "sip:127.0.0.1")
-# waiting time from error to new attepmt about SUBSCRIBE
+# waiting time from error to new attempt about SUBSCRIBE
 modparam("presence_b2b", "on_error_retry_time", 60)
 # how long wait for NOTIFY with Subscription-Status=terminated after unsubscribe
 modparam("presence_b2b", "wait_for_term_notify", 33)
@@ -144,7 +144,7 @@ modparam("presence_b2b", "default_expiration", 3600)
 # process internal subscriptions to presence events
 modparam("presence_b2b", "handle_presence_subscriptions", 1)
 #additional headers for presence
-#modparam("presence_b2b", "additional_presence_headers", "P-Generated: yes\r\nP-Regenreated: no\r\n")
+#modparam("presence_b2b", "additional_presence_headers", "P-Generated: yes\r\nP-Regenerated: no\r\n")
 # randomized SUBSCRIBE requests?
 modparam("presence_b2b", "max_subscribe_delay", 10)
 
@@ -314,7 +314,7 @@ route{
 			
 				if (!have_flat_list()) {
 					# query_resource_list failed or was not called
-					# do standard RLS query acording to To/AOR
+					# do standard RLS query according to To/AOR
 					if (!query_rls_services()) {
 						log(1, "XCAP query failed\n");
 						t_reply("404", "No such list URI");

doc/tutorials/presence/cfg/ps.cfg

@@ -43,7 +43,7 @@ rev_dns=no      # (cmd. line: -R)
 #group=ser
 #disable_core=yes #disables core dumping
 #open_fd_limit=1024 # sets the open file descriptors limit
-#mhomed=yes  # usefull for multihomed hosts, small performance penalty
+#mhomed=yes  # useful for multihomed hosts, small performance penalty
 #disable_tcp=yes 
 #tcp_accept_aliases=yes # accepts the tcp alias via option (see NEWS)
 
@@ -132,7 +132,7 @@ modparam("ctl", "fifo", "fifo:/tmp/ser_fifo")
 # failed transactions (=negative responses) should be logged to
 modparam("acc_db", "failed_transactions", 1)
 
-# comment the next line if you dont want to have accounting to DB
+# comment the next line if you don't want to have accounting to DB
 modparam("acc_db", "log_flag", "FLAG_ACC")
 
 # -- tm params --
@@ -194,7 +194,7 @@ route{
 
 route[FORWARD]
 {
-	# here you could decide wether this call needs a RTP relay or not
+	# here you could decide whether this call needs a RTP relay or not
 
 	# send it out now; use stateful forwarding as it works reliably
 	# even for UDP2TCP
@@ -282,7 +282,7 @@ route[RR]
 		# particularly good if upstream and downstream entities
 		# use different transport protocol
 
-		# if the inital INVITE got the ACC flag store this in
+		# if the initial INVITE got the ACC flag store this in
 		# an RR AVP cookie. this is more for demonstration purpose
 		if (isflagset(FLAG_ACC)) {
 			$account = "yes";
@@ -303,7 +303,7 @@ route[DOMAIN]
 	# domain]
 	lookup_domain("$td", "@to.uri.host");
 
-	# we dont know the domain of the caller and also not
+	# we don't know the domain of the caller and also not
 	# the domain of the callee -> somone uses our proxy as
 	# a relay
 	if (!$t.did && !$f.did) {
@@ -443,7 +443,7 @@ route[INBOUND]
 		if (lookup_contacts("location")) {
 			append_hf("P-hint: usrloc applied\r\n");
 
-			# we set the TM module timers according to the prefences
+			# we set the TM module timers according to the preferences
 			# of the callee (avoid too long ringing of his phones)
 			# Note1: timer values have to be in ms now!
 			# Note2: this makes even more sense if you switch to a voicemail

doc/tutorials/presence/draft_iptel_im_rules.xml

@@ -30,7 +30,7 @@ storing rules for authorization of instant messages.
 
 <!-- ******************** Documents ********************* -->
 <section id="docs"><title>Instant message authorization documents</title>
-<para>Instant message authorization document is XML document formated according
+<para>Instant message authorization document is XML document formatted according
 to the schema defined in <xref linkend="common_auth"/>. It inherits the MIME
 type of common policy documents defined there - application/auth-policy+xml.
 </para>
@@ -142,7 +142,7 @@ xmlns:im="urn:iptel:xml:ns:im-rules">
 
 <section><title>Usage with XCAP</title>
 <para>This document defines <quote>im-rules</quote> as unique application usage
-ID (AUID) requiered by XCAP specification.
+ID (AUID) required by XCAP specification.
 </para>
 
 <section><title>Naming conventions</title>

doc/tutorials/presence/install.xml

@@ -56,7 +56,7 @@ no prefix parameter given - default value is used: /usr/local/)
 	</para></listitem>
 
 	<listitem><para>Compile and install SIP-router with presence modules. Common
-	libraries should be compiled automaticaly - it may fail in the case of
+	libraries should be compiled automatically - it may fail in the case of
 	unsatisfied library dependencies. You need to install all external libraries
 	introduced in <xref linkend="pres.dependencies"/></para>
 	<para><userinput>cd sip_router</userinput></para>

doc/tutorials/presence/intro.xml

@@ -65,7 +65,7 @@ libraries. Their interface is described in standalone documents.
 <section><title>Persistence</title>
 <para>Modules can store their status (working data) into database. This data is
 automatically reloaded on startup, so it is possible to restart SIP-router and
-clients don't note it. Established SIP dialogs are stored in database too.</para>
+clients don't note it. Established SIP dialogs are stored in a database too.</para>
 <para>Details about database storage are described for each module separately in
 module documentation.
 

doc/tutorials/presence/trouble.xml

@@ -27,7 +27,7 @@
 	<listitem><para>The XCAP module is incompatible with TLS module due to Openssl
 	initialization!</para>
 	<para>XCAP module uses libcurl for HTTP communication and libcurl is using
-	libopenssl internaly. But the TLS module needs some extra openssl initialization which
+	libopenssl internally. But the TLS module needs some extra openssl initialization which
 	is not working when libcurl initializes Openssl by itself.</para>
 	<para>Thanks Samuel ([email protected]) for pointing this out.</para></listitem>
 
@@ -41,7 +41,7 @@ to do this or that, you can:
 <itemizedlist>
 	<listitem><para>Try to search for similar problem in mailing lists on
 	<ulink url="http://www.sip-router.org/">SIP-router's main page</ulink> or in
-	<ulink url="http://lists.kamailio.org/cgi-bin/mailman/listinfo/">list archives</ulink>.
+	<ulink url="https://lists.kamailio.org/mailman3/hyperkitty/">list archives</ulink>.
 	</para></listitem>
 
 	<listitem><para>Send an email to <ulink

doc/tutorials/presence/xcap.xml

@@ -24,7 +24,7 @@ data. From the SIP_ROUTER's point of view these items are interesting:
 <para>Definition of authorization documents and theirs usage is specified in <xref 
 linkend="pres_draft_common_auth"/> and especially for presence purposes in <xref 
 linkend="pres_draft_auth"/>. Both documents are quite common and in SIP_ROUTER's
-presence modules implemented only partialy. For more information about XCAP
+presence modules implemented only partially. For more information about XCAP
 authorization see details in <xref linkend="pa.xcap"/>.</para>
 </section> <!-- XCAP authorization -->
 
@@ -46,7 +46,7 @@ there. Such customer may simply watch presence state of
 
 <para>Lists of users - more common resource lists - are defined in <xref
 linkend="pres_draft_rls"/> and their usage with SIP in <xref
-linkend="pres_draft_rls_sip"/>. These lists are partialy implemented in <link
+linkend="pres_draft_rls_sip"/>. These lists are partially implemented in <link
 linkend="pres_rls">RLS module</link>.
 For more information about resource lists see details in <xref
 linkend="rls.xcap"/>.</para>
@@ -393,7 +393,7 @@ Alias /xcap-root /var/simulated-xcap-root
 
 <example><title>Simple (and dangerous) cgi-script for upload</title>
 <para>This code is written in C and it is able to create directories if needed, but its usage in
-presented form is realy unsafe! You have to compile it and put into directory
+presented form is really unsafe! You have to compile it and put into directory
 with other CGI scripts.</para>
 <programlisting><![CDATA[
 #include <stdio.h>

doc/tutorials/rpc/kamailio_rpc.txt

@@ -38,7 +38,7 @@
    transport independent way (called the rpc module api) and one for
    implementing RPC transports.
 
-   The RPC transports are implemented by writting a RPC transport module.
+   The RPC transports are implemented by writing a RPC transport module.
    The most used transport modules are ctl , xmlrpc and jsonrpc-s .
 
    ctl implements a proprietary fast and space efficient RPC encoding over

doc/tutorials/rpc/kamailio_rpc.xml

@@ -36,16 +36,16 @@
 		for implementing RPC transports.
 	</para>
 	<para>
-		The RPC transports are implemented by writting a RPC
+		The RPC transports are implemented by writing a RPC
 		transport module. The most used transport modules are
-		<ulink url='http://www.kamailio.org/docs/modules/devel/modules/ctl/ctl.html'>
+		<ulink url='https://www.kamailio.org/docs/modules/devel/modules/ctl/ctl.html'>
 		<emphasis>ctl</emphasis>
 		</ulink>,
-		<ulink url='http://www.kamailio.org/docs/modules/devel/modules/xmlrpc/xmlrpc.html'>
+		<ulink url='https://www.kamailio.org/docs/modules/devel/modules/xmlrpc/xmlrpc.html'>
 		<emphasis>xmlrpc</emphasis>
 		</ulink>
 		and
-		<ulink url='http://www.kamailio.org/docs/modules/devel/modules/jsonrpc-s/jsonrpc-s.html'>
+		<ulink url='https://www.kamailio.org/docs/modules/devel/modules/jsonrpc-s/jsonrpc-s.html'>
 		<emphasis>jsonrpc-s</emphasis>
 		</ulink>.
 	</para>
@@ -911,7 +911,7 @@ static void rpc_register(rpc_t* rpc, void *ctx)
 <section id="rpc.xmlrpc_examples">
 	<title>Examples using xmlrpc</title>
 	<para>See the <varname>xmlrpc</varname> module documentation:
-	<ulink url='http://www.kamailio.org/docs/modules/devel/modules/xmlrpc.html'>modules/xmlrpc/README</ulink>.
+	<ulink url='https://www.kamailio.org/docs/modules/devel/modules/xmlrpc.html'>modules/xmlrpc/README</ulink>.
 	</para>
 </section>
 

doc/tutorials/rpc_list/docbook/rpc_malloc_test.xml

@@ -23,7 +23,7 @@ RPC Exports for malloc_test
         one of the other malloc_test functions (e.g. mt.mem_alloc or
         the script mt_mem_alloc). Use b|k|m|g to specify the desired
         size unit. Returns the number of bytes freed (can be higher or
-        smaller then the requested size)
+        smaller than the requested size)
 </para>
 <para>
 </para>

doc/tutorials/rpc_list/rpc_malloc_test.txt

@@ -13,7 +13,7 @@ RPC Exports for malloc_test
         one of the other malloc_test functions (e.g. mt.mem_alloc or
         the script mt_mem_alloc). Use b|k|m|g to specify the desired
         size unit.Returns the number of bytes freed (can be higher or
-        smaller then the requested size)
+        smaller than the requested size)
 
  3. mt.mem_realloc
         Reallocates the specified number of bytes from a pre-allocated

doc/tutorials/ser_radius/ser_radius.xml

@@ -243,7 +243,7 @@ root@localhost"/usr/local/src/freeradius-0.9.1# make install
 		    File <filename>/usr/local/etc/raddb/clients.conf</filename>
 		    contains description of RADIUS clients that are allowed to
 		    use the server. For each of the clients you need to specify
-		    it's hostname or IP address and also a shared secret. The
+		    its hostname or IP address and also a shared secret. The
 		    shared secret must be the same string you configured in
 		    radiusclient library.
 		</simpara>

doc/tutorials/serdev/db_interface.xml

@@ -65,7 +65,7 @@
 	<section id="bind_dbmod">
 	    <title><function>bind_dbmod</function></title>
 	    <para>
-		This function is special, it's only purpose is to call
+		This function is special, its only purpose is to call
 		<function>find_export</function> function in the
 		<acronym>SER</acronym> core and find addresses of all other
 		functions (starting with db_ prefix). This function

doc/tutorials/serdev/hfname_parser.xml

@@ -48,9 +48,9 @@
     <para>
 	We did some performance measurement and 32-bit parsing is about 3 times
 	faster for a typical <acronym>SIP</acronym> message than corresponding
-	automaton comparing byte by byte. Performance may vary depending on the
+	automation comparing byte by byte. Performance may vary depending on the
 	message size, parsed header fields and header fields type. Test showed
-	that it was always as fast as corresponding 1-byte comparing automaton.
+	that it was always as fast as corresponding 1-byte comparing automation.
     </para>
     <para>
 	Since comparison must be case insensitive in case of header field

doc/tutorials/serdev/locking.xml

@@ -34,14 +34,14 @@
 		    compiler knows inline assembly (for example sun cc does
 		    not) FAST_LOCK is preferred. The main advantage of using
 		    FAST_LOCK is very low memory overhead and extremely fast
-		    lock/unlock operations (like 20 times faster then SYSV
+		    lock/unlock operations (like 20 times faster than SYSV
 		    semaphores on linux & 40 times on solaris). The only thing
 		    that comes close to them are pthread mutexes (which are
 		    about 3-4 times slower).
 		</simpara>
 	    </listitem>
 	    <listitem>
-		<simpara><emphasis>PHTREAD_MUTEX</emphasis></simpara>
+		<simpara><emphasis>PTHREAD_MUTEX</emphasis></simpara>
 		<simpara>
 		    Uses pthread_mutex_lock/unlock. They are quite fast but
 		    they work between processes only on some systems (they do
@@ -53,7 +53,7 @@
 		<simpara>
 		    Uses posix semaphores
 		    (<function>sem_wait</function>/<function>sem_post</function>). They
-		    are slower then the previous methods but still way faster
+		    are slower than the previous methods but still way faster
 		    then SYSV semaphores. Unfortunately they also do not work
 		    on all the systems (e.g. linux).
 		</simpara>

doc/tutorials/serdev/modiface.xml

@@ -87,7 +87,7 @@
 	    <structname>cmd_export_t</structname> structure. Structures
 	    describing all exported functions are arranged into an array and
 	    pointer to the array is then passed to the core. The last element
-	    of the array must contain 0 in all it's fields, this element serves
+	    of the array must contain 0 in all its fields, this element serves
 	    as the mark telling the core that this is the very last element and
 	    it must stop scanning the array.
 	</para>
@@ -241,7 +241,7 @@ typedef int (*cmd_function)(struct sip_msg*, char*, char*);
 	    <structname>param_export_t</structname> structure. Structures
 	    describing all exported parameters are arranged into an array and
 	    pointer to the array is then passed to the core. The last element
-	    of the array must contain 0 in all it's fields, this element serves
+	    of the array must contain 0 in all its fields, this element serves
 	    as the mark telling the core that this is the very last element and
 	    it must stop scanning the array (This is same as in array of
 	    exported functions).
@@ -315,7 +315,7 @@ typedef struct param_export_ param_export_t;
 	    <emphasis>after</emphasis> the main process forks. The function
 	    will be called for each child separately. The function should
 	    perform initialization that is specific for each child. For example
-	    each child process might open it's own database connection to avoid
+	    each child process might open its own database connection to avoid
 	    locking of a single connection shared by many processes. Such
 	    connections can be opened in the per-child initialization
 	    function. The function accepts one parameter which is rank

doc/tutorials/serdev/msg_start.xml

@@ -75,7 +75,7 @@ struct msg_start {
 		    <structfield>method_value</structfield> - Parsed
 		    method. Field method which is of type <type>str</type> will
 		    be converted to integer and stored here. This is good for
-		    comparison, integer comparison is much faster then string
+		    comparison, integer comparison is much faster than string
 		    comparison.
 		</para>
 	    </listitem>

doc/tutorials/serdev/select_module.xml

@@ -53,7 +53,7 @@ int <function>select_function_name</function>(str* res, struct select *s, struct
 <para>
 	<emphasis>FIXUP CALL:</emphasis>
 	If you set FIXUP_CALL flag for the final
-	function, the fixup call will be done immediatelly after function resolution.
+	function, the fixup call will be done immediately after function resolution.
 	Such call is indicated with res==NULL &amp;&amp; msg==NULL. Such call can convert any of
 	the select's parameter into internal data (can hold one pointer), if you do
 	that, set param_type to SEL_PARAM_DATA.
@@ -75,7 +75,7 @@ int <function>select_function_name</function>(str* res, struct select *s, struct
 </para>
 <para>The table is representation of tree (or oriented graph if you want), where
 first column represents current (up-to now) resolved function (starting with NULL),
-next two columns define if next parameter is integer or particullar string, next
+next two columns define if next parameter is integer or particular string, next
 column is new resolved function which will be tested in next round and the last
 column is set of flags.
 </para>
@@ -132,7 +132,7 @@ TODO:
 <para>
 	<emphasis>NOTE:</emphasis> The tables are inserted into the beginning of the
 	list, so the core's table (and thus parseable names and definitions) can be
-	overrided by module's function, if it is defined with the same name. To
+	overridden by module's function, if it is defined with the same name. To
 	avoid such situation, the best practice is to start module's select with the
 	module's name. E.g in our example code both select functions start
 	with @test...

doc/tutorials/serdev/startup.xml

@@ -16,7 +16,7 @@
     <para>
 	The <function>main</function> function in file
 	<filename>main.c</filename> is the first function called upon server
-	startup. It's purpose is to initialize the server and enter main
+	startup. Its purpose is to initialize the server and enter main
 	loop. The server initialization will be described in the following
 	sections.
     </para>
@@ -196,7 +196,7 @@
 		Structure of the configuration file is described using
 		grammar. Grammar is a set of rules describing valid 'order' or
 		'combination' of tokens. If the file isn't conformable with
-		it's grammar, it is syntactically invalid and cannot be further
+		its grammar, it is syntactically invalid and cannot be further
 		processed. In that case an error will be issued and the server
 		will be aborted.
 	    </para>
@@ -377,7 +377,7 @@ cmd = "forward" "(" host ")" { $$ = mk_action(FORWARD_T, STRING_ST, NUMBER_ST, $
 			    </para>
 			</listitem>
 			<listitem>
-			    <para>Reply-route statement has it's own array of linked-lists.</para>
+			    <para>Reply-route statement has its own array of linked-lists.</para>
 			</listitem>
 		    </itemizedlist>
 		</para>		    
@@ -685,7 +685,7 @@ module_stm = "loadmodule" STRING
 	    </itemizedlist>
 	    
 	    <para>
-		The following initialization will be performed in dont fork
+		The following initialization will be performed in dont_fork
 		mode.  (look into function <function>main_loop</function> in
 		file <filename>main.c</filename>.
 	    </para>

doc/tutorials/serfaq/serfaq.xml

@@ -1189,7 +1189,7 @@ Warning: 392 216.87.144.203:5060 "Noisy feedback tells:  pid=19604
 		<simpara>
 		    It is possible there are some magic options in domain/usrloc/auth_db/
 		    registrar/auth modules you need to turn on to enable multidomain
-		    operation--I don't remember these by heart, hopefuly some people
+		    operation--I don't remember these by heart, hopefully some people
 		    on the mailing list do.
 		</simpara>
 	    </answer>

doc/tutorials/serhowto/ser-howto.xml

@@ -114,7 +114,7 @@
 		</listitem>
 		<listitem>
 		    <para>
-			bison or yacc (Berkley yacc)
+			bison or yacc (Berkeley yacc)
 		    </para>
 		</listitem>
 		<listitem>
@@ -225,8 +225,8 @@
 export SIP_DOMAIN="foo.bar"
 	    </screen>
 	    <para>
-		If you wont the system to created this variable automatically, you need to add the
-		line
+		If you do not want the system to create this variable automatically, you need
+		to add the line
 	    </para>
 	    <screen>
 export SIP_DOMAIN="foo.bar"
@@ -754,7 +754,7 @@ Up time: 132711 [sec]
 
 Transaction Statistics
 Current: 0 (2 waiting) Total: 46 (0 local)
-Replied localy: 37
+Replied locally: 37
 Completion status 6xx: 0, 5xx: 0, 4xx: 23, 3xx: 0,2xx: 22
 
 Stateless Server Statistics

doc/tutorials/seruser/apps.xml

@@ -715,7 +715,7 @@ From: controller
 To: caller
 SDP: on hold
 
-#2 calling user answes
+#2 calling user answers
 200 OK
 From: controller
 To: caller

doc/tutorials/seruser/intro.xml

@@ -625,9 +625,9 @@ if (uri=~"^sip:[0-79][0-9]*@") { # ... forward to gateways then;
 		<title>Rewriting URIs</title>
 		<programlisting>
 if (uri=~"[email protected]") {
-    rewriteuri("sip:[email protected]")
+    rewriteuri("sip:bla@somewhereelse.com")
     # forward statelessly to the destination in current URI, i.e.,
-    # to sip:bla@somewherelese.com:5060
+    # to sip:bla@somewhereelse.com:5060
     forward( uri:host, uri:port);
 }
 		</programlisting>

doc/tutorials/seruser/otherapps.xml

@@ -80,7 +80,7 @@ Up time: 38481 [sec]
 
 Transaction Statistics
 Current: 0 (0 waiting) Total: 606 (0 local)       
-Replied localy: 34      
+Replied locally: 34      
 Completion status 6xx: 0, 5xx: 1, 4xx: 86, 3xx: 0,2xx: 519      
 
 Stateless Server Statistics

doc/tutorials/sip/sip_introduction.xml

@@ -238,9 +238,9 @@
 		<title>Proxy Server Usage</title>
 		<simpara>
 		    A typical configuration is that each centrally administered entity (a
-		    company, for instance) has it's own SIP proxy server which is used by all
+		    company, for instance) has its own SIP proxy server which is used by all
 		    user agents in the entity. Let's suppose that there are two companies A and
-		    B and each of them has it's own proxy server. <xref linkend="companies"/>
+		    B and each of them has its own proxy server. <xref linkend="companies"/>
 			shows how a session invitation from employee Joe in company A will reach
 			employee Bob in company B.
 		</simpara>
@@ -415,7 +415,7 @@ a=fmtp:101 0-16
 	    identifier and will be described in <xref linkend="sip_dialogs"/>.
 	</simpara>
 	<simpara>
-	    Call-ID header field is a dialog identifier and it's purpose is to identify messages
+	    Call-ID header field is a dialog identifier and its purpose is to identify messages
 	    belonging to the same call. Such messages have the same Call-ID identifier. CSeq is
 	    used to maintain order of requests. Because requests can be sent over an unreliable
 	    transport that can re-order messages, a sequence number must be present in the
@@ -644,7 +644,7 @@ Warning: 392 195.37.77.101:5060 "Noisy feedback tells:
 	    request or response comes, a stateful entity tries to associate the request (or
 	    response) to existing transactions. To be able to do it it must extract a unique
 	    transaction identifier from the message and compare it to identifiers of all
-	    existing transactions. If such a transaction exists then it's state gets updated
+	    existing transactions. If such a transaction exists then its state gets updated
 	    from the message.
 	</simpara>
 	<simpara>

doc/tutorials/tcp_tunning.txt

@@ -65,7 +65,7 @@ net.ipv4.tcp_mem
 net.ipv4.tcp_rmem
 net.ipv4.tcp_wmem
 
-  Note: sysctl -w net.ipv4.route.flush=1 - enusre that immediatly subsequent
+  Note: sysctl -w net.ipv4.route.flush=1 - ensure that immediately subsequent
   connections use the values
 
 1.6 Other sysctl that might affect tcp connection rate or the maximum number

doc/tutorials/timers.txt

@@ -150,7 +150,7 @@ protection mechanism to avoid the above race.
 4.5 timer_allow_del
 -------------------
 
-Marks a timer as "to be deleted when the handler ends", usefull when the timer handler 
+Marks a timer as "to be deleted when the handler ends", useful when the timer handler 
 knows it won't prolong the timer anymore (it will return 0) and will do some time 
 consuming work. Calling this function will cause simultaneous timer_dels to return 
 immediately (they won't  wait anymore for the timer handle to finish).