sr-users January 2010

sr-users@lists.kamailio.org

73 participants
127 discussions

[Kamailio-Users] tcp_blocking_connect related errors and Kamailio using 100% CPU

by Pascal Maugeri

Hi Using Kamailio 1.5 we periodically get the following errors: Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (110) Connection timed out Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:core:tcp_send: connect failed Jul 1 09:54:41 localhost /usr/local/sbin/openser[3836]: ERROR:tm:msg_send: tcp_send failed They are several emails in this mailing list explaining we should play with tcp parameters. I will try to change my configuration and see if we can solve this issue. But when this kind of error happen we observe that the kamailio processes are using 100% of CPU (top). Our client is using SIP over TCP only (no UDP). Do you have any hint on how to configure Kamailio to improve TCP support ? Is it normal to kamailio processes to overload CPU ? Regards, Pascal

14 years, 9 months

Re: [SR-Users] TLS problems

by Andreas Rehbein

Hi, I solved the problem within snom370 registration with TLS: It was necessary to set the TLS-Modul Parameter "cipher_list" to RSA. Now the snom 370 registers via TLS. Thanks Klaus! regards Andreas

14 years, 9 months

Re: [SR-Users] TLS problems

by Andreas Rehbein

Hello Klaus, thank you very much! I really appreciate your help! I followed your instructions and I hope that the attached file includes the necessary informations. regards Andreas -----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Freitag, 22. Januar 2010 10:50 An: Andreas Rehbein Betreff: Re: AW: [SR-Users] TLS problems Andreas Rehbein schrieb: > Hi Klaus! > > Yes, the crash happens everytime (and immediately) when I push the > "Register"-Button in snoms web-gui. > > I attached the backtrace-file, but until now I did not rebuild kamailio with > -DDBG_QM_MALLOC. Please let me know if it's necessary. the log only shows the last function call. Please start gdb again and at the gdb prompt generate a backtrace by entering bt, e.g: (gdb) bt regards klaus > > regards > Andreas > > -----Ursprüngliche Nachricht----- > Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Gesendet: Freitag, 22. Januar 2010 09:35 > An: Andreas Rehbein > Cc: sr-users(a)lists.sip-router.org > Betreff: Re: [SR-Users] TLS problems > > Hi Andreas! > > Maybe this is the same bug I reported yesterday. Unfortunately I can not > reproduce the crash anymore. > > Does the crash happen everytime? > > Kamailio produced a core dump: > > 0(6257) ALERT: <core> [main.c:725]: core was generated > > So please send a the backtrace: > # gdb kamailio /path/to/corefile > > bt > > Location of the core file is usually / or /tmp or the kamailio's working > directory. Use > # cat /proc/sys/kernel/core_pattern > to find the exact location of the core dump. > > Further, it might be useful to enable memory debugging: > - in Makefile.defs use -DDBG_QM_MALLOC instead of -DF_MALLOC and > rebuild/reinstall kamailio > - set higher loglevels in kamailio.cfg > memlog=3 > memdbg=3 > debug=3 > modparam("tls", "tls_log", 3) > > Note: this excessive logging makes kamailio start/stop real slow and > logfile will increase rapidly (might fill up your hard disk) > > regards > klaus > > > > Andreas Rehbein schrieb: >> Hi, >> >> >> >> Ive installed Kamailio 3.0 on RHEL5 and activated the mysql backend and >> tls support. Everything works fine with Soft User Agent Phoner lite. >> My Problem is: If I try to register a snom 370 Kamailio crashes >> immediatly. What is wrong? Any suggestions? >> >> Debug: >> >> 17(6290) DEBUG: <core> [ip_addr.c:116]: tcpconn_new: new tcp connection: >> 192.168.0.222 >> >> 17(6290) DEBUG: <core> [tcp_main.c:1052]: tcpconn_new: on port 1430, type > 3 >> 17(6290) DEBUG: <core> [tcp_main.c:1351]: tcpconn_add: hashes: >> 978:1690:1400, 1 >> >> 17(6290) DEBUG: <core> [io_wait.h:361]: DBG: io_watch_add(0x8222fe0, 31, >> 2, 0xb613a2b8), fd_no=24 >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, >> 31, -1, 0x0) fd_no=25 called >> >> 17(6290) DEBUG: <core> [tcp_main.c:3627]: tcp: DBG: sendig to child, >> events 1 >> >> 17(6290) DEBUG: <core> [tcp_main.c:3336]: send2child: to tcp child 0 >> 13(6283), 0xb613a2b8 >> >> 13(6283) DEBUG: <core> [tcp_read.c:884]: received n=4 con=0xb613a2b8, fd=8 >> >> 13(6283) DEBUG: tls [tls_server.c:109]: Using TLS domain TLSs<default> >> >> 17(6290) DEBUG: <core> [tcp_main.c:2826]: DBG: handle_tcp_child: dead >> tcp child 0 (pid 6283, no 13) (shutting down?) >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, >> 24, -1, 0x0) fd_no=24 called >> >> 17(6290) : <core> [pass_fd.c:283]: ERROR: receive_fd: EOF on 4 >> >> 17(6290) DEBUG: <core> [tcp_main.c:3038]: DBG: handle_ser_child: dead >> child 13, pid 6283 (shutting down?) >> >> 17(6290) DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x8222fe0, 4, >> -1, 0x0) fd_no=23 called >> >> 0(6257) ALERT: <core> [main.c:722]: child process 6283 exited by a >> signal 11 >> >> 0(6257) ALERT: <core> [main.c:725]: core was generated >> >> 0(6257) INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD >> >> 17(6290) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 15(6286) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 16(6289) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 12(6281) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 14(6285) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 10(6278) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 6(6269) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 2(6261) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 11(6280) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 1(6260) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 9(6276) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 8(6272) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 3(6262) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 7(6270) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 5(6267) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 4(6265) INFO: <core> [main.c:788]: INFO: signal 15 received >> >> 0(6257) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start >> >> 0(6257) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash > table >> 0(6257) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing > semaphores >> 0(6257) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb >> lists >> >> 0(6257) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done >> >> 0(6257) DEBUG: tls [tls_init.c:621]: tls module final tls destroy >> >> 0(6257) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy >> >> 0(6257) DEBUG: <core> [mem/shm_mem.c:239]: destroying the shared memory >> lock >> >> 0(6257) DEBUG: <core> [main.c:741]: terminating due to SIGCHLD >> >> >> >> tia >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

14 years, 9 months

[Kamailio-Users] kamailio 1.5.4

by Daniel-Constantin Mierla

Hello, should we package kamailio 1.5.4? 1.5.3 was in october last year, there were some commits around since then. Next week monday? 1.4.x got out of maintenance period, should we do the 1.4.5 (just release tarballs) to mark that? Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 9 months

Re: [SR-Users] Request for a special parallel + serial forking scenario

by Klaus Feichtinger

> > Klaus Feichtinger schrieb: > > > >>> Hi, > >>> > >>> I have a special question regarding a mixture of parallel and serial > >>> forking, operated by Kamailio-3.0.0. > >>> > >>> First of all I will give you a short background information, what the > >>> target will be: > >>> > >>> I have a SIP-server on place A, 3 gateways on place B and 3 gateways > >>> on place C). These gateways are registered on SIP server (A) with > >>> different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8, > >>> GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST > >>> be signalled on place B and C in parallel (forking) until the call is > >>> finally established over one of the two involved gateways on place B > >>> or C. When the prime gateway(s) (with the highest Q-value) fail (e.g. > >>> they do not send a provisional response within a timeout or send a > >>> negative response), the next gateway(s) should be addressed (with the > >>> next lower Q-value), a.s.o. > >>> > >>> The configuration works well in case that both gateways on place B > >>> and C fail at the same time (BOTH do not send a response or BOTH send > >>> a negative response or one does not send a response and the other one > >>> sends a negative response). However, in case that only ONE of the two > >>> (always in parallel) addressed gateways fails, it does not work as > >>> expected. > >> > >> What is expected? > >> > >> Do you want to trigger failover to lower priority even if one the > >> gateways is still working fine? You can not do that with sip-router. > >> sr implements parallel forking according to RFC3261, this means it > >> will not generate a failure response as long as one of the branches is > >> still active, maybe sending 200 ok. > >> > > The ideal behaviour would be following: > > - try reaching a gateway on place B and C until one gateway on every > > place (B AND C) sends back a positive (provisional) response - e.g. 180 > > ringing, 183 session progress > > > > - in case that one of the two parallel addressed gateways is reachable > > and sends back a provisional response (= "it is alive"), keep it > > > > - in case that the other one (of the two parallel addressed gateways) > > has a problem (negative response 480 / 404 / 486 ...) or is unreachable > > (= |fr_inv_timer_next| timeout), try the next gateway on this specific > place > > > I'm still not sure if I understand it correct. May examples help: > > the call is forwarded to B1 and C1. B1 does not send back anything, C1 > sends back 100 trying. What is the expected behavior? > - CANCEL C1 and send the call to B2 and C2? > - keep C1 and send another call to B2? > - stay with B1 unreachable and possible C1 answering the call? > The second variant with "keep C1 and send another call to B2" is the expected behaviour. > > - the parallelism is necessary, because calls over these gateways are > > addressed to a usergroup which is split to place B and C behind a > > redundant "non-SIP" PBX system with two active halfs); you can not > > suspect if a user on place B or a user on place C will take the call; > > therefore the call has to be sent to both places. > > Ok. > > > However, the favored behaviour is not standard conform - I know. I guess > > therefore I would need a B2BUA, which is able to establish two > > independent (serially forked) preliminary connections to gateways on > > place B and C and interconnects the successful call to the call > > originator. I fear that no possibility will be available with Kamailio / > > a standard SIP server. > > Maybe you can achieve the wanted behavior by modifying tm module to > CANCEL all branches if a single branch fail (similar to processing of > 6xx error response, which also cancels all branches). > > Depending on the exact needed behavior you might be able to do it with > Asterisk. > > regards > klaus > an alternative solution I think about (but have not yet tested) might be following: - SIP server on place A fork the call to SIP servers on place B and C (both with a fix usrloc contact => parallel forking to two fix destinations) - SIP server on place B fork the call to the gateways on place B serial - SIP server on place C fork the call to the gateways on place C serial The advantage of this solution might be that not one server is responsible for making the mixture of serial AND parallel forking. Each server is responsible for making EITHER parallel (= place A) OR serial (= places B and C) forking. Could this be a practicable alternative? regards Klaus F. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

14 years, 9 months

[Kamailio-Users] new feature: geoip location in cfg

by Daniel-Constantin Mierla

Hello, a new module was uploaded to master branch to lookup ip addresses against a geoip database. The module supports many lookups at the same time and returns the details in pseudo-variables. Therefore a new pv class: $gip(pvc=>key). pvc is the id of the container where to store the results of a geoip search, key is an id for the attribute you want to receive. See details on wiki: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#geoip_module_ps… Readme of the module: http://sip-router.org/docbook/sip-router/branch/master/modules/geoip/geoip.… Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 9 months

[Kamailio-Users] documentation team

by Daniel-Constantin Mierla

Hello, following some discussions on users mailing list, seems we may get a group of people willing to digest documentation and contribute to modules' readme or wiki pages. Hopefully Alex Balashov (who volunteered so far) would have some time to coordinate contributions to git docs, for wiki being easier, as anyone has access. I am willing to help as much I can, but time is always a constraint for a dev. I invite you to join IRC channel #sip-router hosted on freenode.net to plan an synchronize easier. Thanks, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 9 months

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error

by Daniel-Constantin Mierla

please cc the mailing list, otherwise your emails will be ignored. do you have the mysql client installed? Can you connect to the mysql server from terminal with 'mysql' command? Cheers, Daniel On 25.11.2009 19:42 Uhr, YÜKSEL wrote: > Dear Daniel, > > Thanks for your response : Actually I am getting an error below when > I try to create DB with `/usr/local/sbin/kamdbctl create` > > debian:/usr/local/src/kamailio-1.5.0/sip-server# > /usr/local/sbin/kamdbctl create > MySQL password for root: > INFO: test server charset > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 105: mysql: > command not found > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 106: mysql: > command not found > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary > operator expected > INFO: creating database openser ... > /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 71: mysql: command > not found > ERROR: Creating core database and grant privileges failed! > > I`ve applied the instructor one by one but I didn`t understand whay I > am getting this error. > > Regards, > > Yuksel > > > --- On *Wed, 11/25/09, Daniel-Constantin Mierla /<miconda(a)gmail.com>/* > wrote: > > > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > Subject: Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error > To: "lazturk" <lazturk(a)yahoo.com> > Cc: users(a)lists.kamailio.org > Date: Wednesday, November 25, 2009, 12:33 PM > > Hello, > > > On 25.11.2009 17:59 Uhr, lazturk wrote: > > Hello, > > > > How did you solve this problem bcz I am getting a similar error ; > > > > which one? the one related to no database engine specified or the > one related to mysql socket file? > > First: updated the kamctlrc file -- see the comments inside. > > Second: check if mysql server is running and if yes, check the > mysql config to see where the server is listening and where the > mysql client tries to connect to. They must be the same. > > Cheers, > Daniel > > > > > Thanks for your feedback. > > > > > > vivi-8 wrote: > > > >> Hi all > >> I have specify the wanted db type (DBENGINE=MYSQL) in the > >> /usr/local/etc/kamailio/kamctlrc > >> then I using "/usr/local/sbin/kamdbctl create" to create MySQL > database, > >> but I got this error: > >> > >> > >> > >> ERROR: database engine not specified, please setup one in the > config > >> script > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim > >> /usr/local/etc/kamailio/kamctlrc > >> > >> root@acer:/usr/local/src/kamailio-1.5.0/sip-server# > >> /usr/local/sbin/kamdbctl > >> create > >> > >> MySQL password for root: > >> > >> INFO: test server charset > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> Usage: grep [OPTION]... PATTERN [FILE]... > >> > >> Try `grep --help' for more information. > >> > >> /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: > unary > >> operator expected > >> > >> INFO: creating database openser ... > >> > >> ERROR 2002 (HY000): Can't connect to local MySQL server through > socket > >> '/var/run/mysqld/mysqld.sock' (2) > >> > >> ERROR: Creating core database and grant privileges failed! > >> > >> > >> > >> Cheers, > >> > >> vivi > >> > >> > >> _______________________________________________ > >> Kamailio (OpenSER) - Users mailing list > >> Users(a)lists.kamailio.org </mc/compose?to=Users(a)lists.kamailio.org> > >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > >> > >> > > > > > > -- Daniel-Constantin Mierla > * http://www.asipto.com/ > > -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 9 months

Request for a special parallel + serial forking scenario

by Klaus Feichtinger

Hi, I have a special question regarding a mixture of parallel and serial forking, operated by Kamailio-3.0.0. First of all I will give you a short background information, what the target will be: I have a SIP-server on place A, 3 gateways on place B and 3 gateways on place C). These gateways are registered on SIP server (A) with different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8, GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST be signalled on place B and C in parallel (forking) until the call is finally established over one of the two involved gateways on place B or C. When the prime gateway(s) (with the highest Q-value) fail (e.g. they do not send a provisional response within a timeout or send a negative response), the next gateway(s) should be addressed (with the next lower Q-value), a.s.o. The configuration works well in case that both gateways on place B and C fail at the same time (BOTH do not send a response or BOTH send a negative response or one does not send a response and the other one sends a negative response). However, in case that only ONE of the two (always in parallel) addressed gateways fails, it does not work as expected. It does nothing and/or waits for an eventually negative response or the call setup timeout. Configuration is done as described in the README of the TM module. It is a mixture of the main route and a failure_route in combination with the functions t_load_contacts() and t_next_contacts(). Does anybody have an idea how this problem could be solved or any alternative solution for this special requirement of parallel signalisation in any case? Thanks in advance! Regards, Klaus -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

14 years, 9 months

[Kamailio-Users] rtpproxy session is not automatically deleted if INVITE transaction fails?

by Iñaki Baz Castillo

Hi, I'm realizing that rtpproxy session is not automatically terminated when an outgoing INVITE transaction fails ([3456]XX response received from downstream), so the rtpproxy session dies after a while due to time expiration. So I've added the following code to my on_reply_route: ------------ onreply_route[X] { if is_method("INVITE") && status =~ "[3456][0-9][0-9]" unforce_rtp_proxy(); ------------ It seems to do the job. However I expected this to be done automatically by rtpproxy module when an INVITE transaction for which a rtpproxy session has been created fails. Do I miss something? or is it the expected behavior? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users January 2010