modules: readme files regenerated - benchmark ... [skip ci]

src/modules/benchmark/README

@@ -415,7 +415,7 @@ Chapter 2. Developer Guide
 
 1.1.  bm_register(name, mode, id)
 
-   This function register a new timer and/or returns the internal ID
+   This function registers a new timer and/or returns the internal ID
    associated with the timer. mode controls the creation of new timer if
    not found. id is to be used by start and log timer functions.
 

src/modules/carrierroute/README

@@ -235,7 +235,7 @@ Chapter 1. Admin Guide
    function to predictable destinations. The hash source is configurable,
    two different hash functions are available.
 
-   This modules scales up to more than a few million users, and is able to
+   This module scales up to more than a few million users, and is able to
    handle more than several hundred thousand routing table entries. We
    received reports of some setups that used more than a million routing
    table entries. It also supports a large number of carriers and domains
@@ -246,9 +246,9 @@ Chapter 1. Admin Guide
 
    Routing tables can be reloaded and edited (in config file mode) with
    the RPC interface, the config file is updated according to the changes.
-   This is not implemented for the db interface, because its easier to do
-   the changes directly on the db. But the reload and dump functions work
-   of course here as well.
+   This is not implemented for the db interface, because it is easier to
+   do the changes directly on the db. But the reload and dump functions
+   work of course here as well.
 
    Some module functionality is not fully available in the config file
    mode, as it is not possible to specify all information that can be
@@ -285,8 +285,8 @@ Chapter 1. Admin Guide
    The following module must be loaded before this module:
      * a database module, when a database is used as configuration data
        source. Only SQL based databases are supported, as this module
-       needs the capability to issue raw queries. Its not possible to use
-       the dbtext or db_berkeley module at the moment.
+       needs the capability to issue raw queries. It is not possible to
+       use the dbtext or db_berkeley module at the moment.
      * The tm module, when you want to use the $T_reply_code
        pseudo-variable in the “cr_next_domain” function.
 
@@ -518,7 +518,7 @@ cr_tree_rewrite_uri(tree, domain)
        a string any pseudo-variable could be used as input.
      * domain - Name of the routing domain to be used. Additional to a
        string any pseudo-variable could be used as input.
-     * dstvar - Name of the writaable config variable (e.g., an AVP) where
+     * dstvar - Name of the writable config variable (e.g., an AVP) where
        to store the carrier id.
 
 4.2.  cr_route(carrier, domain, prefix_matching, rewrite_user, hash_source,
@@ -963,7 +963,7 @@ domain register {
    gateways. For any (failure) reply code the respective next domain is
    chosen. After that no more failure routes are available, an error will
    be returned from the “cr_next_domain” function. Not all table columns
-   are show here for brevity.
+   are shown here for brevity.
 
    For each failure route domain and carrier that is added to the
    carrierfailureroute table there must be at least one corresponding
@@ -995,7 +995,7 @@ domain register {
    and has call-forwarding deactivated. In order to use the routing that
    is specified above, a matching carrierroute table must be provided,
    that holds domain entries for this routing rules. Not all table columns
-   are show here for brevity.
+   are shown here for brevity.
 
    Example 1.20. Example database content - carrier_name table
 ...
@@ -1166,7 +1166,7 @@ modparam("carrierroute", "carrierroute_mask_col", "mask")
    probabilities for a given prefix, tree and domain don't add to 100%,
    the prefix values will be adjusted according the given prob values.
    E.g. if three hosts with prob values of 0.5, 0.5 and 0.4 are defined,
-   the resulting probabilities are 35.714, 35.714 and 28.571%. But its
+   the resulting probabilities are 35.714, 35.714 and 28.571%. But it is
    better to choose meaningful values in the first place because of
    clarity.
 

src/modules/cdp/README

@@ -353,7 +353,7 @@ if(!cdp_has_app("16777216")) {
 
 6.2. cdp.enable_peer
 
-   enabe/re-enable a diameter peer
+   enable/re-enable a diameter peer
 
 7. Configuration Examples
 
@@ -858,7 +858,7 @@ AAA_AVPCode avpCode, AAAVendorId vendorId, AAASearchType searchType)
 
    Meaning of the parameters is as follows:
      * AAAMessage *msg - the message to search in
-     * AAA_AVP *startAvp - at which AVP to start the search. usefull for
+     * AAA_AVP *startAvp - at which AVP to start the search. Useful for
        looking for more of the same name
      * AAA_AVPCode avpCode - AVP code to match
      * AAAVendorId vendorId - AVP vendor ID to match

src/modules/cnxcc/README

@@ -360,7 +360,7 @@ kamcmd cnxcc.active_clients
 
 5.2. cnxcc.check_client
 
-   Retrives all calls from a particular identifier.
+   Retrieves all calls from a particular identifier.
 
    Parameters: client/customer identifier
 

src/modules/corex/README

@@ -545,7 +545,7 @@ setxflag("$var(flag)");
 
 4.13. isxflagset(flag)
 
-   Return true of the extended message (transaction) flag is set.
+   Return true if the extended message (transaction) flag is set.
 
    Meaning of the parameters is as follows:
      * flag - the index of the flag to be tested. Can be integer or

src/modules/cplc/README

@@ -444,7 +444,7 @@ modparam("cplc","ignore3xx",1)
    There is no guaranty that the CPL script interpretation ended when
    Kamailio script ended also (for the same INVITE ;-)) - this can happen
    when the CPL script does a PROXY and the script interpretation pause
-   after proxying and it will be resume when some reply is received (this
+   after proxying and it will be resumed when some reply is received (this
    can happen in a different process of SER). If the function returns to
    script, the SIP server should continue with the normal behavior as if
    no script existed. When some error is returned, the function itself
@@ -475,7 +475,7 @@ modparam("cplc","ignore3xx",1)
        script (script processing can continue in stateful mode);
        is_stateless is the fastest and less resources consumer
        (transaction is created only if proxying is done), but there is
-       minimal protection against retransmissions (since replies are send
+       minimal protection against retransmissions (since replies are sent
        stateless); force_stateful is a good compromise - all signaling is
        done stateful (retransmission protection) and in the same time, if
        returning to script, it will be in stateless mode (easy to continue
@@ -496,15 +496,15 @@ cpl_run_script("incoming","force_stateful");
    the current REGISTER request is related or not with CPL script
    upload/download/ remove. If it is, all the needed operation will be
    done. For checking if the REGISTER is CPL related, the function looks
-   fist to "Content-Type" header. If it exists and has a the mime type set
-   to "application/cpl+xml" means this is a CPL script upload/remove
+   first to "Content-Type" header. If it exists and has a the mime type
+   set to "application/cpl+xml" means this is a CPL script upload/remove
    operation. The distinction between to case is made by looking at
    "Content-Disposition" header; id its value is "script;action=store",
    means it's an upload; if it's "script;action=remove", means it's a
    remove operation; other values are considered to be errors. If no
-   "Content-Type" header is present, the function looks to "Accept" header
-   and if it contains the "*" or "application/cpl-xml" the request it will
-   be consider one for downloading CPL scripts. The functions returns to
+   "Content-Type" header is present, the function looks for "Accept"
+   header and if it contains "*" or "application/cpl-xml" the request will
+   be considered for downloading CPL scripts. The functions returns to
    script only if the REGISTER is not related to CPL. In other case, the
    function will send by itself the necessary replies (stateless - using
    sl), including for errors.

src/modules/enum/README

@@ -308,7 +308,7 @@ enum_pv_query("$avp(i:100)","e164.arpa.","+sip+voice:sip");
 4.3.  i_enum_query(["suffix" [,"service"]])
 
    The function performs an enum query and rewrites the Request-URI with
-   the result of the query. This the Infrastructure-ENUM version of
+   the result of the query. This is the Infrastructure-ENUM version of
    enum_query(). The only difference to enum_query() is in the calculation
    of the FQDN where NAPTR records are looked for.
 

src/modules/evapi/README

@@ -276,7 +276,7 @@ modparam("evapi", "wait_increase", 1)
 evapi_relay("{ \"event\": \"test\",\n \"data\": { \"fU\": \"$fU\" }\n}");
 ...
 
-   The above exaple will send the following message over tcp:
+   The above example will send the following message over tcp:
 
    Example 1.9. TCP message
 ...

src/modules/htable/README

@@ -480,7 +480,7 @@ $ kamcmd htable.dump htable
        can be stored in a hash table, as long as there is enough free
        shared memory, new items can be added.
      * autoexpire -time in seconds to delete an item from a hash table if
-       no update was done to it. If is missing or set to 0, the items
+       no update was done to it. If it is missing or set to 0, the items
        won't expire.
      * dbtable - name of database to be loaded at startup in hash table.
        If empty or missing, no data will be loaded.
@@ -769,7 +769,7 @@ sht_print();
 4.2.  sht_rm(htname, itname)
 
    Delete the item with the name 'itname' from hash table 'htname'. This
-   API function equivaluent to '$sht(htname=>itname) = $null'.
+   API function is equivalent to '$sht(htname=>itname) = $null'.
 
    This function can be used from ANY_ROUTE.
 
@@ -1232,10 +1232,10 @@ kamcmd htable.seti test x[0] 123
 
    Example:
 ...
-# set  expire for $sht(test=>x) to 120 secs
+# set expire for $sht(test=>x) to 120 secs
 kamctl rpc htable.setex test x 120
 
-# set  expire for $sht(test=>10) to 120 secs
+# set expire for $sht(test=>10) to 120 secs
 kamctl rpc htable.setex test s:10 120
 ...
 

src/modules/http_async_client/README

@@ -412,8 +412,8 @@ route[HTTP_REPLY] {
 5. Pseudo Variables
 
    The $http_req_id read-only variable can be used in REQUEST_ROUTE to
-   retrive the unique identifier for a query after sending it or in the
-   HTTP callback route to retrive the id of the query the reply belongs
+   retrieve the unique identifier for a query after sending it or in the
+   HTTP callback route to retrieve the id of the query the reply belongs
    to. Useful mainly in non-transactional context.
 
    Example 1.17. $http_req_id variable usage

src/modules/http_client/README

@@ -197,7 +197,7 @@ Chapter 1. Admin Guide
    HTTP sessions in a simple way. A connection has one or multiple servers
    and a set of settings that apply to the specific connection.
 
-   The http_client module has multiple settings, some of them applies to a
+   The http_client module has multiple settings, some of them apply to a
    defined connection. You can set timeouts, max data sizes for download
    and much more either using modparam settings or parameters to the
    connection definition.
@@ -216,9 +216,9 @@ Chapter 1. Admin Guide
    ported from the utils module and now use the same libcurl functions. We
    recommend using the new functionality provided by this module.
 
-   The http_client module use the CURL library setting up connections. The
-   CURL library by default use the system configured DNS resolvers, not
-   the Kamailio resolver.
+   The http_client module uses the CURL library setting up connections.
+   The CURL library by default use the system configured DNS resolvers,
+   not the Kamailio resolver.
 
    The module is limited to using HTTP and HTTPS protocols.
 
@@ -700,7 +700,7 @@ modparam("http_client", "netinterface", "eth0")
 
    Example 1.22. http_connect() usage
 ...
-modparam("http_client", "httpcon", "apiserver=>http://kamailio.org/api/");
+modparam("http_client", "httpcon", "apiserver=>https://kamailio.org/api/");
 ...
 # POST Request
 $var(res) = http_connect("apiserver", "/mailbox", "application/json", "{ ok, {20
@@ -741,7 +741,7 @@ xlog("L_INFO", "API-server HTTP connection: $avp(route) Result code $var(res)\n"
 
    Example 1.23. http_connect_raw() usage
 ...
-modparam("http_client", "httpcon", "apiserver=>http://kamailio.org/api/");
+modparam("http_client", "httpcon", "apiserver=>https://kamailio.org/api/");
 ...
 # POST Request
 $var(res) = http_connect_raw("apiserver", "/mailbox", "application/json", "{ ok,
@@ -790,7 +790,7 @@ http_get_redirect("apiserver", "$var(targeturl)");
    If HTTP server returns a class 2xx, 3xx or 4xx reply, the first line or
    the entire reply body (if any) is stored in “result” parameter, which
    must be a writable pseudo variable. See the query_result parameter for
-   controling what value to be stored in the result variable.
+   controlling what value to be stored in the result variable.
 
    Function returns reply code of HTTP reply or -1 if something went
    wrong.

src/modules/rtpengine/README

@@ -2114,7 +2114,9 @@ rtpengine_offer();
             default action is rtpengine persists call to redis.
           + force-answer - force “answer”, that is, only rewrite SDP when
             corresponding session already exists in the RTP proxy. By
-            default is on when the session is to be completed.
+            default is on when the session is to be completed. This is
+            only necessary when the offer was sent by rtpengine_offer(),
+            and the answer is handled by rtpengine_manage().
           + direction=... - this option specifies a logical network
             interface and should be given exactly twice. It enables RTP
             bridging between different addresses or networks of the same
@@ -2205,10 +2207,10 @@ rtpengine_offer();
             of the SDP. If none of them are specified, the protocol given
             in the SDP is left untouched. Otherwise, the “SRTP” flag
             indicates that SRTP should be used, while “RTP” indicates that
-            SRTP should not be used. “AVPF” indicates that the advanced
-            RTCP profile with feedback messages should be used, and “AVP”
-            indicates that the regular RTCP profile should be used. See
-            also the next set of flags below.
+            both SRTP and AVPF should not be used. “AVPF” indicates that
+            the advanced RTCP profile with feedback messages should be
+            used, and “AVP” indicates that the regular RTCP profile should
+            be used. See also the next set of flags below.
           + RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVP, RTP/AVPF, RTP/SAVPF,
             UDP/TLS/RTP/SAVPF - these serve as an alternative, more
             explicit way to select between the different RTP protocols and