Module: kamailio
Branch: master
Commit: 2d7aee506c617f2d258719562f8debf2b4ba087e
URL: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2021-04-06T08:38:16+02:00
core/mem: removed tlsf_malloc_bits.h
- no longer needed after sync with v3.1
---
Removed: src/core/mem/tlsf_malloc_bits.h
---
Diff: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
Patch: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
---
diff --git a/src/core/mem/tlsf_malloc_bits.h b/src/core/mem/tlsf_malloc_bits.h
deleted file mode 100644
index 29c783d4a4..0000000000
--- a/src/core/mem/tlsf_malloc_bits.h
+++ /dev/null
@@ -1,119 +0,0 @@
-#ifndef INCLUDED_tlsfbits
-#define INCLUDED_tlsfbits
-
-#if defined(__cplusplus)
-#define tlsf_decl inline
-#else
-#define tlsf_decl static
-#endif
-
-/*
-** Architecture-specific bit manipulation routines.
-**
-** TLSF achieves O(1) cost for malloc and free operations by limiting
-** the search for a free block to a free list of guaranteed size
-** adequate to fulfill the request, combined with efficient free list
-** queries using bitmasks and architecture-specific bit-manipulation
-** routines.
-**
-** Most modern processors provide instructions to count leading zeroes
-** in a word, find the lowest and highest set bit, etc. These
-** specific implementations will be used when available, falling back
-** to a reasonably efficient generic implementation.
-**
-** NOTE: TLSF spec relies on ffs/fls returning value 0..31.
-** ffs/fls return 1-32 by default, returning 0 for error.
-*/
-
-/*
-** Detect whether or not we are building for a 32- or 64-bit (LP/LLP)
-** architecture. There is no reliable portable method at compile-time.
-*/
-#if defined (__alpha__) || defined (__ia64__) || defined (__x86_64__) \
- || defined (_WIN64) || defined (__LP64__) || defined (__LLP64__)
-#define TLSF_64BIT
-#endif
-
-/*
-** gcc 3.4 and above have builtin support, specialized for architecture.
-** Some compilers masquerade as gcc; patchlevel test filters them out.
-**
-** Note: clang is compatible with GCC builtins and will also define those macros
-*/
-#if defined (__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)) \
- && defined (__GNUC_PATCHLEVEL__)
-
-tlsf_decl int tlsf_ffs(unsigned int word)
-{
- return __builtin_ffs(word) - 1;
-}
-
-tlsf_decl int tlsf_fls(unsigned int word)
-{
- const int bit = word ? 32 - __builtin_clz(word) : 0;
- return bit - 1;
-}
-
-#if defined (TLSF_64BIT)
-tlsf_decl int tlsf_fls_sizet(size_t size)
-{
- const int bit = size ? 64 - __builtin_clzl(size) : 0;
- return bit - 1;
-}
-#endif
-#else
-/* Fall back to generic implementation. */
-
-tlsf_decl int tlsf_fls_generic(unsigned int word)
-{
- int bit = 32;
-
- if (!word) bit -= 1;
- if (!(word & 0xffff0000)) { word <<= 16; bit -= 16; }
- if (!(word & 0xff000000)) { word <<= 8; bit -= 8; }
- if (!(word & 0xf0000000)) { word <<= 4; bit -= 4; }
- if (!(word & 0xc0000000)) { word <<= 2; bit -= 2; }
- if (!(word & 0x80000000)) { word <<= 1; bit -= 1; }
-
- return bit;
-}
-
-/* Implement ffs in terms of fls. */
-tlsf_decl int tlsf_ffs(unsigned int word)
-{
- return tlsf_fls_generic(word & (~word + 1)) - 1;
-}
-
-tlsf_decl int tlsf_fls(unsigned int word)
-{
- return tlsf_fls_generic(word) - 1;
-}
-
-#if defined (TLSF_64BIT)
-tlsf_decl int tlsf_fls_sizet(size_t size)
-{
- int high = (int)(size >> 32);
- int bits = 0;
- if (high)
- {
- bits = 32 + tlsf_fls(high);
- }
- else
- {
- bits = tlsf_fls((int)size & 0xffffffff);
-
- }
- return bits;
-}
-#endif /* defined (TLSF_64BIT) */
-
-#endif /* GNUC */
-
-
-#if !defined (TLSF_64BIT)
-#define tlsf_fls_sizet tlsf_fls
-#endif
-
-#undef tlsf_decl
-
-#endif
### Description
It doesn't look like the "pua_dialoginfo" module has support for the "display" attribute in the identity tag. This tag is used by some phones to update the phone display with caller/callee information for the respective key. I'm wondering how difficult it would be to add this feature. Thanks in advance for anyone who reads this!
### Expected behavior
Kamailio includes display attribute in identity tags in generated publish messages.
<pre>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full">
<dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766" direction="initiator">
<state>early</state>
<local>
<identity <b><i>display="Alice"</i></b>>sip:alice@example.com</identity>
<target uri="sip:alice@phone11.example.com"/>
</local>
<remote>
<identity <b><i>display="Bob"</i></b>>sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
</pre>
#### Actual observed behavior
Kamailio generates a publish request for dialog events similar to the one below. The display attribute is not included in the "identity" tags. This means that when a notify message is sent to a watcher for this publish, the name is not rendered on the phone display.
<pre>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full">
<dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766" direction="initiator">
<state>early</state>
<local>
<b><identity>sip:alice@example.com</identity></b>
<target uri="sip:alice@phone11.example.com"/>
</local>
<remote>
<b><identity>sip:bob@example.org</identity></b>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
</pre>
### Possible Solutions
I added a small modification to the module as a POC and it works as expected. With the following modification, the phone display is updated with the string in the “display” attribute. I added line 191-193 below, between lines 190 & 191 on the current master branch. The example below shows the “remote” tag, I also did the same thing for the local tag a few more lines down.
<pre>
184 tag_node = xmlNewChild(remote_node, NULL, BAD_CAST "identity",
185 BAD_CAST buf) ;
186 if( tag_node ==NULL)
187 {
188 LM_ERR("while adding childn");
189 goto error;
190 }
191 /* Testing - adding display attribute to the identity tag */
192 xmlNewProp(tag_node, BAD_CAST "display", BAD_CAST "RemoteCallerName");
193 /* */
195
196 tag_node = xmlNewChild(remote_node, NULL, BAD_CAST "target", NULL);
197 if( tag_node ==NULL)
</pre>
Here is a link to the file in the module I’m referring to:
https://github.com/kamailio/kamailio/blob/master/src/modules/pua_dialoginfo…
I don’t really have any professional experience writing C code, and I was unable to identify a way to grab this string from the “From” header. Unfortunately, because I would have really loved to give this feature back to the community!
### Additional Information
Thank you so much for this amazing software. I absolutely adore Kamailio! If someone is interested in this, please let me know if there is anything I can do to help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2615
### Description
I think something wrong with integer comparison when tested this config file
```
listen=udp:[::1]:5060
listen=udp:127.0.0.1:5060
loadmodule "xlog.so"
loadmodule "sdpops.so"
request_route {
if (sdp_get_address_family() ieq 6 ) {
xlog("L_WARN", "sdp_get_address_family == 6\n");
} else if (sdp_get_address_family() ieq 4) {
xlog("L_WARN", "sdp_get_address_family == 4\n");
} else if (sdp_get_address_family() ieq 1) {
xlog("L_WARN", "cannot detect sdp family\n");
}
}
```
The expected output of IP address type used in SDP. But really I always get "cannot detect sdp family" message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2701
### Description
As admin, I want check TLS encrypted call signaling on local Kamailio.
To do this I can use [this instruction](https://voipembedded.wordpress.com/2021/03/22/troubleshooting-….
Here used `siptrace` module.
But at the same time, I need to send the same call signaling to the company `Homer` server.
So I need to send a copy of the call signaling in two directions.
Could you add the ability to allow specify multiple values in `duplicate_uri` param like.
```
modparam("siptrace", "duplicate_uri", "<sip:127.0.0.1:9060>,<sip:homer.example.com:9060>")
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2693
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [x] New feature (non-breaking change which adds new functionality)
#### Description
New parameter to add json in an accounting/CDR field and prevent unwanted json escaping.
Example:
```
modparam("acc_json", "acc_extra", "json_data=$avp(json_data);")
modparam("acc_json", "acc_json_pre_encoded_prefix", "json_")
...
$avp(json_data) = '{"b":2, "c":3}';
...
```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2699
-- Commit Summary --
* acc_json: param to accept pre-encoded json values
-- File Changes --
M src/modules/acc_json/acc_json_mod.c (55)
M src/modules/acc_json/doc/acc_json_admin.xml (43)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2699.patchhttps://github.com/kamailio/kamailio/pull/2699.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2699
### Description
We tried to load share 50+ media servers using dispatching algorithm 11 and faced an unexpected behavior when most calls go to very first host in the group.
### Troubleshooting
I tried to start Kamailio like this:
sudo kamailio -f /etc/kamailio/kamailio.cfg -E -d 5 -u 995
but errors were the same when dispatcher group had more than 25 and less than 25 hosts
It was tried different combinations of dispatcher list host group configuration:
100 sip:10.60.27.123:7000 10 rweight=50
100 sip:10.60.27.123:7000 10 weight=50;rweight=50
100 sip:10.60.27.123:7000 rweight=50,maxload=80
When making 100 calls the quarter of them go to the first host in the group.
#### Reproduction
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes", "501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
Dispatcher group must have more than 25 hosts, if equal or less than 25 than it is Ok:
100 sip:10.60.27.123:7000 0 10 rweight=50
100 sip:10.60.27.123:7001 0 10 rweight=50
100 sip:10.60.27.123:7002 0 10 rweight=50
100 sip:10.60.27.123:7003 0 10 rweight=50
100 sip:10.60.27.123:7004 0 10 rweight=50
100 sip:10.60.27.123:7005 0 10 rweight=50
100 sip:10.60.27.123:7006 0 10 rweight=50
100 sip:10.60.27.123:7007 0 10 rweight=50
100 sip:10.60.27.123:7008 0 10 rweight=50
100 sip:10.60.27.123:7009 0 10 rweight=50
100 sip:10.60.27.123:7010 0 10 rweight=50
100 sip:10.60.27.123:7011 0 10 rweight=50
100 sip:10.60.27.123:7012 0 10 rweight=50
100 sip:10.60.27.123:7013 0 10 rweight=50
100 sip:10.60.27.123:7014 0 10 rweight=50
100 sip:10.60.27.123:7015 0 10 rweight=50
100 sip:10.60.27.123:7016 0 10 rweight=50
100 sip:10.60.27.123:7017 0 10 rweight=50
100 sip:10.60.27.123:7018 0 10 rweight=50
100 sip:10.60.27.123:7019 0 10 rweight=50
100 sip:10.60.27.123:7020 0 10 rweight=50
100 sip:10.60.27.123:7021 0 10 rweight=50
100 sip:10.60.27.123:7022 0 10 rweight=50
100 sip:10.60.27.123:7023 0 10 rweight=50
100 sip:10.60.27.123:7024 0 10 rweight=50
To emulate call load and multiple media servers, SIPp scenarios were used.
#### Debugging Data
#### Log Messages
#### SIP Traffic
No specific traffic, regular INVITE messages having international numbers.
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
```
* **Operating System**:
```
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.prd.tc5.ams.nl.kwebbl.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2698
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Hi Maintainers,
I have worked a bit on setting fuzzing up for Kamailio by way of OSS-Fuzz. Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects, and it would be great to have Kamailio integrated. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.
In this PR https://github.com/google/oss-fuzz/pull/5279 I have done exactly that, namely created the necessary logic from an OSS-Fuzz perspective to integrate Kamailio. If you would like to integrate, could you please provide a set of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. The emails should be linked to a Google account in order to view the detailed reports and notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.
At the moment I stored the fuzzers in the Google OSS-Fuzz repository, but we can move them up here to make maintenance easier.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2660
-- Commit Summary --
* Adds initial fuzzer for integration with oss-fuzz.
-- File Changes --
A fuzz/fuzz_uri.c (8)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2660.patchhttps://github.com/kamailio/kamailio/pull/2660.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2660
### Description
Carrierroute module takes now 16 minutes to load about 50'000 entries from postgres-db.
In version 5.0.3 it was 10 seconds from the same db.
### Troubleshooting
#### Reproduction
Install kamailio 5.0.3 and fill your carrierroute table with thousands of entries. See how fast its loaded.
Then install 5.0.4 and see how long it takes now.
You can observe the query "SELECT * FROM carrierroute WHERE carrier=1 and domain=1 and prob>0" multiple times in the postgres-db log.
#### Debugging Data
none.
#### Log Messages
not needed.
#### SIP Traffic
not needed.
### Possible Solutions
Perhaps try to do the check "in-memory" instead generate a new sql-query.
### Additional Information
This bug exists in Kamilio versions >=5.0.4 and is (potentially) introduced by:
commit 9800aba65146b72623bb512049300d1beb8c8ec4
Author: Huseyin Dikme <hueseyin.dikme(a)1und1.de>
Date: Tue Sep 12 15:37:17 2017 +0200
carrierroute: warning for the same carrier/domain having routes with only 0 probability
- While starting kamailio or reloading the routes, if the same carrier/domain pairs do not have
any route with a probability other than 0 (zero) then an error log will be printed on the screen.
Besides, the log "invalid dice_max value" in the cr_func.c has been made more clear.
(cherry picked from commit 9741bee7af8136b35af8e6279e530aa0ad54f574)
* **Operating System**:
Ubuntu 20.04.2 LTS
Linux 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2653
### Description
Could you extend `import_file` directive to support wildcards like
```
import_file "/run/kamailio/cfg/*"
```
This will allow place runtime config files with public IP of VM. Useful for cloud installation.
```
listen=udp:eth0 advertise 52.24.72.57:5060
listen=tcp:eth0 advertise 52.24.72.57:5060
```
### Expected behavior
All files matched to wildcard included into config
#### Actual observed behavior
wildcard ignored
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2125
### Description
We have some JS code looping over all P-Asserted-Identity headers removing some of the entries:
```
let headerIndex = 0;
const telUriMatcher = new RegExp("tel:");
let paiValue = ksr.pv
.gete("$(hdr(P-Asserted-Identity)[" + headerIndex + "])")
.toString();
while (paiValue.length > 0) {
ksr.info(
`${ksr.pv.getw("$ci")}: Found P-A-I header with content <${ksr.pv.getw(
"$(hdr(P-Asserted-Identity)[" + headerIndex + "])"
)}> at index ${headerIndex}\n`
);
if (telUriMatcher.test(paiValue)) {
ksr.info(
`${ksr.pv.getw("$ci")}: Removed P-A-I header ${ksr.pv.getw(
"$(hdr(P-Asserted-Identity)[" + headerIndex + "])"
)}\n`
);
ksr.textopsx.remove_hf_value(
"P-Asserted-Identity[" + headerIndex + "]"
);
}
headerIndex++;
paiValue = ksr.pv
.gete("$(hdr(P-Asserted-Identity)[" + headerIndex + "])")
.toString();
}
```
In our tests, we wanted to remove the second header, but the first one got removed instead. The pseudovars docs say, the index of a header is 0-based. In textopsx docs it doesn't explicitly say, it's 1-based, but the first example shows it actually is.
### Possible Solutions
Right now, we replaced the line
```
ksr.textopsx.remove_hf_value("P-Asserted-Identity[" + headerIndex + "]");
```
with this one:
```
ksr.textopsx.remove_hf_value("P-Asserted-Identity[" + (headerIndex + 1) + "]");
```
This solves the problem, but it is not what we would expect. Both header access methods should use the same index base.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.3.5 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 8.3.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
Linux hostname 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2387
Module: kamailio
Branch: master
Commit: ac60e5d0a9f847fe77458d733d6ca67c9352978d
URL: https://github.com/kamailio/kamailio/commit/ac60e5d0a9f847fe77458d733d6ca67…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2021-03-31T16:16:15+02:00
modules: readme files regenerated - textopsx ... [skip ci]
---
Modified: src/modules/textopsx/README
---
Diff: https://github.com/kamailio/kamailio/commit/ac60e5d0a9f847fe77458d733d6ca67…
Patch: https://github.com/kamailio/kamailio/commit/ac60e5d0a9f847fe77458d733d6ca67…
---
diff --git a/src/modules/textopsx/README b/src/modules/textopsx/README
index 772461ae54..dbb27653a0 100644
--- a/src/modules/textopsx/README
+++ b/src/modules/textopsx/README
@@ -246,7 +246,7 @@ if(fnmatch("$rU", "123*"))
Meaning of the parameters is as follows:
* hf - Header field to be appended. Format: HFNAME [ [IDX] ]. If
index is not specified new header is inserted at the end of
- message.
+ message. The index 1 correxponds to the first header.
* hvalue - Value to be added, config var formatting supported.
Example 1.7. append_hf_value usage
@@ -267,7 +267,7 @@ ot exists add new header
Meaning of the parameters is as follows:
* hf - Header field to be appended. Format: HFNAME [ [IDX] ]. If
index is not specified new header is inserted at the top of
- message.
+ message. The index 1 correxponds to the first header.
* hvalue - Value to be added, config var formatting supported.
Example 1.8. insert_hf_value usage
@@ -285,7 +285,7 @@ insert_hf_value("foo[1]", "gogo") # try add to the first header
Meaning of the parameters is as follows:
* hf_par - Header field/param to be removed. Format: HFNAME [ [IDX] ]
[. PARAM ] If asterisk is specified as index then all values are
- affected.
+ affected. The index 1 correxponds to the first header.
Example 1.9. remove_hf_value usage
...
@@ -305,7 +305,7 @@ remove_hf_value("foo[*].bar") # for each foo delete bar parameters
Meaning of the parameters is as follows:
* hf_par - Header/param to be removed. Format: HFNAME [ [IDX] ] [.
PARAM ] If asterisk is specified as index then all values are
- affected.
+ affected. The index 1 correxponds to the first header.
Example 1.10. remove_hf_value2 usage
...
@@ -324,7 +324,7 @@ remove_hf_value2("foo[*].bar") # for each foo delete bar parameters
Meaning of the parameters is as follows:
* hf_para - Header field value / param to be appended. Format: HFNAME
[ [IDX] ] [. PARAM] If asterisk is specified as index then all
- values are affected.
+ values are affected. The index 1 correxponds to the first header.
* hvalue - Value to be assigned, config var formatting supported. If
value is empty then no equal sign appears in param.
@@ -348,7 +348,7 @@ assign_hf_value("foo[*].bar", "") # set empty value (ex. lr)
Meaning of the parameters is as follows:
* hf_para - Header field value / param to be appended. Format: HFNAME
[ [IDX] ] [. PARAM] If asterisk is specified as index then all
- values are affected.
+ values are affected. The index 1 correxponds to the first header.
* hvalue - Value to be assigned, config var formatting supported. If
value is empty then no equal sign appears in param.