diff --git a/src/modules/db_cluster/README b/src/modules/db_cluster/README
index 4e52d0ab242..bddaa5d3b4b 100644
--- a/src/modules/db_cluster/README
+++ b/src/modules/db_cluster/README
@@ -197,7 +197,8 @@ modparam("db_cluster", "max_query_length", 5)
 modparam("db_cluster", "connection",
              "c1=>mysql://kamailio:kamailiorw@localhost/kamailio1")
 modparam("db_cluster", "connection",
-             "c2=>mysql://kamailio:kamailiorw@localhost/kamailio2")
+             "c2=>mysql://kamailio:kamailiorw@remotehost/kamailio2")
+
 modparam("db_cluster", "cluster", "k1=>c1=9r9p;c2=9r9p")
 
 modparam("acc", "db_url", "cluster://k1")
diff --git a/src/modules/dmq/README b/src/modules/dmq/README
index 1e7d6ff375d..b79a6c2759b 100644
--- a/src/modules/dmq/README
+++ b/src/modules/dmq/README
@@ -28,6 +28,9 @@ Charles Chance
    1. Admin Guide
 
         1. Overview
+
+              1.1. KDMQ Request
+
         2. Dependencies
 
               2.1. Kamailio Modules
@@ -99,6 +102,9 @@ Chapter 1. Admin Guide
    Table of Contents
 
    1. Overview
+
+        1.1. KDMQ Request
+
    2. Dependencies
 
         2.1. Kamailio Modules
@@ -131,6 +137,8 @@ Chapter 1. Admin Guide
 
 1. Overview
 
+   1.1. KDMQ Request
+
    The DMQ module implements a distributed message queue on top of
    Kamailio in order to facilitate data propagation and replication
    between multiple instances, referred as "nodes" (or "peers").
@@ -161,11 +169,21 @@ Chapter 1. Admin Guide
    the from local list of active nodes, no longer being considered to be
    part of the KDMQ cluster.
 
-   Example 1.1. KDMQ Request Example
+   IMPORTANT: DMQ must be used only between Kamailio instances having same
+   major version. Internal structures can be incompatible between
+   different major versions and can lead to crashes or unexpected
+   behaviour.
+
+1.1. KDMQ Request
+
+   KDMQ messages can have different format and content for R-URI username,
+   headers and body, being specific to each component that leverages DMQ
+   to replicate data, such as htable, dialog or usrloc modules.
 
-   This request is generated for DMQ peers availability notifications.
-   Other messages can be produced by various modules, with different R-URI
-   username and body content, such as htable, dialog or usrloc modules.
+   Next request is generated by DMQ module for peers availability
+   notifications.
+
+   Example 1.1. KDMQ Request Example
 ...
 
 KDMQ sip:notification_peer@192.168.40.15:5090 SIP/2.0
diff --git a/src/modules/nathelper/README b/src/modules/nathelper/README
index 0fa395da200..45da8bc54d6 100644
--- a/src/modules/nathelper/README
+++ b/src/modules/nathelper/README
@@ -706,9 +706,11 @@ if(is_rfc1918("$rd")) {
 5.9.  set_contact_alias([trim])
 
    Adds an “;alias=ip~port~transport” parameter to the contact URI
-   containing the received ip, port, and transport protocol. The new
-   contact URI is immediately visible to other modules in the way the
-   fix_nated_contact() does it.
+   containing the received ip, port, and transport protocol. The update of
+   contact URI is signaled to a few other modules in the way the
+   fix_nated_contact() does it by using the internal flags. The new value
+   is not visible to pseudo-variables and it does not change the SIP
+   message buffer.
 
    Meaning of parameters:
      * trim - by default, set_contact_alias() will not detect and trim an
diff --git a/src/modules/ratelimit/README b/src/modules/ratelimit/README
index ecd6fce79a1..4862e717f73 100644
--- a/src/modules/ratelimit/README
+++ b/src/modules/ratelimit/README
@@ -514,5 +514,5 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
 
    The pipes and queues are stored as static vectors, so no more than
    MAX_PIPES/MAX_QUEUES can be added without recompilation.
-     * MAX_PIPES - 16
-     * MAX_QUEUES - 10
+     * MAX_PIPES - 32
+     * MAX_QUEUES - 32
diff --git a/src/modules/sipdump/README b/src/modules/sipdump/README
index fc573660060..d542772a5e3 100644
--- a/src/modules/sipdump/README
+++ b/src/modules/sipdump/README
@@ -303,7 +303,7 @@ modparam("rtimer", "timer", "name=tjobs;interval=300;mode=1;")
 modparam("rtimer", "exec", "timer=tjobs;route=TCLEAN")
 ...
 route[TCLEAN] {
-    exec_cmd("find /tmp -type f -name kamailio-sipdump-* -mtime +1 -delete &");
+    exec_cmd("find /tmp -type f -name kamailio-sipdump-* -mtime +2 -delete &");
 }
 ...
 
diff --git a/src/modules/tm/README b/src/modules/tm/README
index 0b0d385a3e9..9d28018f0a5 100644
--- a/src/modules/tm/README
+++ b/src/modules/tm/README
@@ -144,7 +144,7 @@ Daniel-Constantin Mierla
               5.1. tm.list
               5.2. tm.t_uac_start
               5.3. tm.t_uac_wait
-              5.4. tm.t_uac_wait
+              5.4. tm.t_uac_wait_block
               5.5. tm.cancel
               5.6. tm.hash_stats
               5.7. tm.reply
@@ -404,7 +404,7 @@ Chapter 1. Admin Guide
         5.1. tm.list
         5.2. tm.t_uac_start
         5.3. tm.t_uac_wait
-        5.4. tm.t_uac_wait
+        5.4. tm.t_uac_wait_block
         5.5. tm.cancel
         5.6. tm.hash_stats
         5.7. tm.reply
@@ -2975,7 +2975,7 @@ t_clean();
    5.1. tm.list
    5.2. tm.t_uac_start
    5.3. tm.t_uac_wait
-   5.4. tm.t_uac_wait
+   5.4. tm.t_uac_wait_block
    5.5. tm.cancel
    5.6. tm.hash_stats
    5.7. tm.reply
@@ -3010,7 +3010,7 @@ t_clean();
    Similar to tm.t_uac_start, but waits asynchronously for the SIP
    response and tries to provide its details via RPC response.
 
-5.4.  tm.t_uac_wait
+5.4.  tm.t_uac_wait_block
 
    Similar to tm.t_uac_start, but blocks waiting for the SIP response and
    returns the SIP reply code and reason text via RPC response. It waits
diff --git a/src/modules/topos/README b/src/modules/topos/README
index ef7c0e96344..6c7ef0e3d86 100644
--- a/src/modules/topos/README
+++ b/src/modules/topos/README
@@ -140,11 +140,13 @@ Chapter 1. Admin Guide
    to be loaded (tune the module parameters if needed).
 
    It also works for SIP MESSAGE or other requests that do not create a
-   dialog -- record_route() must be used for them as well, the headers are
-   not going to be in the messages sent to the network, they are needed to
-   know local addresses used to communicate with each side. This module is
-   designed to work for presence (SUBSCRIBE-based) dialogs too. The
-   REGISTER and PUBLISH requests are skipped from processing by this
+   dialog (e.g., OPTIONS) -- record_route() must be used for them as well,
+   the headers are not going to be in the messages sent to the network,
+   they are needed to know local addresses used to communicate with each
+   side. This module is designed to work for presence (SUBSCRIBE-based)
+   dialogs too.
+
+   The REGISTER and PUBLISH requests are skipped from processing by this
    module, expected to be terminated on a local SIP server.
 
 2. Dependencies
diff --git a/src/modules/xhttp/README b/src/modules/xhttp/README
index 781ac413927..9a59c839aa1 100644
--- a/src/modules/xhttp/README
+++ b/src/modules/xhttp/README
@@ -131,11 +131,15 @@ Chapter 1. Admin Guide
 
 3.2. Kamailio Core Settings
 
-   SIP requires a Content-Length header for TCP transport. But most HTTP
-   clients do not set the content length for normal GET requests.
-   Therefore, the core must be configured to allow incoming requests
-   without content length header:
-     * tcp_accept_no_cl=yes
+   Related core settings:
+     * tcp_accept_no_cl=yes - SIP requires the Content-Length header for
+       TCP transport. But most HTTP clients do not set the content length
+       for normal GET requests. Therefore, the core must be configured to
+       allow incoming requests without content length header.
+     * http_reply_parse=yes - various Kamailio modules may parse what it
+       is sent out (e.g., for replication, topology management). In such
+       case errors are printed if the outgoing message is not SIP and this
+       parameter is not set.
 
 3.3. External Libraries or Applications