sr-dev December 2021

sr-dev@lists.kamailio.org

11 participants
271 discussions

[kamailio/kamailio] crash related to functions in cfg file parser for invalid cfg (#2239)
by Henning Westerholt 14 Jun '22

14 Jun '22

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

2 2

[kamailio/kamailio] [Feature Request] Add reload capability for geoip2 module (#2029)
by Joel Serrano 13 Apr '22

13 Apr '22

### 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 3

[kamailio/kamailio] Kamailio 5.4.x dialog profiles functionality dead-lock on certain high-load scenarios (Issue #2923)
by Henning Westerholt 30 Mar '22

30 Mar '22

### 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

3 6

[kamailio/kamailio] There is no jwt.so (#2883)
by hance2010 02 Mar '22

02 Mar '22

5 7

[kamailio/kamailio] db_redis: cluster support (Issue #2977)
by Riccardo-78 23 Feb '22

23 Feb '22

### Description At the moment db_redis driver does not support interfacing with a redis cluster. This is a proposal to add support to it. The db_redis module will get a new module parameter to enable cluster support (with default 0 - disabled): ``` modparam("db_redis", "cluster", 1) ``` The redis url used by other modules needs to specify all nodes in the cluster, and must NOT include redis database number (since it's not supported in cluster mode): ``` #!define DBURL_USRLOC "redis://10.0.1.1:6379,10.0.1.2:6379,10.0.1.3:6379" ``` The implementation is going to use the [hiredis-cluster](https://github.com/Nordix/hiredis-cluster) library (BSD license). If cluster mode is not enabled the module will behave like before, i.e. all calls to redis will use hiredis library directly. If you find this proposal sensible, I'll start coding it. Feedback is welcome, of course! -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2977 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2977(a)github.com>

3 5

[kamailio/kamailio] Enable CentOS 7 to build with OpenSSL 1.1.1 package from EPEL (#2779)
by space88man 08 Feb '22

08 Feb '22

#### 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 EPEL now includes a openssl11 package for CentOS 7. This feature is for users who want to build kamailio-tls with OpenSSL 1.1.1 instead of OpenSSL 1.0.2. It is implemented as a `--with=openssl11` conditional (the default os off), so should not affect/change the regular CentOS 7 builds as distributed by kamailio.org. This is for adventurous users on CentOS 7 willing to maintain their own OpenSSL 1.1.1-enabled TLS package. EPEL dependencies( openssl11-libs, openssl11-devel) are required at runtime and for build. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2779 -- Commit Summary -- * pkg: enable CentOS 7 to build with OpenSSL 1.1.1 -- File Changes -- M pkg/kamailio/obs/kamailio.spec (32) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2779.patch https://github.com/kamailio/kamailio/pull/2779.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/2779

3 13

[kamailio/kamailio] Localy generated transaction with dns failover and socket forcing (Issue #2987)
by Dennis 02 Feb '22

02 Feb '22

### Description DNS failover do not wok for localy generated transaction when script forcing socket or sets Via parameters with corex via_add_srvid/via_add_xavp_params, in log appear the errors: ``` Dec 24 13:30:17 sbc kamailio[9772]: 10(9800) DEBUG: <core> [core/parser/parse_uri.c:1306]: parse_uri(): bad uri, state 0 parsed: <<F3>gbf> (4) / <<F3>gbf#017^?> (38) Dec 24 13:30:17 sbc kamailio[9772]: 10(9800) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: [<F3>gbf#017^?] ``` #### Reproduction Config stripped for localize problem: ``` #!define IPADDR_THISNODE "192.168.122.130" #!subst "/IPADDR_THISNODE/192.168.122.130/" #!define MULTIDOMAIN 0 ####### Global Parameters ######### #!define WITH_DEBUG ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ children=8 server_id = 10 xavp_via_params = "via" /* uncomment the next line to disable TCP (default on) */ disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases * based on reverse DNS on IPs (default on) */ # auto_aliases=no /* listen on local and anycast addresses */ listen=udp:IPADDR_THISNODE:5060 #### DNS settings use_dns_cache = on # Use KAMAILIO internal DNS cache use_dns_failover = on # Depends on KAMAILIO internal DNS cache #dns_srv_loadbalancing = on # #dns_try_naptr = on # dns_try_naptr = off # dns_retr_time=1 # Time in seconds before retrying a DNS request dns_retr_no=1 # Number of DNS retransmissions before giving up dns_try_ipv6=yes dns_use_search_list=no ####### Modules Section ######## /* set paths to location of modules */ loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "counters.so" loadmodule "dispatcher.so" # ----------------- setting module-specific parameters --------------- # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) /* set the path to RPC fifo control file */ # modparam("jsonrpcs", "fifo_name", "/run/kamailio/kamailio_rpc.fifo") /* set the path to RPC unix socket control file */ # modparam("jsonrpcs", "dgram_socket", "/run/kamailio/kamailio_rpc.sock") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # ----- tm params ----- modparam("tm", "fr_timer", 2000) #modparam("tm", "reparse_on_dns_failover", 0) # ----- dispatcher params ----- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_probing_threshold", 2) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "outbound_proxy", "sip:proxy") # ----- corex params ----- modparam("corex", "dns_cache", "type=A;name=proxy;addr=192.168.122.129;ttl=3600000;flags=2") modparam("corex", "dns_cache", "type=A;name=proxy;addr=192.168.122.131;ttl=3600000;flags=2") # ----- rr params ----- # set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 0) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) onsend_route { xinfo(">> onsend_route snd_to=$sndto(ip)\n"); } event_route [tm:local-request] { xlog("L_INFO", ">> Routing locally generated $rm to $ru\n"); xinfo(">> mbu: $mbu"); $fs = "udp:IPADDR_THISNODE:5060"; // This have the same effect as forcing socket // via_add_srvid(1); t_set_fr(1000,250); } ``` disparcher list have only one target: `110 sip:192.168.122.131:5060;transport=udp 0 1` The scenario is simple - dispatcher try to ping target via proxy, config have two "A" records in cache, all work as expected until tm:local-request route modify Via header by setting $fs or one of the corex module functions which set flags FL_ADD_SRVID|FL_ADD_XAVP_VIA_PARAMS|FL_USE_XAVP_VIA_FIELDS, tm in this case (after error as above) decline failover. #### Debugging Data transaction fail log: ``` Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: dispatcher [dispatch.c:3546]: ds_ping_result_helper(): probe all, mode DS_PROBE_ALL Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: dispatcher [dispatch.c:3589]: ds_ping_set(): probing set #110, URI sip:192.168.122.131:5060;transport=udp Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: dispatcher [dispatch.c:3620]: ds_ping_set(): Default ping_from: sip:dispatcher@localhost Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: dispatcher [dispatch.c:3630]: ds_ping_set(): Default outbound proxy: sip:proxy Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:457]: t_uac_prepare(): next_hop=<sip:proxy> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/dns_cache.c:527]: _dns_hash_find(): (_sip._udp.proxy(15), 33), h=170 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/dns_cache.c:3050]: dns_srv_resolve_ip(): ("_sip._udp.proxy", 0, 0), ret=-5, ip= Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/dns_cache.c:527]: _dns_hash_find(): (proxy(5), 1), h=878 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/dns_cache.c:2807]: dns_a_resolve(): (proxy, 0) returning 0 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/dns_cache.c:3176]: dns_srv_sip_resolve(): (proxy, 0, 0), ip, ret=0 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 55725 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:246]: t_run_local_req(): executing event_route[tm:local-request] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <OPTIONS> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKda9d.ac749307000000000000000000000000.0>; state=16 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) INFO: <script>: >> Routing locally generated OPTIONS to sip:192.168.122.131:5060;transport=udp Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) INFO: <script>: >> mbu: OPTIONS sip:192.168.122.131:5060;transport=udp SIP/2.0 Dec 24 13:15:37 sbc kamailio[9772]: Via: SIP/2.0/UDP 192.168.122.130;branch=z9hG4bKda9d.ac749307000000000000000000000000.0 Dec 24 13:15:37 sbc kamailio[9772]: To: <sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: From: <sip:dispatcher@localhost>;tag=e92e326f0a937cb326014225217c2c12-5929046b Dec 24 13:15:37 sbc kamailio[9772]: CSeq: 10 OPTIONS Dec 24 13:15:37 sbc kamailio[9772]: Call-ID: 62100fd077a3a243-9799(a)192.168.122.130 Dec 24 13:15:37 sbc kamailio[9772]: Max-Forwards: 70 Dec 24 13:15:37 sbc kamailio[9772]: Content-Length: 0 Dec 24 13:15:37 sbc kamailio[9772]: User-Agent: kamailio (5.5.3 (x86_64/linux)) Dec 24 13:15:37 sbc kamailio[9772]: #015 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: pv [pv_core.c:2703]: pv_set_force_sock(): trying to set send-socket to [udp:192.168.122.130:5060] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/socket_info.c:641]: grep_sock_info(): checking if host==us: 15==15 && [192.168.122.130] == [192.168.122.130] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/socket_info.c:648]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:314]: t_run_local_req(): local Via update - new socket: [192.168.122.130] - msg-flags: 0 9(9799) DEBUG: tm [uac.c:340]: t_run_local_req(): apply new updates with Via to sip msg Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <OPTIONS> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKda9d.ac749307000000000000000000000000.0>; state=16 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [To] type 3 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [42]; uri=[sip:192.168.122.131:5060;transport=udp] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (42)[<sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: ], to tag (0)[] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [From] type 4 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [CSeq] type 5 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <10> <OPTIONS> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Content-Length] type 12 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [User-Agent] type 28 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <OPTIONS> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKda9d.ac749307000000000000000000000000.0>; state=16 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [To] type 3 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [42]; uri=[sip:192.168.122.131:5060;transport=udp] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (42)[<sip:192.168.122.131:5060;transport=udp> Dec 24 13:15:37 sbc kamailio[9772]: ], to tag (0)[] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [From] type 4 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [CSeq] type 5 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <10> <OPTIONS> Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:189]: uac_refresh_hdr_shortcuts(): cseq: [CSeq: 10] Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) DEBUG: tm [uac.c:685]: send_prepared_request_impl(): uac: 0x7f0f6262b9c8 branch: 0 to 192.168.122.131:5060 Dec 24 13:15:37 sbc kamailio[9772]: 9(9799) INFO: <script>: >> onsend_route snd_to=192.168.122.131 Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: <core> [core/parser/parse_uri.c:1306]: parse_uri(): bad uri, state 0 parsed: <<F3>gbf> (4) / <<F3>gbf#017^?> (38) Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: [<F3>gbf#017^?] Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: tm [t_reply.c:1592]: t_should_relay_response(): rps completed - uas status: 0 branch: 0 Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: tm [t_reply.c:2236]: local_reply(): branch=0, save=0, winner=0 Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: tm [t_reply.c:2275]: local_reply(): local transaction completed 408/0 (totag retr: 0/1024) Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: tm [t_hooks.c:256]: run_trans_callbacks_internal(): DBG: trans=0x7f0f6262b738, callback type 1024, id 0 entered Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: dispatcher [dispatch.c:3491]: ds_options_callback(): OPTIONS-Request was finished with code 408 (to sip:192.168.122.131:5060;transport=udp, group 110) Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: dispatcher [dispatch.c:2973]: ds_update_state(): update state for sip:192.168.122.131:5060;transport=udp in group 110 to 10 Dec 24 13:15:37 sbc kamailio[9772]: 10(9800) DEBUG: dispatcher [dispatch.c:3049]: ds_update_state(): old state was 9, set new state to 9 ``` I think that error somewhere in memory management when allocating/free structures for Via header modification which is hard to debug, i have insert several debug output in uac.c in my case the problem fire after a call of function insert_tmcb: ``` /* Register the callbacks after everything is successful and nothing can fail. Otherwise the callback parameter would be freed twise, once from TMCB_DESTROY, and again because of the negative return code. */ {// extra debug struct ua_client *uac=&request->my_T->uac[0]; LM_DBG(">>>>> Before insert_tmcb\n"); LM_DBG(">>>>> request uac: %p urip: %p uri: %.*s\n", uac, &uac->uri, STR_FMT(&uac->uri)); uac=&new_cell->uac[0]; LM_DBG(">>>>> new_cell uac: %p urip: %p uri: %.*s\n", uac, &uac->uri, STR_FMT(&uac->uri)); } if(uac_r->cb && insert_tmcb(&(new_cell->tmcb_hl), uac_r->cb_flags, *(uac_r->cb), uac_r->cbp, NULL)!=1){ ret=E_OUT_OF_MEM; LM_ERR("short of tmcb shmem\n"); goto error1; } {// extra debug struct ua_client *uac=&request->my_T->uac[0]; LM_DBG(">>>>> After insert_tmcb\n"); LM_DBG(">>>>> request uac: %p urip: %p uri: %.*s\n", uac, &uac->uri, STR_FMT(&uac->uri)); uac=&new_cell->uac[0]; LM_DBG(">>>>> new_cell uac: %p urip: %p uri: %.*s\n", uac, &uac->uri, STR_FMT(&uac->uri)); } ``` In log i see: ``` Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:189]: uac_refresh_hdr_shortcuts(): cseq: [CSeq: 10] Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:591]: t_uac_prepare(): >>>>> Before insert_tmcb Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:592]: t_uac_prepare(): >>>>> request uac: 0x7f72407959c8 urip: 0x7f7240795bd8 uri: sip:192.168.122.131:5060;transport=udp Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:594]: t_uac_prepare(): >>>>> new_cell uac: 0x7f72407959c8 urip: 0x7f7240795bd8 uri: sip:192.168.122.131:5060;transport=udp Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:604]: t_uac_prepare(): >>>>> After insert_tmcb Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:605]: t_uac_prepare(): >>>>> request uac: 0x7f72407959c8 urip: 0x7f7240795bd8 uri: <F3>#007yDr^? Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:607]: t_uac_prepare(): >>>>> new_cell uac: 0x7f72407959c8 urip: 0x7f7240795bd8 uri: <F3>#007yDr^? Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) DEBUG: tm [uac.c:699]: send_prepared_request_impl(): uac: 0x7f72407959c8 branch: 0 to 192.168.122.131:5060 Dec 24 14:36:39 sbc kamailio[12709]: 9(12732) INFO: <script>: >> onsend_route snd_to=192.168.122.131 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: <core> [core/parser/parse_uri.c:1306]: parse_uri(): bad uri, state 0 parsed: <<F3>#007yD> (4) / <<F3>#007yDr^?> (38) Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: [<F3>#007yDr^?] Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: tm [t_reply.c:1592]: t_should_relay_response(): rps completed - uas status: 0 branch: 0 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: tm [t_reply.c:2236]: local_reply(): branch=0, save=0, winner=0 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: tm [t_reply.c:2275]: local_reply(): local transaction completed 408/0 (totag retr: 0/1024) Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: tm [t_hooks.c:256]: run_trans_callbacks_internal(): DBG: trans=0x7f7240795738, callback type 1024, id 0 entered Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: dispatcher [dispatch.c:3491]: ds_options_callback(): OPTIONS-Request was finished with code 408 (to sip:192.168.122.131:5060;transport=udp, group 110) Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: dispatcher [dispatch.c:2973]: ds_update_state(): update state for sip:192.168.122.131:5060;transport=udp in group 110 to 10 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: dispatcher [dispatch.c:3004]: ds_update_state(): destination did not replied 1 times, threshold 2 Dec 24 14:36:40 sbc kamailio[12709]: 10(12733) DEBUG: dispatcher [dispatch.c:3049]: ds_update_state(): old state was 0, set new state to 10 ``` insert_tmcb have shm_malloc fincion call in the beninig, after this call the content of uri structure is broken. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.5.3 (x86_64/linux) 473cef 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. ``` * **Operating System**: ``` Ubuntu 18.04.6 LTS ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2987 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2987(a)github.com>

3 8

[kamailio/kamailio] register using uac module is getting send even if send_socket is not in this listening list of kamailio (#2624)
by Surendra Tiwari 31 Jan '22

31 Jan '22

### Description I am uac module with database. uacreg table have the send_socket column. i do have 2 kamailio server running. i want only kamailio-1 should send register to uacreg entries. for this i have used send_socket column with socket of kamailio-1. After this we can see both kamailio server sending registration and that's the problem.  ### Troubleshooting #### Reproduction loadmodule "uac.so" modparam("uac","auth_username_avp","$avp(auser)") modparam("uac","auth_password_avp","$avp(apass)") modparam("uac","auth_realm_avp","$avp(arealm)") modparam("uac", "reg_contact_addr", "EXTERNAL_IP:5060") modparam("uac", "reg_db_url", DBURL) and use send_socket into uacreg with kamailio-1 socket.  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.8 (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**:  ``` root@ip-10-0-12-135:/etc/kamailio# uname -a Linux ip-10-0-12-135 5.3.0-1019-aws #21~18.04.1-Ubuntu SMP Mon May 11 12:33:03 UTC 2020 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/2624

5 10

[kamailio/kamailio] app_lua: build warning (#2728)
by sergey-safarov 29 Jan '22

29 Jan '22

``` which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) CC (gcc) [M app_lua.so] app_lua_api.o app_lua_api.c: In function 'lua_sr_kemi_register_libs': app_lua_api.c:1942:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplicit-f unction-declaration] 1942 | luaL_openlib(L, "KSR", _sr_crt_KSRMethods, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua.so] app_lua_kemi_export.o CC (gcc) [M app_lua.so] app_lua_mod.o LD (gcc) [M app_lua.so] app_lua.so which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) CC (gcc) [M app_lua_sr.so] app_lua_sr_api.o app_lua_sr_api.c: In function 'lua_sr_core_openlibs': app_lua_sr_api.c:1614:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici t-function-declaration] 1614 | luaL_openlib(L, "sr", _sr_core_Map, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua_sr.so] app_lua_sr_exp.o app_lua_sr_exp.c: In function 'lua_sr_exp_openlibs': app_lua_sr_exp.c:3686:3: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici t-function-declaration] 3686 | luaL_openlib(L, "sr.sl", _sr_sl_Map, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua_sr.so] app_lua_sr_mod.o LD (gcc) [M app_lua_sr.so] app_lua_sr.so ``` -- 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/2728

2 10

[kamailio/kamailio] DB_UNIXODBC always reports errors for sql queries with no result set (#2810)
by kdanderso 17 Jan '22

17 Jan '22

### Description SQL queries that do not return a result set (such as INSERT, DELETE, UPDATE) always report errors when using db_unixodbc. The query succeeds, but the log indicates a failure. #### Reproduction Use db_unixodbc.so for sql queries. Issue a valid query such as INSERT that is not expected to return a result set. #### Log Messages ERROR: db_unixodbc [res.c:52]: db_unixodbc_get_columns(): no columns returned from the query ERROR: db_unixodbc [res.c:253]: db_unixodbc_convert_result(): getting column names failed ERROR: db_unixodbc [dbase.c:271]: db_unixodbc_store_result(): failed to convert result ERROR: <core> [db_query.c:197]: db_do_raw_query(): error while storing result ERROR: sqlops [sql_api.c:297]: sql_do_query(): cannot do the query [DELETE FROM mytable WHERE id = 1] ### Additional Information Kamailio Version 5.5.0 This issue was also reported to SR-users, but that user did not open an issue. (See https://lists.kamailio.org/pipermail/sr-users/2018-March/100581.html) -- 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/2810

2 5

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2021