sr-dev February 2022

sr-dev@lists.kamailio.org

17 participants
241 discussions

[kamailio/kamailio] kamctl - maintenance for dbtextdb.py tool (#2469)

by Daniel-Constantin Mierla

**kamctl** include a python tool that is parsing SQL statements to do operations over the **db_text** files, for the common db operations (e.g., insert, delete). It is located at: * https://github.com/kamailio/kamailio/tree/master/utils/kamctl/dbtextdb The tool was contributed long time ago and not kept up to date, being known not to work with Python3 (e.g., #2464). This issue is created to see if someone has the interest to pick up the maintenance of this tool, if not it will be removed from kamctl. Note that db_text works with text files, so it is not necessary to have a tool for managing the content of these files, they can be simply updated with any text editor. -- 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/2469

1 year, 10 months

[kamailio/kamailio] [kamctl] Dispatcher operations in a case of db_text are mostly incorrect (#2464)

by Igor Olhovskiy

### Description On creating dispatcher with `kamctl` in the case of `db_text` it fails ### Troubleshooting #### Reproduction Point `kamctlrc` to DB_TEXT. Run `kamctl dispatcher add 1 sip:asterisk_2:5060 1 3` Run 'kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 'prefix=123' 'test1'' Run 'kamctl dispatcher show' Run 'kamctl dispatcher reload' #### Debugging Data ``` # kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 attrs cannot be empty or null -e \E[37;31mERROR: dispatcher - SQL Error ``` ``` # kamctl dispatcher add 1 sip:asterisk_2:5060 1 3 'prefix=123' 'test1' Traceback (most recent call last): File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1243, in <module> main(sys.argv) File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1230, in main dataset = conn.Execute(' '.join(argv[1:])) File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 423, in Execute self.WriteTempTable() File "/usr/lib/x86_64-linux-gnu/kamailio//kamctl/dbtextdb/dbtextdb.py", line 1138, in WriteTempTable self.temp_file.write(header.strip() + '\n') File "/usr/lib/python3.7/tempfile.py", line 620, in func_wrapper return func(*args, **kwargs) TypeError: a bytes-like object is required, not 'str' -e \E[37;31mERROR: dispatcher - SQL Error ``` dump is showing active dispatchers, show - is not. ``` # kamctl dispatcher dump { "jsonrpc": "2.0", "result": { "NRSETS": 1, "RECORDS": [{ "SET": { "ID": 1, "TARGETS": [{ "DEST": { "URI": "sip:asterisk_2:5060", "FLAGS": "AP", "PRIORITY": 0 } }] } }] }, "id": 124 } root@e529c8cb4f62:/# kamctl dispatcher show -e dispatcher gateways ``` No result on reload ``` # kamctl dispatcher reload { "jsonrpc": "2.0", "result": { }, "id": 160 } ``` ### Possible Solutions I've tried to add data to the table manually, but here I got another issue. But on Kamailio load, the only first dispatcher is processed. Will add another issue on this. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` /# kamailio -v version: kamailio 5.4.1 (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**: Debian 10/Docker ``` # uname -a Linux 9b7efa852274 5.3.18-lp152.36-default #1 SMP Tue Aug 18 17:09:44 UTC 2020 (885251f) 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/2464

1 year, 10 months

[kamailio/kamailio] The acc modules writes a random string into the sip_reason field for an ACK message (FAKED_REPLY) (Issue #2981)

by Frits Wiersma

### Description While upgrading to kamailio version 5.5.2 I noticed that the sip reason is not always filled in correctly. In our current setup with kamailio version 4.4 the acc module writes the INVITE, ACK end BYE messages to a postgres database. Also the missed calls are logged. With version 5.5.2 but also with version 5.5.3 the sip reason seems to contain a random 2 digits. It gets even worse when a call is missed and kamailio generates a 408 timeout. Then a random string of 15 characters is written to the database. Sometimes this results in a fatal error because the postgres driver can't escape the string. ### Troubleshooting The relevant part in de code is in the function env_set_code_status in file acc_logic.c if (reply==FAKED_REPLY || reply==NULL) { /* code */ acc_env.code_s.s = int2bstr((unsigned long)code, code_buf, &acc_env.code_s.len); /* reason */ if (acc_env.reason.len == 0) { /* already extracted in case of locally generated replies */ acc_env.reason.s = error_text(code); acc_env.reason.len = strlen(acc_env.reason.s); } The sip reason is only filled in when the len is 0, but once the length is set it looks like it's not being reset to 0 again somewhere. I can fix the problem by removing the if statement, but that is probably not the intention of the programmer. #### Reproduction The wrong reason in the ACK can probably be reproduces with any call, but in my test setup an Asterisk system answers the call. After the "OK" an ACK is received which is seen as a FAKED_REPLY. The reason.len however is still 2 and the reason is not set. The new function "env_set_reason" is not being called in this case. The issue with the 408 can be reproduced by calling an endpoint and let kamailio timeout. This has to be done twice to reproduce the error. This time kamailio wants to write the missed INVITE to the database with a random string of 15 characters for the sip reason. To me it looks like the length of 15 comes from the length of the "Request Timeout" string but the pointer reason.s point to a memory part of a previous transaction which is already gone ? #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.5.2 (x86_64/linux) 55e232 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_BLOCKLIST, 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: 55e232 compiled on 15:45:52 Dec 9 2021 with gcc 8.3.0 ``` * **Operating System**: ``` Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2981 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2981(a)github.com>

1 year, 10 months

[kamailio/kamailio] crash related to functions in cfg file parser for invalid cfg (#2239)

by Henning Westerholt

Against current git master. ``` henning@static:~/repositories/kamailio$ cat etc/crash-4.cfg #!KAMAILIO loadmodule "sl.so" request_route { switch (1) { case -1: send_reply("404", "Not Found"); case -2: send_reply("405",("Method Not Allowed"); exit; } ``` > $ ./src/kamailio -f etc/crash-4.cfg -L src/modules/ -Y /tmp -E -d > 0(2278) CRITICAL: <core> [core/cfg.y:3549]: yyerror_at(): parse error in config file /home/henning/repositories/kamailio/etc/crash-4.cfg, line 10, column 43: syntax error > 0(2278) CRITICAL: <core> [core/cfg.y:3549]: yyerror_at(): parse error in config file /home/henning/repositories/kamailio/etc/crash-4.cfg, line 10, column 43: '('')' expected (function call) > Segmentation fault (core dumped) > henning@static:~/repositories/kamailio$ gdb src/kamailio core > Reading symbols from src/kamailio...done. > [New LWP 2278] > Core was generated by `./src/kamailio -f etc/crash-4.cfg -L src/modules/ -Y /tmp -E -d'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00005580cdbd131e in append_action (a=0x7fad84db9300, b=0x7fad84db97f8) at core/route_struct.c:147 > 147 for(t=a; t->next; t=t->next); > (gdb) bt > #0 0x00005580cdbd131e in append_action (a=0x7fad84db9300, b=0x7fad84db97f8) at core/route_struct.c:147 > #1 0x00005580cdf9208b in yyparse () at core/cfg.y:2428 > #2 0x00005580cdb96c11 in main (argc=9, argv=0x7ffc2d9f6a68) at main.c:2309 > (gdb) f 0 > #0 0x00005580cdbd131e in append_action (a=0x7fad84db9300, b=0x7fad84db97f8) at core/route_struct.c:147 > 147 for(t=a; t->next; t=t->next); > (gdb) p a > $1 = (struct action *) 0x7fad84db9300 > (gdb) p b > $2 = (struct action *) 0x7fad84db97f8 > (gdb) p t > $3 = (struct action *) 0x80 > (gdb) p a->next > $4 = (struct action *) 0x80 > (gdb) p *t > Cannot access memory at address 0x80 -- 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/2239

1 year, 11 months

[kamailio/kamailio] [Feature Request] Add reload capability for geoip2 module (#2029)

by Joel Serrano

### Description Currently, the `geoip2` module loads the IP database at startup and keeps it in cache and there is no way to tell Kamailio to reload the database without a full restart. ### Possible Solutions To keep this module inline with other modules that use external datasources, I would suggest to implement a new RPC command and a new geoip2 function to reload the database defined in the `path` geoip2 modparam without the need of a restart. I'm not aware of the effort required for implementing either of them, but only having an RPC command would effectively solve this issue as you can call RPC commands from within Kamailio conf, thus, the reload function would not be something strictly required but more of a nice-to-have. ### Examples: Function: ``` geoip2_reload() ``` RPC command: ``` kamctl rpc gip2.reload / kamctl rpc geoip2.reload ``` Kamcmd command: ``` kamcmd geoip2.reload ``` -- 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/2029

2 years, 1 month

[kamailio/kamailio] Kamailio 5.4.x dialog profiles functionality dead-lock on certain high-load scenarios (Issue #2923)

by Henning Westerholt

### Description The Kamailio 5.4.x dialog profiles functionality can lead to dead-lock on certain high-load scenarios. The Kamailio dialog profiles are used to track parallel channels for about 200 outgoing PSTN carrier interconnections. During high traffic times (like several thousands parallel calls) the Kamailio server will frequently (e.g. hourly) goes into an end-less loop while executing get_profile_size in the configuration script. This causes the locking for the dialog profiles never be released and Kamailio will stop serving traffic. Internal monitoring tools and RPC commands stay working, as long as they do not touch the dialog functionality. A similar (dedicated) Kamailio setup is used for tracking parallel channels for customers. Here the dead-lock is not observed that frequently, but aparentely also some crashes happens in a much longer time interval. ### Troubleshooting After analysis of the back-traces with GDB the get_profile_size() function was removed from the configuration script. After this change the crash did not happened anymore for several days. #### Reproduction Issue could not be reproduced so far. #### Debugging Data ##### bt 1 (some data removed) (gdb) bt \# 0 0x00007f57cf3b00da in get_profile_size (profile=0x7f50ccbc7e80, value=0x7ffd9928f300) at dlg_profile.c:859 n = 364 i = 12 ph = 0x7f50d3e4b7d0 \# 1 0x00007f57cf419c67 in w_get_profile_size_helper (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7ffd9928f300, spd=0x7f57d6916960) at dialog.c:941 \# 2 0x00007f57cf41a459 in w_get_profile_size3 (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7f57d6935118, result=0x7f57d6916960) at dialog.c:982 \# 3 0x0000000000463fea in do_action (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1094 \# 4 0x00000000004711ee in run_actions (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1581 \# 5 0x000000000046058b in do_action (h=0x7ffd99293610, a=0x7f57d690fda8, msg=0x7f57d699d418) at core/action.c:700 The first back-trace was taking from a running process with gdb. The counter in f0 does not increased that much during this time, probably due the overflow of the loop counter. ##### bt2 (analysis with data structure with gdb scripts) Here the loop counter in f0 showed a really high value. Expected size of dialog profiles hash table: (gdb) p profile->entries[3] $4 = {first = 0x7f9bfd4aad98, content = 2068} (gdb) p profile->entries[7] $3 = {first = 0x7f9c12079f70, content = 784} (gdb) p profile->entries[12] $6 = {first = 0x7f9c02be5d50, content = 7600} (gdb) p profile->entries[14] $2 = {first = 0x7f9bff636de8, content = 6764} hash table bucket 14 shows a lot of corruption and the loop never ends (carrier names and IPs replaced). The list for hash bucket 7 got linked to the list for hash bucket 14: counter 6755: prev 0x7f9c0b9dcde0 - current 0x7f9c02e5b378 - next 0x7f9c0a5f9ba0 - value carrier1-XX.XX - hash 14 counter 6756: prev 0x7f9c02e5b378 - current 0x7f9c0a5f9ba0 - next 0x7f9c0860b968 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6757: prev 0x7f9c0a5f9ba0 - current 0x7f9c0860b968 - next 0x7f9bfe3f3a78 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6758: prev 0x7f9c0860b968 - current 0x7f9bfe3f3a78 - next 0x7f9c10d977f0 - value carrier1-XX.XX - hash 14 counter 6759: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6760: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 counter 6761: prev 0x7f9c0ae198b0 - current 0x7f9c12079f70 - next 0x7f9c011f2540 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 6762: prev 0x7f9c12079f70 - current 0x7f9c011f2540 - next 0x7f9bfff886f0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6763: prev 0x7f9c011f2540 - current 0x7f9bfff886f0 - next 0x7f9c05db00a8 - value carrier3-XX.XX= - hash 7 [...] counter 28270: prev 0x7f9c019d06e8 - current 0x7f9bfaf18290 - next 0x7f9c12c90680 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 28271: prev 0x7f9bfaf18290 - current 0x7f9c12c90680 - next 0x7f9c086a2b58 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 28272: prev 0x7f9c12c90680 - current 0x7f9c086a2b58 - next 0x7f9c0b4f09e8 - value carrier2-XX.XX▒▒▒▒ - hash 7 [...] hash table bucket 7 is still consistent regarding the loop, but already shows initial sign of corruption. There is one item of the list for hash bucket 14 visible: counter 780: prev 0x7f9c0db57ac8 - current 0x7f9c02225700 - next 0x7f9bfbf7db08 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 781: prev 0x7f9c02225700 - current 0x7f9bfbf7db08 - next 0x7f9c10d977f0 - value carrier1-XX.XX- hash 14 counter 782: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 783: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 total size of hash table is 784 #### Log Messages No special log messages observed. #### SIP Traffic SIP traffic looked ok during analysis of the core dumps. ### Possible Solutions * adding additional safe-guards for the get_profile_size function to not access data from other hash buckets * stopping the loop counter after some threshold * finding and fixing the source of the internal data corruption (obviously) * refactoring the dialog modules to use another approach for storing the dialog profile information ### Additional Information * **Kamailio version**: Kamailio 5.4.7, compiled from git repository * **Operating System**: CentOS 7.9 -- 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/2923

2 years, 1 month

[kamailio/kamailio] module keepalive bug report (Issue #3028)

by 狐狐

### Description Ka servers A(172.22.247.37) and B(172.22.247.232) use the keepalive module to check if each other's status is available. When one server such as B is down, server A will still send about 16 OPTIONS messages. When A sends the 14th or 15th OPTIONS, ka on A will change B's status to down. At this point, if B restarts, B will reply 200OK to A’s OPTIONS message, and A will change B's status to alive, but A will not send OPTIONS message to B any more. Even if B dies later, B's status will be alive on A forever. ps: if B is restart at the 14th OPTIONS or earlier, A will correctly send heartbeat OPTIONS to B later. if B is restart at the 16th or later, A will not change B's status to alive, and certainly will not sends OPTIONS to B anymore, but this is correct isn't it? question is obviously B’s status is alive on A, but A sends no OPTIONS to B. ### Troubleshooting ![image](https://user-images.githubusercontent.com/26111722/154245407-93f3ac77-3c22-4129-9877-9efa317007a5.png) ![image](https://user-images.githubusercontent.com/26111722/154245553-d19c8121-27ef-448b-933d-153843c61048.png) #### Reproduction 1. set keepalive config ant A ``` loadmodule "keepalive.so" modparam("keepalive","ping_interval",3) modparam("keepalive","destination","172.22.247.232") ``` use ka_is_alive function check B's status. 2. restart A server and confirm that the OPTIONS status is correct. 3. stop the B server until the number of retran messages reaches 15. 4. restart B server, and check OPTIONS #### Log Messages ![image](https://user-images.githubusercontent.com/26111722/154245407-93f3ac77-3c22-4129-9877-9efa317007a5.png) #### SIP Traffic ![image](https://user-images.githubusercontent.com/26111722/154245553-d19c8121-27ef-448b-933d-153843c61048.png) at the time that the arrow points to, 172.22.247.232's status is 1(refers to the log above). but notice that there is no OPTIONS message to 172.22.247.232 anymore. ![image](https://user-images.githubusercontent.com/26111722/154248962-fa6efd08-361c-4be1-b3cf-3c452d6b4e36.png) ![image](https://user-images.githubusercontent.com/26111722/154249002-f1c6b80e-2880-4c6b-bfb0-4a0f3963c6b8.png) ### Possible Solutions ### Additional Information * **Operating System**: ``` Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux kamailio 5.5.2 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3028 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3028(a)github.com>

2 years, 2 months

[kamailio/kamailio] segmentation fault on kamailio 5.4.4 (Issue #3040)

by descartin

hello all we have seen a segmentation fault on a kamailio 5.4.4 ``` #0 0x00007feb664346ad in print_lists (dlg=0x7feaa5f65290) at dlg_var.c:277 277 varlist = varlist->next; Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 elfutils-libelf-0.166-2.el7.x86_64 elfutils-libs-0.166-2.el7.x86_64 glibc-2.17-157.el7_3.5.x86_64 jansson-2.10-1.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-8.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-9.el7.x86_64 libcurl-7.29.0-35.el7.centos.x86_64 libev-4.15-7.el7.x86_64 libevent-2.0.21-4.el7.x86_64 libgcc-4.8.5-16.el7.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-6.el7.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 libuuid-2.23.2-33.el7_3.2.x86_64 libxml2-2.9.1-6.el7_2.3.x86_64 nspr-4.13.1-1.0.el7_3.x86_64 nss-3.28.4-1.2.el7_3.x86_64 nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64 nss-util-3.28.4-1.0.el7_3.x86_64 openldap-2.4.40-13.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 systemd-libs-219-30.el7_3.9.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64 (gdb) bt #0 0x00007feb664346ad in print_lists (dlg=0x7feaa5f65290) at dlg_var.c:277 #1 0x00007feb664367ff in pv_set_dlg_variable (msg=0x7feb6a881bd8, param=0x7feb6adc85a0, op=254, val=0x7ffea166a7a0) at dlg_var.c:443 #2 0x00000000004bbaf2 in lval_pvar_assign (h=0x7ffea166bbd0, msg=0x7feb6a881bd8, lv=0x7feb6adc8668, rv=0x7feb6adc87e8) at core/lvalue.c:352 #3 0x00000000004bc5f0 in lval_assign (h=0x7ffea166bbd0, msg=0x7feb6a881bd8, lv=0x7feb6adc8668, rve=0x7feb6adc87e0) at core/lvalue.c:400 #4 0x0000000000487ddf in do_action (h=0x7ffea166bbd0, a=0x7feb6adc8f80, msg=0x7feb6a881bd8) at core/action.c:1455 #5 0x0000000000489b1b in run_actions (h=0x7ffea166bbd0, a=0x7feb6adc8338, msg=0x7feb6a881bd8) at core/action.c:1581 #6 0x000000000047c6d7 in do_action (h=0x7ffea166bbd0, a=0x7feb6adce4c0, msg=0x7feb6a881bd8) at core/action.c:1067 #7 0x0000000000489b1b in run_actions (h=0x7ffea166bbd0, a=0x7feb6adc3190, msg=0x7feb6a881bd8) at core/action.c:1581 #8 0x000000000048a25f in run_top_route (a=0x7feb6adc3190, msg=0x7feb6a881bd8, c=0x7ffea166bbd0) at core/action.c:1666 #9 0x00007feb69eab0a2 in reply_received (p_msg=0x7feb6a881bd8) at t_reply.c:2543 #10 0x000000000059dc77 in do_forward_reply (msg=0x7feb6a881bd8, mode=0) at core/forward.c:764 #11 0x000000000059f949 in forward_reply (msg=0x7feb6a881bd8) at core/forward.c:865 #12 0x00000000005f095a in receive_msg ( buf=0xacec80 <buf.7134> "SIP/2.0 100 Trying\r\nVia: SIP/2.0/UDP 79.170.70.13;branch=z9hG4bK7837.ffc6315fbd54de1e6a00b32fa1cc0eda.1\r\nVia: SIP/2.0/UDP 79.170.66.28:5080;received=79.170.66.28;rport=5080;branch=z9hG4bK83ve3c7ty27QF"..., len=426, rcv_info=0x7ffea166c6c0) at core/receive.c:509 #13 0x00000000004e3cd7 in udp_rcv_loop () at core/udp_server.c:543 #14 0x0000000000429f56 in main_loop () at main.c:1689 #15 0x0000000000434034 in main (argc=15, argv=0x7ffea166cf58) at main.c:2876 ``` [Uploading core_kamailio_mia_osp_feb18.log…]() could you please take a look to the attached full backtrace? thanks a lot and regards david -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3040 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3040(a)github.com>

2 years, 2 months

[kamailio/kamailio] p_usrloc: add UTC_timestamps parameter (PR #3036)

by Stefan Mititelu

#### 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:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Enable UTC time format for expires and last_modified columns. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3036 -- Commit Summary -- * p_usrloc: add UTC_timestamps parameter -- File Changes -- M src/modules/p_usrloc/doc/p_usrloc_admin.xml (22) M src/modules/p_usrloc/p_usrloc_mod.c (18) M src/modules/p_usrloc/p_usrloc_mod.h (4) M src/modules/p_usrloc/ucontact.c (12) M src/modules/p_usrloc/udomain.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3036.patch https://github.com/kamailio/kamailio/pull/3036.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3036 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3036(a)github.com>

2 years, 2 months

[kamailio/kamailio] cdp: increase the amount of avps allocated when reading AVP_Vendor_Sp… (PR #3031)

by kristiyan-peychev-flolive

…ecific_Application_Id   #### 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 - [X] Small bug fix (non-breaking change which fixes an issue) - [ ] 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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  I've ran into issues when working with certain HSS's that sent more AVP's than were allocated. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3031 -- Commit Summary -- * cdp: increase the amount of avps allocated when reading AVP_Vendor_Specific_Application_Id -- File Changes -- M src/modules/cdp/peerstatemachine.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3031.patch https://github.com/kamailio/kamailio/pull/3031.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3031 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3031(a)github.com>

2 years, 2 months

← Newer
1
...
6
7
8
9
10
11
12
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2022