sr-dev December 2017

sr-dev@lists.kamailio.org

26 participants
475 discussions

Contributing platform specific code to Kamailio

by Tsvetomir Dimitrov

Hello, I am working on a functionality which handles ipsec tunel creation for VoLTE registration and I'd like to contribute it to the project. However the code is heavily Linux specific - uses xfrm framework, so it won't compile on distribution with older kernels and definitely won't compile on *BSD. How problematic is this? How to handle this implementation so that it gets merged? Right now I can see two options: 1. Implement the functionality in ims_register_pcscf. 2. Implement separate ipsec module and handle the tunel creation/tear down from the configuration. The first solution is definitely the easiest one for implementation, but after my patch the module won't be as portable as it is now and I'm afraid my patch will be rejected. The second one separates the platform specific code in separate module and won't affect ims_register_pcscf. However I need data from ims_usrloc_pcscf, which is not accessible from the configuration. Also, writing separate module for a limited IPSEC handling seems like a overkill for me. What's your opinion? Best regards, Tsvetomir

6 years, 3 months

[kamailio/kamailio] sanity() test passes on invalid uri (#1289)

by juha-h

K master sanity() test passes URI hostpart that contains ` (back quote) character and possibly other invalid hostpart characters: Config: modparam("sanity", "default_checks", 1024) /* URI checks */ modparam("sanity", "uri_checks", 3) /* RURI, From */ xlog("L_INFO", "Checking $ru\n"); if (!sanity_check()) xlog("L_INFO", "Check failed\n"); else xlog("L_INFO", "Check passed\n"); Syslog: Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Checking sip:jh at te`st.fi Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Check passed According to RFC3261: hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum -- 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/1289

6 years, 3 months

[kamailio/kamailio] dialog: track_cseq_updates after failing uac_auth (#1359)

by Carlos Cruz Luengo

### Description [track_cseq_updates](http://kamailio.org/docs/modules/4.4.x/modules/dialog.h… of _dialog_ module seems to fail in cseq number adaptation of subsequent ACK once [uac_auth()](http://kamailio.org/docs/modules/4.4.x/modules/uac.html#uac.f.u… function of _uac_ module transaction fails: 1. INVITE sent by UAC (CSeq 100). 1. 407 from UAS. 1. INVITE generated by uac_auth (CSeq 101). 1. 500 from UAS. 1. INVITE to another carrier (CSeq 100) 1. 200 OK from carrier. 1. ACK (CSeq 101 instead of 100). ACK CSeq is increased by one but it shouldn't as it is acknowledging INVITE in step 5. ### Troubleshooting #### Reproduction The issue can be reproduced with the logic mentioned above (track_cseq_updates=1): - Initial INVITE - INVITE generated by uac_auth in failure_route - INVITE to another destination in failure_route - CSeq in ACK is increased by one #### SIP Traffic See attached pcap file ([cseq_tracking_wrong_ack.pcap.gz](https://github.com/kamailio/kamailio/files…) that involves following parties: - 155.179.229.105: UAC that sends the INVITE. - 155.179.229.109: Kamailio - 202.165.186.162: Initial carrier (the one that asks for SIP auth) - 9.189.124.97: Second carrier ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.6 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 4.9.2 ``` * **Operating System**:  ``` Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux ``` Is there any way to disable CSeq mangling triggered by uac_auth once this transaction fails to prevent this mangling from breaking the subsequent ACK transaction? Thank you and regards, -- 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/1359

6 years, 3 months

[kamailio/kamailio] v5.0.4: nathelper: force_socket not being honoured (#1298)

by 00Asgaroth00

### Description The force_socket parameter is not always used when set. If I understand the module documentation correctly, when setting the force_socket parameter, then all nathelper udp traffic will be forced to use this socket definition. The issue here is a result of another issue first described [here](http://sip-router.1086192.n5.nabble.com/NatHelper-ignoring-force-sock… in 2015 but is still present in current stable kamailio v5.0.4. We have 3 registrars running in "memory only" mode, using dmq_usrloc to replicate registrations to the remaining two nodes. On the remaining two nodes there is no socket parameter set for the AOR, but nathelper still wants to ping these AOR's. It is on these two systems where this issue exhibits itself. I will open another ticket for this scenario and try to reference it here as they are related. Each registrar has two interfaces, one is our "admin" lan, the other is our "voice" lan. The default route is set on these hosts and is a gateway on our "admin" lan. See issue #1297 When the registrars that are replicated to receive the AOR, they attempt to ping the endpoint (ideally they should not ping them). nathelper seems to think that the best interface to send them over is the "admin" lan even though force_socket is defined. I would have expected that the message should have been sent via the socket defined in the "force_socket" parameter. ### Troubleshooting Module definitions registrar ``` modparam("registrar", "method_filtering", 1) modparam("registrar", "case_sensitive", 1) modparam("registrar", "append_branches", 0) modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 0) modparam("registrar", "path_use_received", 1) modparam("registrar", "path_check_local", 1) modparam("registrar", "max_contacts", 1) ``` usrloc ``` modparam("usrloc", "db_mode", 0) modparam("usrloc", "use_domain", 1) modparam("usrloc", "timer_interval", 60) modparam("usrloc", "timer_procs", 4) modparam("usrloc", "nat_bflag", 6) ``` nathelper ``` modparam("nathelper", "natping_interval", 20) modparam("nathelper", "natping_processes", 4) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "sipping_from", "sip:keepalive@example.com") modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "sipping_bflag", 6) modparam("nathelper", "force_socket", "10.7.0.189:5060") modparam("nathelper", "udpping_from_path", 1) ``` Kamailio is listening on the same socket that is defined for the "force_socket" parameter above ``` listen=udp:10.6.0.189:5060 listen=udp:10.7.0.189:5060 listen=tcp:10.6.0.189:80 ``` dmq ``` modparam("dmq", "server_address", DMQ_ADDRESS) modparam("dmq", "notification_address", DMQ_NOTIFY_ADDRESS) modparam("dmq", "multi_notify", 1) modparam("dmq", "num_workers", 4) ``` dmq_usrloc ``` modparam("dmq_usrloc", "enable", 1) ``` #### Reproduction Using the above settings register a user and once they are replicated to the registrar that did not service the request, the options pings on the nodes that were replicated to will exhibit this issue. Example AOR where the registration was serviced (options pings should come from this host, and do, and flow as expected) ``` { "jsonrpc": "2.0", "result": { "Domain": "location", "Size": 1024, "AoRs": [{ "Info": { "AoR": "example_user(a)example.com", "HashID": -1389656423, "Contacts": [{ "Contact": { "Address": "sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP", "Expires": 66, "Q": -1, "Call-ID": "wE-GD4GzkrtuDAJUBJf1Jg..", "CSeq": 58, "User-Agent": "Z 3.15.40006 rv2.8.20", "Received": "sip:212.2.172.228:39808", "Path": "<sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:39808>", "State": "CS_NEW", "Flags": 0, "CFlags": 64, "Socket": "udp:10.7.0.190:5060", "Methods": -1, "Ruid": "uloc-2-59fa1f9d-714-17", "Instance": "[not set]", "Reg-Id": 0, "Last-Keepalive": 1509615136, "Last-Modified": 1509615136 } }] } } ], "Stats": { "Records": 1, "Max-Slots": 1 } }, "id": 4836 } ``` example AOR of the above registration on a registrar that was replicated to by dmq/dmq_usrloc, ideally these AOR's should not be pinged at all, but, currently they do, but, in this case, when they do get ping'd, they do not use the socket as defined in the "force_socket" parameter. ``` { "jsonrpc": "2.0", "result": { "Domain": "location", "Size": 1024, "AoRs": [{ "Info": { "AoR": "example_user(a)example.com", "HashID": -1389656423, "Contacts": [{ "Contact": { "Address": "sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP", "Expires": 69, "Q": -1, "Call-ID": "wE-GD4GzkrtuDAJUBJf1Jg..", "CSeq": 91, "User-Agent": "Z 3.15.40006 rv2.8.20", "Received": "sip:212.2.172.228:39808", "Path": "<sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:39808>", "State": "CS_NEW", "Flags": 2, "CFlags": 64, "Socket": "[not set]", "Methods": -1, "Ruid": "uloc-2-59fa1f9d-714-17", "Instance": "[not set]", "Reg-Id": 0, "Last-Keepalive": 1509617664, "Last-Modified": 1509617664 } }] } } ], "Stats": { "Records": 1, "Max-Slots": 1 } }, "id": 4571 } ``` #### Log Messages There are no apparent error messages in the logs relating to this that I can see. #### SIP Traffic Here you can clearly see that the OPTIONS message is being sent over the "10.6.0.189" interface when the modules "force_socket" parameter is set to "10.7.0.189:5060" ``` U 2017/11/02 08:37:59.426608 10.6.0.189:5060 -> 10.7.0.186:5062 OPTIONS sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 10.6.0.189:5060;branch=z9hG4bK8416926. Route: <sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:39808>. From: sip:keepalive@example.com;tag=uloc-2-59fa1f9d-714-17-9968b2da-13812ff4. To: sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP. Call-ID: c0cec5f7-555ac383-68bb313(a)10.6.0.189. CSeq: 1 OPTIONS. Content-Length: 0. . U 2017/11/02 08:38:19.431937 10.6.0.189:5060 -> 10.7.0.186:5062 OPTIONS sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 10.6.0.189:5060;branch=z9hG4bK8345318. Route: <sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:39808>. From: sip:keepalive@example.com;tag=uloc-2-59fa1f9d-714-17-9968b2da-23812ff4. To: sip:example_user@212.2.172.228:39808;rinstance=ed8aa63e90f53e97;transport=UDP. Call-ID: c0cec5f7-655ac383-a9bb313(a)10.6.0.189. CSeq: 1 OPTIONS. Content-Length: 0. . ``` ### Possible Solutions Unknown ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.0.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 on 10:57:22 Oct 26 2017 with gcc 4.8.5 ``` * **Operating System**: ``` CentOS Linux release 7.4.1708 (Core) Linux localhost 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 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/1298

6 years, 4 months

Kamailio World 2018 - Call for Presentations

by Daniel-Constantin Mierla

Hello, I would like to announce that Call for Presentations at Kamailio World 2018 is now open. You can submit your proposal or see more details at: - https://www.kamailioworld.com/k06/call-for-speakers/ The 6th edition of the event takes place again in Berlin, Germany, during May 14-16, 2018. Expect over 150 participants, developers and community members as well as representatives from other popular open source VoIP projects such as Asterisk or FreeSwitch. Looking forward to meeting many of you there! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

6 years, 4 months

[kamailio/kamailio] http_async_client: fix initialization of tls_client_* and tls_ca_path (#1386)

by Victor Seva

set_query_params() was checking if those variables had a value to copy them. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1386 -- Commit Summary -- * http_async_client: fix initialization of tls_client_* and tls_ca_path module parameters -- File Changes -- M src/modules/http_async_client/http_async_client_mod.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1386.patch https://github.com/kamailio/kamailio/pull/1386.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/1386

6 years, 4 months

[kamailio/kamailio] topos: retry initial INVITE - no Contact (#1356)

by sergey-vb

### Description When callee device not reachable kamailio tries to reach it, I have profile with 3 retries with 1second interval. But Contact header present only in 1-st Invite. Next Invites are send without Contact header... With topoh module - Contact normal in all INVITES. ### Troubleshooting #### Reproduction Load and configure topos module Create permanent location record which is unreachable. Make call to it. make sure that you have profile with retries. #### Log Messages [kamailio.tar.gz](https://github.com/kamailio/kamailio/files/1542939/kamaili… #### SIP Traffic [retry-Invite-on-not-reach.tar.gz](https://github.com/kamailio/kamailio/file… ### Additional Information * **Kamailio Version** version: kamailio 5.2.0-dev1 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 on 14:50:56 Dec 8 2017 with gcc 4.8.5 * **Operating System**: Red Hat Enterprise Linux Server 7.3 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 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/1356

6 years, 4 months

[kamailio/kamailio] acc: set cdr_extra values to NULL (#1378)

by Carlos Cruz Luengo

### Description ACC module [cdr_extra modparam](http://kamailio.org/docs/modules/devel/modules/acc.html#acc.p.cdr… allows saving additional custom values in cdr entries using dlg_vars. When you define a new value to be saved: `modparam("acc", "cdr_extra", "c1=$dlg_var(caller)")` and you set a $dlg_var(c1) in the logic, everything works as expected. But if you set it to $null or you don't even define it, it is saved as '' (empty string). Would be nice that setting to $null would store the underlying null value (NULL in SQL database) and not defining it would lead to not even including it in the final INSERT? ### Troubleshooting #### Reproduction Define a new value to be saved: `modparam("acc", "cdr_extra", "c1=$dlg_var(caller)")` And in the kamailio.cfg logic: - If you set $dlg_var(c1) to any string ('', 'foo', '2'), it is saved as expected ('', 'foo', '2'). - If you set $dlg_var(c1) to an integer different from 0 (1, 2, 3), it is saved as a string containing that number ('1', '2', '3'). This seems normal as dlg_vars can only store strings. - If you set $dlg_var(c1) to 0, it is saved as an empty string (''). Seems normal too. - If you set $dlg_var(c1) to $null, it is saved as an empty string (''). - If you don't define $dlg_var(c1) at all, it is saved as an empty string (''). #### Debugging Data Both [_extra2strar_](https://github.com/kamailio/kamailio/blob/e101f21c37238862a4… and [_extra2strar_dlg_only_](https://github.com/kamailio/kamailio/blob/e101f21c3… functions defined in [_acc_extra.c_](https://github.com/kamailio/kamailio/blob/master/src/modules… set _cdr_type_array_ entry to TYPE_NULL, but that array is not used in subsequent [for loop](https://github.com/kamailio/kamailio/blob/e101f21c37238862a474c50218d…. ### Possible Solutions Modify the logic in the [for loop](https://github.com/kamailio/kamailio/blob/e101f21c37238862a474c50218d… so that it invokes VAL_NULL macro for null values using _cdr_type_array_. With this change both $null values and undefined values would use underlying NULL value. I could try to make further changes to avoid the key in the insert for undefined values instead of setting it to NULL. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.6 (x86_64/linux) 0a8379-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 0a8379 -dirty compiled on 12:23:36 Dec 20 2017 with gcc 6.3.0 ``` * **Operating System**: ``` Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux ``` Is there any reason I missed for not doing this change ([this comment](https://github.com/kamailio/kamailio/blob/e101f21c37238862a474c502… makes me think so)? If not, I can try to provide a PR with these changes. Regards, -- 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/1378

6 years, 4 months

[kamailio/kamailio] acc: save cdr entries in UTC (#1358)

by Carlos Cruz Luengo

### Description ACC module allows setting datetime fields in UTC via [time_mode param](http://kamailio.org/docs/modules/devel/modules/acc.html#acc.p.time_m…. However, this setting does not cause cdr entries to be saved in that format and I haven't found any equivalent parameter to achieve this. ### Troubleshooting Analyzing the code for MySQL database storage I have found that [_db_time2str_ex_ function defined in _db_ut.c_](https://github.com/kamailio/kamailio/blob/master/src/lib/srdb1/d… uses localtime(). ### Possible Solutions Changing localtime() to gmtime() cdrs are saved in UTC, but it would be desirable to add a new module param that makes this configurable. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.6 (x86_64/linux) 0a8379-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 0a8379 -dirty compiled on 17:01:42 Dec 4 2017 with gcc 6.3.0 ``` * **Operating System**:  ``` Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux ``` Should I proceed and try to get a working PR to add this new modparam or there is currently a way to get this that I have missed (apart from setting system time to UTC)? Thank you and regards, -- 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/1358

6 years, 4 months

[kamailio/kamailio] acc: Allow nullable cdr extra fields (#1385)

by Carlos Cruz Luengo

#### Pre-Submission Checklist - [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: - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #1378 #### Description - allow custom cdr fields defined with cdr_extra modparam to be saved as null. Before this change, cdr_extra variables not defined in config operation (or set to $null) were saved as empty string (''). This commit makes possible to save them as NULL value. - new modparam to make this behaviour configurable: cdr_extra_nullable. Set it to 1 to enable this new behaviour (default value: 0) You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1385 -- Commit Summary -- * acc: Allow nullable cdr extra fields -- File Changes -- M src/modules/acc/acc_cdr.c (11) M src/modules/acc/acc_mod.c (8) M src/modules/acc/acc_mod.h (1) M src/modules/acc/doc/acc_admin.xml (22) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1385.patch https://github.com/kamailio/kamailio/pull/1385.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/1385

6 years, 4 months

← Newer
1
...
7
8
9
10
11
12
13
...
48
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2017