[sr-dev] git:master: Modules_k: usrloc Fixed syntax errors on documentation of modules.

[Marius Zbihlei]

Module: sip-router
Branch: master
Commit: 61b81832cb4eacc82b0c711c686f85c09e62be7c
URL:    http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=61b81832cb4eacc82b0c711c686f85c09e62be7c

Author: Marius Zbihlei <marius.zbihlei at 1and1.ro>
Committer: Marius Zbihlei <marius.zbihlei at 1and1.ro>
Date:   Tue Sep 14 11:42:42 2010 +0300

Modules_k:usrloc Fixed syntax errors on documentation of modules.

---

 modules_k/usrloc/README               |   36 +++++++++++++++++---------------
 modules_k/usrloc/doc/usrloc_admin.xml |   36 ++++++++++++++++----------------
 2 files changed, 37 insertions(+), 35 deletions(-)

diff --git a/modules_k/usrloc/README b/modules_k/usrloc/README
index d6df0ea..f6fd5f7 100644
--- a/modules_k/usrloc/README
+++ b/modules_k/usrloc/README
@@ -199,26 +199,28 @@ Chapter 1. Admin Guide
 1.1. Contact matching
 
    How the contacts are matched (dor same AOR - Address of Record) is an
-   important aspect of the usrloc modules, especialy in the context of NAT
-   traversal - this raise mre problems since contacts from different
-   phones of same users may overlap (if behind NATs with same
-   configuration) or the re-register contact of same phone may be seen as
-   a new one (due different binding via NAT).
+   important aspect of the usrloc module, especially in the context of NAT
+   traversal - this raises more problems since contacts from different
+   phones of the same user may overlap (if behind NATs with same
+   configuration) or the re-register contact of the same phone may be seen
+   as a new one (due different binding via NAT).
 
    The SIP RFC 3261 publishes a matching algorithm based only on the
    contact string with callid and cseq number extra checking (if callid is
-   the same, it must have a higher cseq number, otherwise invalid). But as
-   argumented above, this is not enough in NAT traversal context, so the
-   Kamailio implementation of contact machting offers more algorithms:
-     * contact based only - it strict RFC 3261 compiancy - the contact is
-       matched as string and extra checked via callid and cseg (if callid
-       is the same, it must have a higher cseq number, otherwise invalid).
-     * contact and callid based - it an extension of the first case - the
-       contact and callid must matched as string; the cseg must be higher
-       than the previous one - so be careful how you deal with REGISTER
-       retransmissions in this case.
-     * contact and path based - it an extension of the first case - the
-       contact and path must matched as string; the cseg must be higher
+   the same, it must have a higher cseq number, otherwise it is invalid).
+   But as argumented above, this is not enough in NAT traversal context,
+   so the Kamailio implementation of contact matching offers more
+   algorithms:
+     * contact based only - it is strict RFC 3261 compliancy - the contact
+       is matched as string and extra checked via callid and cseq (if
+       callid is the same, it must have a higher cseq number, otherwise it
+       is invalid).
+     * contact and callid based - it is an extension of the first case -
+       the contact and callid must be matched as string; the cseq must be
+       higher than the previous one - so be careful how you deal with
+       REGISTER retransmissions in this case.
+     * contact and path based - it is an extension of the first case - the
+       contact and path must be matched as string; the cseq must be higher
        than the previous one - so be careful how you deal with REGISTER
        retransmissions in this case.
 
diff --git a/modules_k/usrloc/doc/usrloc_admin.xml b/modules_k/usrloc/doc/usrloc_admin.xml
index 2b6d307..0b03fe2 100644
--- a/modules_k/usrloc/doc/usrloc_admin.xml
+++ b/modules_k/usrloc/doc/usrloc_admin.xml
@@ -24,43 +24,43 @@
 		<title>Contact matching</title>
 		<para>
 		How the contacts are matched (dor same AOR - Address of Record) is an 
-		important aspect of the usrloc modules, especialy in the context of NAT
-		traversal - this raise mre problems since contacts from different 
-		phones of same users may overlap (if behind NATs with same
-		configuration) or the re-register contact of same phone may be
+		important aspect of the usrloc module, especially in the context of NAT
+		traversal - this raises more problems since contacts from different 
+		phones of the same user may overlap (if behind NATs with same
+		configuration) or the re-register contact of the same phone may be
 		seen as a new one (due different binding via NAT).
 		</para>
 		<para>
 		The SIP RFC 3261 publishes a matching algorithm based only on the 
 		contact string with callid and cseq number extra checking (if callid
-		is the same, it must have a higher cseq number, otherwise invalid).
+		is the same, it must have a higher cseq number, otherwise it is invalid).
 		But as argumented above, this is not enough in NAT traversal context, 
-		so the &kamailio; implementation of contact machting offers more algorithms:
+		so the &kamailio; implementation of contact matching offers more algorithms:
 		</para>
 		<itemizedlist>
 			<listitem>
 			<para>
-				<emphasis>contact based only</emphasis> - it strict RFC 3261
-				compiancy - the contact is matched as string and extra checked
-				via callid and cseg (if callid is the same, it must have a 
-				higher cseq number, otherwise invalid).
+				<emphasis>contact based only</emphasis> - it is strict RFC 3261
+				compliancy - the contact is matched as string and extra checked
+				via callid and cseq (if callid is the same, it must have a
+				higher cseq number, otherwise it is invalid).
 			</para>
 			</listitem>
 			<listitem>
 			<para>
-				<emphasis>contact and callid based</emphasis> - it an extension
-				of the first case - the contact and callid must matched as 
-				string; the cseg must be higher than the previous one - so be
-				careful how you deal with REGISTER retransmissions in this 
+				<emphasis>contact and callid based</emphasis> - it is an extension
+				of the first case - the contact and callid must be matched as
+				string; the cseq must be higher than the previous one - so be
+				careful how you deal with REGISTER retransmissions in this
 				case.
 			</para>
 			</listitem>
 			<listitem>
 			<para>
-				<emphasis>contact and path based</emphasis> - it an extension
-				of the first case - the contact and path must matched as 
-				string; the cseg must be higher than the previous one - so be
-				careful how you deal with REGISTER retransmissions in this 
+				<emphasis>contact and path based</emphasis> - it is an extension
+				of the first case - the contact and path must be matched as
+				string; the cseq must be higher than the previous one - so be
+				careful how you deal with REGISTER retransmissions in this
 				case.
 			</para>
 			</listitem>