From a0fac2aaa14a5d4a2054128095cf68d79304d3c2 Mon Sep 17 00:00:00 2001 From: Kamailio Dev Date: Mon, 10 Apr 2023 08:16:28 +0200 Subject: [PATCH] modules: readme files regenerated - benchmark ... [skip ci] --- src/modules/benchmark/README | 2 +- src/modules/carrierroute/README | 20 ++++++++++---------- src/modules/cdp/README | 4 ++-- src/modules/cnxcc/README | 2 +- src/modules/corex/README | 2 +- src/modules/cplc/README | 14 +++++++------- src/modules/enum/README | 2 +- src/modules/evapi/README | 2 +- src/modules/htable/README | 8 ++++---- src/modules/http_async_client/README | 4 ++-- src/modules/http_client/README | 14 +++++++------- src/modules/rtpengine/README | 12 +++++++----- 12 files changed, 44 insertions(+), 42 deletions(-) diff --git a/src/modules/benchmark/README b/src/modules/benchmark/README index 425324d1108..7f2a0a56ece 100644 --- a/src/modules/benchmark/README +++ b/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. diff --git a/src/modules/carrierroute/README b/src/modules/carrierroute/README index 339f9ded48f..8c2db863b86 100644 --- a/src/modules/carrierroute/README +++ b/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. diff --git a/src/modules/cdp/README b/src/modules/cdp/README index ba016e16283..253ec85a4bd 100644 --- a/src/modules/cdp/README +++ b/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 diff --git a/src/modules/cnxcc/README b/src/modules/cnxcc/README index f739b85fbae..62960a6e631 100644 --- a/src/modules/cnxcc/README +++ b/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 diff --git a/src/modules/corex/README b/src/modules/corex/README index be898f0d7fa..99b44554762 100644 --- a/src/modules/corex/README +++ b/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 diff --git a/src/modules/cplc/README b/src/modules/cplc/README index dc1381e8fb2..d6882e14fa2 100644 --- a/src/modules/cplc/README +++ b/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. diff --git a/src/modules/enum/README b/src/modules/enum/README index 1de02049402..73881c095cf 100644 --- a/src/modules/enum/README +++ b/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. diff --git a/src/modules/evapi/README b/src/modules/evapi/README index e87f47169c9..7eddf8c18b1 100644 --- a/src/modules/evapi/README +++ b/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 ... diff --git a/src/modules/htable/README b/src/modules/htable/README index 766f06b2e73..0252b62e030 100644 --- a/src/modules/htable/README +++ b/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 ... diff --git a/src/modules/http_async_client/README b/src/modules/http_async_client/README index a0ff1b5ca16..57eff8a890f 100644 --- a/src/modules/http_async_client/README +++ b/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 diff --git a/src/modules/http_client/README b/src/modules/http_client/README index d0d11e38c18..c3788a1c2cc 100644 --- a/src/modules/http_client/README +++ b/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. diff --git a/src/modules/rtpengine/README b/src/modules/rtpengine/README index 4afdc69fc6a..de4e15310af 100644 --- a/src/modules/rtpengine/README +++ b/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