sr-dev January 2016

sr-dev@lists.kamailio.org

34 participants
295 discussions

git:master:b7c588df: tm: store last received response code before running onreply_route

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: b7c588dff06030a82f305b210573be5bbc961cec URL: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-09-07T15:56:45+02:00 tm: store last received response code before running onreply_route - otherwise an innapropriate cancel can happen if the current branch got before an 1xx response, and the script writer enforces another reply code with t_reply() - reported by Thomas Sevestre, GH#315 --- Modified: modules/tm/t_reply.c --- Diff: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Patch: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… --- diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c index b2e6e53..8da3205 100644 --- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -2286,10 +2286,21 @@ int reply_received( struct sip_msg *p_msg ) backup_xavps = xavp_set_list(&t->xavps_list); #endif setbflagsval(0, uac->branch_flags); + if(msg_status>last_uac_status) { + /* current response (msg) status is higher that the last received + * on the same branch - set it temporarily so functions in onreply_route + * can access it (e.g., avoid sending CANCEL by forcing another t_relply() + * in onreply_route when a negative sip response was received) */ + uac->last_received = msg_status; + } + /* Pre- and post-script callbacks have already * been executed by the core. (Miklos) */ run_top_route(onreply_rt.rlist[onreply_route], p_msg, &ctx); + + /* restore brach last_received as before executing onreply_route */ + uac->last_received = last_uac_status; /* transfer current message context back to t */ if (t->uas.request) t->uas.request->flags=p_msg->flags; getbflagsval(0, &uac->branch_flags);

7 years, 8 months

[kamailio] Module:sca Line seize does not release after some 'bye's (#341)

by Kevin Scott Adams

I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs. messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117 And the kamcmd showing the seize line (in this case both are seized) sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866 I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001. The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it. Thanks Kev --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/341

7 years, 9 months

[kamailio] SNMPstats dialog 0 afeter reboot (#424)

by igorPot

I have rebooted my kamailio machine and now the value of kamailio dialogs is always 0: KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0 KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0 And also the status is: KAMAILIO-MIB::kamailioDialogUsageState.0 = INTEGER: idle(0) How can I change it to active(1)? I have dialog.so loaded as well as modparam("dialog", "dlg_flag", 4) and dlg_manage(). If I do 'kamctl stats dialog': # kamctl stats dialog dialog:active_dialogs = 498 dialog:early_dialogs = 57 dialog:expired_dialogs = 24 dialog:failed_dialogs = 73222 dialog:processed_dialogs = 539449 I have the same configruation of SNMPstats and kamailio in 2 other machines and it works perfectly. In this machine it worked until I rebooted the machine. I asked this question in th emailing list and I got the following response: "Must be something in how the SNMP module reads the data from the statistics counters." I don't know if this could help. Thank you. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/424

7 years, 10 months

[kamailio] Lots of tcp_read_* errors in log, multi-transport server, lack of context in messages (#385)

by Andrey Utkin

Hi devs, The logs of our Kamailio servers are rich for such lines: ``` Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104) Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading ``` The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers. What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/385

7 years, 10 months

[kamailio] cnxcc: segmentation fault on 2 calls get terminatet - kamailio 4.3.3 (#417)

by Rick

Log: ``` Nov 25 12:01:23 sip42 kamailio[29215]: INFO: <script>: start - duration: 0 Nov 25 12:01:24 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=1.000000, ca2=0.000000 Nov 25 12:01:24 sip42 kamailio[29218]: INFO: <script>: start - duration: 0 Nov 25 12:01:25 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=4.000000, ca2=1.000000 Nov 25 12:01:26 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=7.000000, ca2=4.000000 Nov 25 12:01:27 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=9.000000, ca2=7.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=11.000000, ca2=9.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [2JR.9RLbmcERvjSelQ5zHRdAONs1pk0V]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [73tmL4-hk3-50vnsgt19E4rPMMAqHlAG]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: ERROR: cnxcc [cnxcc_mod.c:1023]: terminate_call(): Error executing dlg_end_dlg command. Return code was [404] Nov 25 12:01:28 sip42 kamailio[29246]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 45 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:728]: handle_sigs(): child process 29234 exited by a signal 11 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:731]: handle_sigs(): core was not generated Nov 25 12:01:28 sip42 kamailio[29187]: INFO: <core> [main.c:743]: handle_sigs(): terminating due to SIGCHLD ``` Stacktrace: ``` (gdb) bt full #0 0x00007f3e25b5cfba in get_hash1_raw (s=0x0, len=0) at ../../hashes.h:109 p = 0x0 v = 4284224 h = 0 #1 0x00007f3e25b5d22d in str_hash_get (ht=0x7f3e26333580, key=0x0, len=0) at ../../str_hash.h:94 h = 32766 e = 0x301c31c78 #2 0x00007f3e25b69167 in __free_call (call=0x7f3e2646da00) at cnxcc_mod.c:910 e = 0x0 __FUNCTION__ = "__free_call" #3 0x00007f3e25b68dd5 in terminate_all_calls (credit_data=0x7f3e2646d950) at cnxcc_mod.c:899 call = 0x7f3e2646da00 tmp = 0x7f3e2646da00 __FUNCTION__ = "terminate_all_calls" #4 0x00007f3e25b5952f in check_calls_by_money (ticks=51698976, param=0x0) at cnxcc_check.c:109 credit_data = 0x7f3e2646d950 call = 0x7f3e2646da00 total_consumed_money = 11 consumption_diff = 2 h_entry = 0x7f3e2646d858 tmp = 0x7f3e26335c00 tmp_call = 0x7f3e2647d680 i = 118 __FUNCTION__ = "check_calls_by_money" #5 0x00000000005bcf1c in fork_basic_timer (child_id=-1, desc=0x7f3e25b866fd "CNXCC TB TIMER", make_sock=1, f=0x7f3e25b58200 <check_calls_by_money>, param=0x0, interval=1) at timer_proc.c:79 pid = 0 #6 0x00007f3e25b5ffce in __child_init (rank=0) at cnxcc_mod.c:383 pid = 0 __FUNCTION__ = "__child_init" #7 0x00000000005143d4 in init_mod_child (m=0x7f3e315cf8a8, rank=0) at sr_module.c:915 __FUNCTION__ = "init_mod_child" #8 0x00000000005146db in init_child (rank=0) at sr_module.c:941 No locals. #9 0x0000000000505cef in main_loop () at main.c:1654 i = 4 pid = 1327 si = 0x0 si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\061\000*>\177\000\000\240.~\264\376\177\000\000\a<\355*>\177\000\000y%p\000\000\000\000\000ȥ3&>\177\000\000\220$\361*>\177\000\000\300(l1>\177\000\000\000\371\360*>\177\000\000\003\000\000\000>\177\000\000\060.~\264\376\177\000\000xBI\000\000\000\000" nrprocs = 4 __FUNCTION__ = "main_loop" #10 0x000000000050be5a in main (argc=13, argv=0x7ffeb47e3138) at main.c:2553 cfg_stream = 0x1b9c010 c = -1 r = 0 tmp = 0x7ffeb47e4ee2 "" tmp_len = 32574 port = 846456272 proto = 0 options = 0x71cae0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1760074178 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0xf63d4e2e p = 0x7f3e3273e000 "" st = {st_dev = 15, st_ino = 9426, st_nlink = 2, st_mode = 16877, st_uid = 109, st_gid = 114, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_mtim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_ctim = {tv_sec = 1448451190, tv_nsec = 195999907}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/417

7 years, 10 months

[kamailio] kamailio crash when use http_query (#468)

by situnan

1file:modules/utils/functionsc 2Problem Description：Array Overflow and View Code Label：wsong@grandstreamcn size_t write_function( void *ptr, size_t size, size_t nmemb, void *stream_ptr) { http_res_stream_t *stream = (http_res_stream_t *) stream_ptr; stream->buf = (char *) pkg_realloc(stream->buf, stream->curr_size + (size * nmemb) + 1); if (stream->buf == NULL) { LM_ERR("cannot allocate memory for stream\n"); return CURLE_WRITE_ERROR; } memcpy(&stream->buf[stream->pos], (char *) ptr, (size * nmemb)); stream->curr_size += ((size * nmemb) + 1); stream->pos += (size * nmemb); //begin modify wsong@grandstreamcn // reason:stream->buf size begin with 0 // stream->buf[stream->pos + 1] = '\0'; stream->buf[stream->pos ] = '\0'; //end modify wsong@grandstreamcn return size * nmemb; } --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/468

7 years, 11 months

[kamailio] Makefile System hangs the computer (#479)

by tanton81

Hello everyone, I will try to describe a problem that I encountered recently while I was recompiling Kamailio 431 Probably the problem has been already mentioned by someone at the bug tracker but I couldn't find such a topic So, I had an installed and already configured and working Kamailio I decided simply to add a new module to it, for that I made the following instructions: 'make proper' -> result OK 'make include_modules="the list of needed modules" cfg' -> slows the whole OS (Linux SLED 12), I had a constant disk activity during the time I was waiting to see how the things will finish After that I tried the same on a different machine, which is the same (virtual machine) , unfortunately the result was the same After several retries I found that it is impossible to do: make proper make include_modules="" cfg I found that I had to type a 'make cfg' after the 'make proper': make proper make cfg make include_modules="" cfg make all I hadn't the time to find out why there is a such problem but I suppose that when you do a 'make proper' your configuration file is deleted Than 'make cfg' creates this config file again and finally 'make include_modules' looks for this configuration file and fills it with the complementary modules Without this configuration file the 'make include_modules="" cfg probably enters to an infinite loop which as result makes your OS not respond Can anyone confirm the problem ? Best regards, Anton --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/479

8 years, 1 month

[kamailio] Database timeout over SSL? (#406)

by Tobias Lindgren

Hi, having some rare issues writing acc-data to a remote MySQL server. The connection is made using the MySQL SSL options. Most, 99,9%, of the writes work well. The error is: ``` Nov 20 13:48:55 /usr/sbin/kamailio[28976]: WARNING: db_mysql [km_dbase.c:84]: db_mysql_submit_query(): driver error on ping: SSL connection error: socket layer receive error Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: db_mysql [km_dbase.c:121]: db_mysql_submit_query(): driver error on query: SSL connection error: socket layer receive error Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query ``` Apart from the connection details (using [mysql-ssl-conf] for the SSL config block) I have this config: ``` modparam("db_mysql", "ping_interval", 30); modparam("db_mysql", "timeout_interval", 8); ``` The documentation suggests that "ping_interval" is the "Time interval in seconds to send ping messages to MySQL server in order to keep the connection open." However, looking at the code this seems a bit misleading because it looks like the ping is only done on an actual query (db_mysql_submit_query), i.e. not with a regular interval/on a timer as suggested by the documentation? Also the "auto_reconnect" parameter is stated as default 1 (on), but in the code this is just used as a "retry" of the query itself and MYSQL_OPT_RECONNECT is never set on the connection (https://dev.mysql.com/doc/refman/5.5/en/auto-reconnect.html)? Maybe this is not necessary and it's enough to just re-try the query? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/406

8 years, 2 months

[kamailio] rr: add enable_double_rr_always option (#257)

by Andrey Utkin

This patch helps us to handle inadequatness of Linphone mobile apps (both iOS and Android flavours are affected) without reinventing a lot of logics to handle each transport (we use TCP, TLS, WS, WSS). E.g. if we have two TLS-based Linphone clients, even with enable_double_rr for gentle cross-forwarding we would get single RR header without transport= attribute, resulting in Linphone sending ACK and BYE via UDP. This new option, being enabled, results in two RR headers being always inserted, with transport attribute being always added. I believe this cannot harm the installation with enable_double_rr, just makes instructions more explicit. The Linphone's behaviour looks like a set of different bugs, but it would get us much more efforts to fix. I don't know if any other useragent needs such workaround. So I would perfectly understand if this commit wouldn't be accepted upstream. Also this commit currently lacks README doc rebuild, because I don't know how to do that. Only XML doc is updated. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/257 -- Commit Summary -- * rr: add enable_double_rr_always option -- File Changes -- M modules/rr/doc/rr_admin.xml (24) M modules/rr/record.c (14) M modules/rr/rr_mod.c (2) M modules/rr/rr_mod.h (1) M tcp_read.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/257.patch https://github.com/kamailio/kamailio/pull/257.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/257

8 years, 2 months

[kamailio] registrar: Custom socket string for location table (related to pr #470) (#471)

by Ian Yu-Hsun Lin

# Environment Kamailio-433 installed behind nat (Amazon EC2 or Google Compute Engine) using config ```cfg listen=PRIVATE_IP:PORT advertise PUBLIC_IP:PORT ``` # What I wanted to do In table `location`, the column `socket` will be stored in the form of "PROTO:**PRIVATE_IP**:PORT" while for some reasons I would like it to be stored as "PROTO:**PUBLIC_IP**:PORT" Through the `registrar` document there is the [xavp_cfg](http://wwwkamailioorg/docs/modules/43x/modules/registrarhtml#registrarpxavp_cfg) parameter that can be used in conjunction with the attribute "socket" to specify the socket string From my understanding this might be the solution to my requirement # Problem The column `location``socket` wasn't changed when setting the custom socket string via `xavp_cfg` After looking into the source code, firstly, a potential bug (correct me if I'm wrong) that it would reset the `sock_flag` to -1 (no flags) even if `reg_xavp_cfg` and `sock_flag` is set A pull request #470 has been opened for this Secondly, if we pass the above problem, in `savec` it did grab the socket string from xavp_cfg and in function `grep_sock_info()` the socket string was checked with all the address we listen on, including the advertised public address via `socket_info->useinfo` But the returned socket structure still contains the private address info # Conclusion so far So, I wasn't sure if using the parameter `xavp_cfg` for setting socket string and stores it in location table make sense or not If yes, can you please giving me some hints about the potential way to extend this? Cheers, Ian --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/471

8 years, 2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev January 2016