pua_dialoginfo: Add display attributes to identity tags.
- This is an example of how "display" attributes could be added to identity tags in the PUBLISH message XML body.
- This is not a working solution, the strings("RemoteCallerName" & "LocalCallerName") are "hard coded". I could not figure out how to get the caller/callee information from the SIP message.
<!-- 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 -->
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] 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 #2615
#### Description
This is not a working solution. Opening the PR as requested by @miconda in issue #2615. I just added a couple lines to test how adding a "display" attribute to the identity tags would look like. This allows the phone to update it's display with relevant caller/callee information. I "hard coded" the values to verify that this works. However, I could not figure out how to get the display name from the SIP message(I'm not experienced with C).
It seems that the "local" identity should have it's display name set to the name in the From header. And, the remote identity should have its display name set to the user part of the URI in the "To" header.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2617
-- Commit Summary --
* Create dialog_publish.c
-- File Changes --
M src/modules/pua_dialoginfo/dialog_publish.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2617.patchhttps://github.com/kamailio/kamailio/pull/2617.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/2617
Hi,
Same issue with @farnk05 on https://github.com/kamailio/kamailio/issues/2224
Wanted to open a fresh issue to not reopen an old one.
This is on kamailio 5.4.2, which appears to have these fixes from https://github.com/kamailio/kamailio/issues/2224#issuecomment-602730307 in them when I checked the src files.
```
$ sudo rpm -qi kamailio |grep Date
Install Date: Fri 20 Nov 2020 12:03:26 AM PST
Build Date : Tue 27 Oct 2020 05:37:31 AM PDT
```
```
$ sudo rpm -qa | grep kamailio
kamailio-mysql-5.4.2-0.el7.x86_64
kamailio-tls-5.4.2-0.el7.x86_64
kamailio-5.4.2-0.el7.x86_64
kamailio-websocket-5.4.2-0.el7.x86_64
kamailio-tcpops-5.4.2-0.el7.x86_64
kamailio-statsd-5.4.2-0.el7.x86_64
```
Package Source: https://rpm.kamailio.org/centos/7/5.4/5.4.2/x86_64/
OS: RHEL 7.6.1810
Mem mgr: default/qm
SHM is 4096, PKG is 1024 (system has 16gb ram, 4 core Intel Skylake CPU on a KVM.
There are a few variations we see with the qm_free errors, here are the most common we see when kamailio segfaults, and we have to let systemd restart it, or Monit as we now have to have Monit check for CRITICAL messages since kamailio segfaults so often.
```
/usr/sbin/kamailio[32734]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7f0da5012fc0), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring
/usr/sbin/kamailio[32734]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7f0da5012fc0), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring ...
```
```
/usr/sbin/kamailio[32733]: CRITICAL: dialog [dlg_profile.c:574]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1)
/usr/sbin/kamailio[32733]: CRITICAL: dialog [dlg_profile.c:574]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1)
/usr/sbin/kamailio[6160]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7ff00842e320), called from tm: h_table.c: free_cell_helper(189), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring
```
GDB as requested in the other Issue (note gdb was run on another VM, not the main system, hopefully that is not an issue:
```
$ gdb /usr/sbin/kamailio /core-kamailio-11-995-992-11912-1612143069
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/kamailio...Reading symbols from /usr/lib/debug/usr/sbin/kamailio.debug...done.
done.
[New LWP 11912]
warning: .dynamic section for "/lib64/libc.so.6" is not at the expected address (wrong library or version mismatch?)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by '/usr/sbin/kamailio -DD -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamai'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000006024be in destroy_avp_list_unsafe (list=0x7fdc559d4fd8) at core/usr_avp.c:625
625 avp = avp->next;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_6.x86_64 libcom_err-1.42.9-13.el7.x86_64 libgcc-4.8.5-36.el7_6.2.x86_64 libmaxminddb-1.2.0-1.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64 libunistring-0.9.3-9.el7.x86_64 mariadb-libs-5.5.60-1.el7_5.x86_64 openssl-libs-1.0.2k-16.el7_6.1.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) frame 0
#0 0x00000000006024be in destroy_avp_list_unsafe (list=0x7fdc559d4fd8) at core/usr_avp.c:625
625 avp = avp->next;
(gdb) list
620 avp_t *avp, *foo;
621
622 avp = *list;
623 while( avp ) {
624 foo = avp;
625 avp = avp->next;
626 shm_free_unsafe( foo );
627 }
628 *list = 0;
629 }
(gdb) p *p_entry
No symbol "p_entry" in current context.
(gdb) p *l
No symbol "l" in current context.
(gdb)
No symbol "l" in current context.
(gdb) p *lh
No symbol "lh" in current context.
(gdb) p *lh
No symbol "lh" in current context.
(gdb) frame 1
#1 0x00007fdd56fb8f92 in free_cell_helper (dead_cell=0x7fdc559d4dd8, silent=0, fname=0x7fdd570d1363 "timer.c", fline=643) at h_table.c:255
255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from);
(gdb)
#1 0x00007fdd56fb8f92 in free_cell_helper (dead_cell=0x7fdc559d4dd8, silent=0, fname=0x7fdd570d1363 "timer.c", fline=643) at h_table.c:255
255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from);
(gdb) list
250 if(dead_cell->user_avps_from)
251 destroy_avp_list_unsafe(&dead_cell->user_avps_from);
252 if(dead_cell->user_avps_to)
253 destroy_avp_list_unsafe(&dead_cell->user_avps_to);
254 if(dead_cell->uri_avps_from)
255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from);
256 if(dead_cell->uri_avps_to)
257 destroy_avp_list_unsafe(&dead_cell->uri_avps_to);
258 if(dead_cell->xavps_list)
259 xavp_destroy_list_unsafe(&dead_cell->xavps_list);
(gdb) p *dlg
No symbol "dlg" in current context.
(gdb) p *msg
No symbol "msg" in current context.
(gdb)
```
--
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/2620
### Description
We noticed a PKG memory leak when using DMQ module's function _dmq_bcast_message_ .
### Troubleshooting
#### Reproduction
Issue can be reproduced with configuration below.
* 3 Kamailio nodes each one listening on dedicated port 5070 for DMQ on their private IP address.
* A dns name _[KAMAILIO_DNS]_ resolving these 3 nodes:
```
# dig +short A [KAMAILIO_DNS]
10.234.97.169
10.234.97.170
10.234.92.126
```
DMQ module configured as below (example for node 1)
```
loadmodule "dmq.so"
...
modparam("dmq", "server_address", "sip:10.234.97.169:5070")
modparam("dmq", "notification_address", "sip:[KAMAILIO_DNS]:5070")
modparam("dmq", "ping_interval", 10)
modparam("dmq", "multi_notify", 1)
```
Each time an INVITE comes in, we use function below to broadcast custom message to all of the nodes:
```
...
if(is_method("INVITE")) {
dmq_bcast_message("invitenotification", "invite received", "text/plain");
}
...
```
This custom message is handled as below:
```
request_route {
...
if(is_method("KDMQ")) {
if($Rp == 5070) route(DMQHANDLE);
else drop;
}
...
}
...
route[DMQHANDLE] {
if($tU == "invitenotification") {
# Doing some additional stuff here, but not the cause of the leak
send_reply("200", "OK");
} else {
dmq_handle_message();
}
}
```
Using **sipp** to send lots of messages, we can easily notice the free PKG memory decreasing over time (using `kamcmd pkg.stats`)
#### Debugging Data
Processes impacted by the leak are the ones processing SIP messages. In case of TCP, it is one of the tcp receivers.
When doing a dump of such processes with command below:
```
kamcmd cfg.set_now_int core mem_dump_pkg [PID]
```
Results are full of records like these ones:
```
ALERT: qm_status: alloc'd from core: core/parser/parse_from.c: parse_from_header(63)
ALERT: qm_status: alloc'd from core: core/parser/parse_addr_spec.c: parse_to_param(285)
```
We are sure that the leak is generated by this DMQ broadcast function: we isolated it and noticed no leaks when removing it from a basic script configuration.
We tried different configurations:
* disabling multi_notify => memory leak still present
* using an IP address instead of the DNS name => memory leak still present
Valgrind did not help us to find out more precisely where the issue in the code could be located.
### Possible Solutions
Would a _free_ of _msg->from->parsed_ be missing somewhere in DMQ code?
Behavior looks very similar to https://github.com/kamailio/kamailio/pull/59
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.3.7 (x86_64/linux) c16b3f-dirty
flags: , EXTRA_DEBUGUSE_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, TIMER_DEBUG, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
```
* **Operating System**:
```
Debian 9.13 under docker
Linux 4.9.0-9-amd64
```
--
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/2600
Hello,
it is the time to plan a bit the road to the next major release, to be
versioned 5.5.0.
The 5.4.0 was release by end of July 2020, therefore we are approaching
the end of our usual development cycle, also during the last online
devel meeting we considered the 2nd part of spring 2021 as a target time
frame for 5.5.
To narrow it down, I would propose to freeze the development at the end
of March 2021, test during April and maybe beginning of May, then
release v5.5.0.
So far we have a lot of development to existing components, by the
freeze date I expect 3-5 new modules to be in the repo as well.
If anyone wants a different time line towards 5.5.0, let's discuss and
choose the one that suits most of the developers.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
I've been trying the new in-memory only presence feature in 5.4.x but have run into an issue:
```
ERROR: presence [presence_dmq.c:109]: pres_dmq_init_proc(): dmq_worker_init: database not bound
kamailio[8404]: segfault at 0 ip 00007f4f8419c4d7 sp 00007ffd68ef0130 error 4 in presence.so[7f4f8418d000+fe000]
CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 31
ALERT: <core> [main.c:777]: handle_sigs(): child process 8411 exited by a signal 11
```
I have this set `modparam("presence", "publ_cache", 2)` but had to comment it out in order to prevent kamailio from crashing. I have reverted back to using mysql for storing presentity records for now.
### Troubleshooting
#### Reproduction
Starting kamailio with these mod params can re-produce the issue.
```
#!ifdef WITH_PRESENCE
# ----- presence params -----
modparam("presence", "db_url", DBURL)
modparam("presence", "server_address", "sip:EXTERNAL_LISTEN_IP:EXTERNAL_UDP_PORT")
modparam("presence", "subs_db_mode", 0)
modparam("presence", "publ_cache", 2)
modparam("presence", "clean_period", 40)
modparam("presence", "max_expires", 3600010)
modparam("presence", "enable_dmq", 1)
# ----- presence_xml params -----
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)
# ----- presence_dialoginfo params -----
modparam("presence_dialoginfo", "force_dummy_dialog", 1)
#!endif
```
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.4.3 (x86_64/linux) e19ae3
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: e19ae3
compiled on 18:17:25 Dec 14 2020 with gcc 4.8.5
```
* **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`)
-->
```
CentOS 7 - Linux hostname 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 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/2642
The function lookup_to_dset() is a config command implemented inside the registrar module.
https://github.com/kamailio/kamailio/blob/351efd29d332703e79104a106ade08c9d…
As you can see from the link above, It triggers w_lookup_to_dset() and it ends up calling lookup_helper() with the mode flag set to zero that causes lookup_helper() to not overwrite the request uri (and destination uri if it's the case).
For me it's worth documenting lookup_to_dset() inside modules/registrar/README file, this function it was very useful to me and I found out about it only digging into the code.
Thanks
--
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/2623
### Description
`dns_int_match_ip` is broken on 5.3.0 and above
### Troubleshooting
#### Reproduction
Try this dialplan:
```
if (dns_int_match_ip('dns.google', '8.8.8.8')) {
xlog("L_INFO", "OK dns-ip match with dns_int_match_ip");
} else {
xlog("L_ERR", "FAIL dns-ip match with dns_int_match_ip");
}
if (dns_int_match_ip('100.100.100.100', '8.8.8.8')) {
xlog("L_ERR", "FAIL dns_int_match_ip on 2 ip's");
} else {
xlog("L_INFO", "OK dns_int_match_ip on 2 ip's");
}
```
On 5.2 releases, both checks succeed. On 5.3 and up, both fail.
#### Debugging Data
I've traced down the problem to `str2ip`.
In 5.2, this is a `static inline` function defined in the header file `resolve.h`. Therefore, the returned `ip` structure is allocated *once per compilation unit* - ie. `ipops_mod.c` and `dns_cache.c` both have their own versions of the variable.
Since fb75e90549a (5.3 and up) this function is defined in it's own compilation unit (`resolve.c`) and therefore shared by all callers.
See: https://stackoverflow.com/questions/185624/static-variables-in-an-inlined-f…
#### Log Messages
n/a
#### SIP Traffic
n/a
### Possible Solutions
- Have `ki_dns_sys_match_ip` make a local copy of the return value of `str2ip`
- Move `str2ip` back to a header file
- Refactor `str2ip` to take a pointer to an output struct
### Additional Information
In 5.3, this is what happens:
```
# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on dns.google.com, zeroing out the static variable
# - (dns_cache_do_request will call str2ip on dns.google.com, zeroing out the static variable again)
# - resolvehost queries DNS
# - the resolved IP's will be compared to the zero'd out struct
dns_int_match_ip('dns.google', '8.8.8.8') == false
# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on 100.100.100.100, overwriting the static variable
# - the static variable will be compared to itself
dns_int_match_ip('100.100.100.100', '8.8.8.8') == true
```
--
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/2645
### Description
Hi,
I am migrating from Kamailio 4.4.7 (debian 8.1) to 5.4.3 (debian 10.7).
I changed the neccessary changes in configuration (replaced MI with RPC) and I tried to start the kamailio. The issue is that it takes about 3minutes to start. On the older version 4.4.7 it started aproximetly in 20s.
The modules I am using are:
```
"cfgutils.so","db_mysql.so","kex.so","tm.so","tmx.so","sl.so","rr.so","pv.so","maxfwd.so","textops.so","siputils.so","xlog.so","sanity.so","ctl.so","jsonrpcs.so","exec.so","carrierroute.so","avpops.so","sqlops.so","dmq.so","htable.so","dialog.so","acc.so","acc_radius.so","dispatcher.so","dialplan.so","textopsx.so","statsd.so","app_perl.so","http_async_client.so".
```
I assume the issue is caused by carrierroute module. It takes also about 3 minutes to reload routes (when the kamailio service is running) using rpc command cr.reload_routes.
I did not change anything in configuration related to carrierroute module.
```
modparam("carrierroute", "config_source", "db")
modparam("carrierroute", "db_url", DBURL)
modparam("carrierroute", "match_mode", 128)
modparam("carrierroute", "avoid_failed_destinations", 0)
modparam("carrierroute", "carrierroute_table", "carrierroute_view")
```
Carrierroute module loading on version 4.4.7 needed:
- INFO: carrierroute [cr_db.c:317]: load_route_data_db(): **took 1s**
- INFO: carrierroute [cr_carrier.c:100]: add_domain_data(): and INFO: carrierroute [cr_data.c:414]: get_domain_data_or_add(): **took 8s**
- INFO: carrierroute [cr_data.c:655]: rule_fixup(): **took 3s**
Carrierroute module loading on version 5.4.3 needed:
- INFO: carrierroute [cr_db.c:317]: load_route_data_db(): **took 1s**
- INFO: carrierroute [cr_carrier.c:100]: add_domain_data(): and INFO: carrierroute [cr_data.c:414]: get_domain_data_or_add(): **took 2min 23s**
- INFO: carrierroute [cr_data.c:655]: rule_fixup(): **took 17s**
I have also compiled kamailio version 5.0 on both (debian 8.1 and debian 10.7), but it also took so long to start on both machines.
### Additional Information
```
version: kamailio 5.4.3 (x86_64/linux) 06bd17
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: 06bd17
compiled on 16:10:30 Jan 25 2021 with gcc 8.3.0
```
* **Operating System**:
```
Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
Debian 10.7
```
Thank you for your 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/2613
The old, quite arbitrary, default of 0.01 is preserved.
<!-- 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 -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2647
-- Commit Summary --
* uac_redirect: Make default q-value configurable
-- File Changes --
M src/modules/uac_redirect/doc/uac_redirect_admin.xml (19)
M src/modules/uac_redirect/rd_funcs.c (4)
M src/modules/uac_redirect/uac_redirect.c (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2647.patchhttps://github.com/kamailio/kamailio/pull/2647.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/2647