Module: sip-router Branch: master Commit: 61b81832cb4eacc82b0c711c686f85c09e62be7c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=61b8183… Author: Marius Zbihlei &lt;marius.zbihlei(a)1and1.ro&gt; Committer: Marius Zbihlei &lt;marius.zbihlei(a)1and1.ro&gt; 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>