auth: Documentation corrections

modules/auth/doc/auth.xml

@@ -51,10 +51,10 @@
 	    authentication backends).
 	</para>
 	<para>
-	    We decided to break the authentication code into several modules
+	    We decided to divide the authentication code into several modules
 	    because there are now more than one backends (currently database
 	    authentication and radius are supported). This allows us to create
-	    separate packages so uses can install and load only required
+	    separate packages so users can install and load only the required
 	    functionality. This also allows us to avoid unnecessary
 	    dependencies in the binary packages.
 	</para>

modules/auth/doc/functions.xml

@@ -9,7 +9,7 @@
     <section id="consume_credentials">
 	<title><function>consume_credentials()</function></title>
 	<para>
-	    This function removes previously authorized credentials from the
+	    This function removes previously authorized credential headers from the
 	    message being processed by the server. That means that the
 	    downstream message will not contain credentials there were used by
 	    this server. This ensures that the proxy will not reveal
@@ -73,7 +73,7 @@ if (has_credentials("myrealm")) {
 			</para>
 			<para>
 			It must not be empty string <quote></quote>. In case of REGISTER
-			requests To header field domain (e.g., variable $td) can be used
+			requests, the To header field domain (e.g., variable $td) can be used
 			(because this header field represents the user being registered),
 			for all other messages From header field domain can be used
 			(e.g., variable $fd).
@@ -132,10 +132,10 @@ if (!www_authenticate("$td", "subscriber")) {
 		put the header field into a response generated from the request the
 		server is processing and send the reply. Upon reception of such a
 		reply the user agent should compute credentials and retry the request.
-		For more information regarding digest authentication see RFC2617.    See module parameter force_stateless_reply
-		regarding sending of the reply.
+		For more information regarding digest authentication see RFC2617.
+		See module parameter force_stateless_reply regarding sending of the reply.
 		</para>
-		<para>Meaning of the parameters the same as for function
+		<para>Meaning of the parameters is the same as for function
 		www_challenge(realm, flags)</para>
 		<para>
 		This function can be used from REQUEST_ROUTE.
@@ -160,7 +160,7 @@ if (!proxy_authenticate("$fd", "subscriber")) {
 		The function challenges a user agent for authentication. It combines
 		the functions www_challenge() and proxy_challenge(), by calling
 		internally the first one for REGISTER requests and the second one for
-		the rest of the request types.
+		the rest of other request types.
 		</para>
 		<para>Meaning of the parameters the same as for function
 		www_challenge(realm, flags)</para>
@@ -168,7 +168,7 @@ if (!proxy_authenticate("$fd", "subscriber")) {
 		This function can be used from REQUEST_ROUTE.
 		</para>
 		<example>
-		<title>proxy_challenge usage</title>
+		<title>auth_challenge usage</title>
 		<programlisting format="linespecific">
 ...
 if (!auth_check("$fd", "subscriber", "1")) {
@@ -240,7 +240,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
 		</listitem>
 		<listitem>
 			<para><emphasis>passwd</emphasis> - the password to be used
-			for authentication. Can contain config variables. Username is
+			for authentication. Can contain config variables. The Username is
 			taken from Auth header.</para>
 		</listitem>
 		<listitem>
@@ -278,7 +278,7 @@ if (!auth_check("$fd", "subscriber", "1")) {
 		</itemizedlist>
 		<para>
 			When challenge header is built and stored in avp,
-			append_to_reply() and sl reply functions can be used to send
+			append_to_reply() and the sl reply functions can be used to send
 			appropriate SIP reply to challenge for authentication.
 		</para>
 		<para>
@@ -356,7 +356,7 @@ if (!pv_proxy_authenticate("$fd", "$avp(password)", "0")) {
 		This function can be used from REQUEST_ROUTE.
 		</para>
 		<example>
-		<title>pv_proxy_authenticate usage</title>
+		<title>pv_auth_check usage</title>
 		<programlisting format="linespecific">
 ...
 $avp(password)="xyz";
@@ -370,10 +370,10 @@ if (!pv_auth_check("$fd", "$avp(password)", "0", "1")) {
 
 	<section id="auth_get_www_authenticate">
 		<title>
-			<function moreinfo="none">auth_get_www_authenticate(realm, flags, pvdst)</function>
+			<function moreinfo="none">auth_get_www_authenticate(realm, flags, pvdest)</function>
 		</title>
 		<para>
-		Build WWW-Authentication header and set the resulting value in 'pvdest' parameter.
+		Build WWW-Authentication header and set the resulting value in 'pvdest' pseudo-variable parameter.
 		</para>
 		<para>Meaning of the realm and flags parameters is the same as for
 		pv_www_authenticate(realm, passwd, flags)</para>

modules/auth/doc/params.xml

@@ -13,8 +13,8 @@
 	  <varname>auth_checks_in_dlg</varname> (flags)
 	</title>
 	<para>
-	    These three module parameters control which optional integrity
-         checks will be performed on the SIP message carrying digest response
+	These three module parameters control which optional integrity
+        checks will be performed on the SIP message carrying digest response
         during digest authentication. <varname>auth_check_register</varname>
         controls integrity checks to be performed on REGISTER messages,
         <varname>auth_checks_no_dlg</varname> controls which optional