sr-dev December 2015

sr-dev@lists.kamailio.org

30 participants
230 discussions

[kamailio] Enable/disable persistence for uacreg (#369)

by Dan Christian Bogos

As discussed over mailing list, it will be useful to have enable/disable flags inside uacreg table. Ta, DanB --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/369

8 years, 3 months

[kamailio] modules/uac: Record-Route header parameter format for replace_uri (#455)

by Dmitri Savolainen

Module uac use some kind of Base64 for SipUri saving in Record-Route header parameter "rr_from_store_param" Base64 is case sensitive, but according to rfc3261: ``` When comparing header fields, field names are always case- insensitive Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive Tokens are always case-insensitive Unless specified otherwise, values expressed as quoted strings are case-sensitive For example, Contact: <sip:alice@atlantacom>;expires=3600 is equivalent to CONTACT: <sip:alice@atlantacom>;ExPiReS=3600 and Content-Disposition: session;handling=optional is equivalent to content-disposition: Session;HANDLING=OPTIONAL The following two header fields are not equivalent: Warning: 370 devnull "Choose a bigger pipe" Warning: 370 devnull "CHOOSE A BIGGER PIPE" ``` Ok " values expressed as quoted strings are case-sensitive", so I thought to make a quoted string like ``` Record-Route: <sip:xxxxxxxxxxxx:5071;lr;ftag=SDj3nsa01-78422015;vsf="baSE64strinG";nat=yes> ``` but according to rfc3261 DQUATE is not possible here: ``` other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" ``` Some devices in my network convert "rr_from_store_param" to lower-case letters, so there is trash in To/From headers after restore, It is not wise behaviour, but is rfc compliant So any idea for using Base32 instead of Base64? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/455

8 years, 3 months

Panning next major release - v4.4

by Daniel-Constantin Mierla

Hello, sketching the road to the next major release, so people can plan their goals for it and discuss, if needed, before the start of winter holidays: - development freezing by end of January 2016 - test for one to one and a half month - release in the first part of March 2016 If there are important topics to decide on, we can organize an IRC meeting sometime in January 2016. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu

8 years, 3 months

[kamailio] dmq_usrloc/usrloc core dumping (#440)

by 00Asgaroth00

I have 3 kamailio 434 registrars replicating between each other using dmq usrloc module I have recently noticed that all of the registrars crash at random intervals over the course of the day, they all dont crash at the same time, but randomly, independantly of each other I cannot see any unusual traffic arriving at the systems that may be a cause for the crash I'd appreciate assistance trying to get to the bottom of the issue Kamailio Version: ``` # /usr/sbin/kamailio -V version: kamailio 434 (x86_64/linux) 0ec860 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select id: 0ec860 compiled on 17:42:12 Nov 25 2015 with gcc 447 ``` Message in the log file when the kamailio application crashes: ``` Dec 14 01:46:54 /usr/sbin/kamailio[16205]: ALERT: <core> [mainc:728]: handle_sigs(): child process 16234 exited by a signal 11 Dec 14 01:46:54 /usr/sbin/kamailio[16205]: ALERT: <core> [mainc:731]: handle_sigs(): core was generated Dec 14 01:46:54 /usr/sbin/kamailio[16205]: INFO: <core> [mainc:743]: handle_sigs(): terminating due to SIGCHLD Dec 14 01:46:54 /usr/sbin/kamailio[16246]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16244]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16232]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16243]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16242]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16228]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16245]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16241]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16235]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16240]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16225]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16236]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16233]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16220]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16221]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16230]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16237]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16231]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16217]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16229]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16218]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16219]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16226]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16215]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16216]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16239]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16212]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16223]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16214]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16213]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16208]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16207]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16211]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16238]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16222]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16210]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16227]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16224]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16206]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16209]: INFO: <core> [mainc:798]: sig_usr(): signal 15 received Dec 14 01:46:54 /usr/sbin/kamailio[16205]: WARNING: tm [h_tablec:130]: free_cell_helper(): removed cell 0x7f5a40a084f8 is still linked in hash table (h_tablec:440) Dec 14 01:46:54 /usr/sbin/kamailio[16205]: WARNING: tm [h_tablec:130]: free_cell_helper(): removed cell 0x7f5a40a12390 is still linked in hash table (h_tablec:440) ``` Core file synopsis is: ``` Core was generated by `/usr/sbin/kamailio -P /var/run/kamailiopid -m 1024 -M 64 -u root -g root' Program terminated with signal 11, Segmentation fault #0 0x00007f5a82f68985 in mem_insert_ucontact (_r=0x7f5a409ec948, _c=0x7ffcc26f3140, _ci=0x7f5a81418500) at urecordc:152 152 if_update_stat( _r->slot, _r->slot->d->contacts, 1); ``` I still have the core file, however, it contains some sensitive info, so I can send backtraces directly to you if required Please let me know if you require any additional info Thanks --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/440

8 years, 3 months

[kamailio] tcpops: implement event_route for unexpectedly closed tcp connections (#454)

by Armen Babikyan

Comments are welcome You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/454 -- Commit Summary -- * tcpops: implement event_route for unexpectedly closed tcp connections -- File Changes -- M events.c (13) M events.h (2) M modules/tcpops/tcpops.c (44) M modules/tcpops/tcpops.h (2) M modules/tcpops/tcpops_mod.c (6) M tcp_read.c (24) -- Patch Links -- https://github.com/kamailio/kamailio/pull/454.patch https://github.com/kamailio/kamailio/pull/454.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/454

8 years, 3 months

[kamailio] core: rewrite add_interfaces() with getifaddrs() based implementation (#447)

by celan69

To make IPV6 work with Solaris, add_interfaces() had to be modified. I decided to reimplement it with a getifaddrs() based implementation, which is available from Solaris 11 upwards, and also on FreeBSD and Linux. By default, the latter continues to use the netlink based variant. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/447 -- Commit Summary -- * core: rewrite add_interfaces() with getifaddrs() based implementation -- File Changes -- M Makefile.defs (2) M socket_info.c (142) -- Patch Links -- https://github.com/kamailio/kamailio/pull/447.patch https://github.com/kamailio/kamailio/pull/447.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/447

8 years, 3 months

Happy New Year!

by Daniel-Constantin Mierla

The amazing 2015 for Kamailio is done! Thank you everyone for contributing to it! Now it is the time to get prepared to fill the 2016, with interesting discussions on our forums, solving new RTC challenges, adding features in Kamailio and welcoming new contributors! I wish a healthy and prosperous year to all Kamailio friends! I am looking forward to meeting many of you at Kamailio World Conference, where we are going to celebrate 15 years of development for Kamailio project, as well as at other events around the globe! Happy New Year! Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda http://www.kamailioworld.com

8 years, 3 months

git:master:c7e411ed: tm: reinit ref counter if attempting to free while still in wait timer

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: c7e411edb3c68260d43f86ee6977d468c074836b URL: https://github.com/kamailio/kamailio/commit/c7e411edb3c68260d43f86ee6977d46… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-12-30T21:18:23+01:00 tm: reinit ref counter if attempting to free while still in wait timer --- Modified: modules/tm/h_table.c --- Diff: https://github.com/kamailio/kamailio/commit/c7e411edb3c68260d43f86ee6977d46… Patch: https://github.com/kamailio/kamailio/commit/c7e411edb3c68260d43f86ee6977d46… --- diff --git a/modules/tm/h_table.c b/modules/tm/h_table.c index ea38de0..d492665 100644 --- a/modules/tm/h_table.c +++ b/modules/tm/h_table.c @@ -131,6 +131,7 @@ void free_cell_helper(tm_cell_t* dead_cell, int silent, const char *fname, unsig LM_WARN("removed cell %p is still linked in hash table (%s:%u)\n", dead_cell, fname, fline); if(t_on_wait(dead_cell)) { + INIT_REF(dead_cell, 1); LM_WARN("cell %p is still linked in wait timer (%s:%u)" " - skip freeing now\n", dead_cell, fname, fline); return;

8 years, 3 months

git:master:94da0d64: tsilo: check if tsilo hash table is still set when executing tm callback

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: 94da0d648805b958d266b789015f66cef8628ae4 URL: https://github.com/kamailio/kamailio/commit/94da0d648805b958d266b789015f66c… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-12-30T17:41:18+01:00 tsilo: check if tsilo hash table is still set when executing tm callback - freeing the transaction structure by tm at shutdown can execute this callback, resulting in core dump (at shutdonw) if tsilo destroyed its hash table already --- Modified: modules/tsilo/ts_handlers.c --- Diff: https://github.com/kamailio/kamailio/commit/94da0d648805b958d266b789015f66c… Patch: https://github.com/kamailio/kamailio/commit/94da0d648805b958d266b789015f66c… --- diff --git a/modules/tsilo/ts_handlers.c b/modules/tsilo/ts_handlers.c index c04ec36..392c71a 100644 --- a/modules/tsilo/ts_handlers.c +++ b/modules/tsilo/ts_handlers.c @@ -25,6 +25,7 @@ #include "ts_handlers.h" extern struct tm_binds _tmb; +extern struct ts_table *t_table; /*! * \brief add transaction structure to tm callbacks @@ -61,6 +62,8 @@ void ts_onreply(struct cell* t, int type, struct tmcb_params *param) ts_entry_t* _e; ts_transaction_t *cb_ptr, *ptr; + if(t_table==0) return; + cb_ptr = (ts_transaction_t*)(*param->param); if (cb_ptr == NULL) { LM_DBG("NULL param for type %d\n", type);

8 years, 3 months

git:master:ee7568cb: Merge pull request #457 from phil-lavin/feature-dont-append-realm-to-username-master

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: ee7568cb7da1be0c3c3d4ba2cd5bada4b4895bee URL: https://github.com/kamailio/kamailio/commit/ee7568cb7da1be0c3c3d4ba2cd5bada… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-12-30T10:43:26+01:00 Merge pull request #457 from phil-lavin/feature-dont-append-realm-to-username-master auth_radius: support for not appending realm to the username passed to RADIUS --- Modified: modules/auth_radius/authrad_mod.c Modified: modules/auth_radius/authrad_mod.h Modified: modules/auth_radius/doc/auth_radius.xml Modified: modules/auth_radius/doc/auth_radius_admin.xml Modified: modules/auth_radius/sterman.c --- Diff: https://github.com/kamailio/kamailio/commit/ee7568cb7da1be0c3c3d4ba2cd5bada… Patch: https://github.com/kamailio/kamailio/commit/ee7568cb7da1be0c3c3d4ba2cd5bada… --- diff --git a/modules/auth_radius/authrad_mod.c b/modules/auth_radius/authrad_mod.c index f4a9eac..94ca865 100644 --- a/modules/auth_radius/authrad_mod.c +++ b/modules/auth_radius/authrad_mod.c @@ -66,6 +66,7 @@ static int service_type = -1; int use_ruri_flag = -1; int ar_radius_avps_mode = 0; +int append_realm_to_username = 1; static char *auth_extra_str = 0; struct extra_attr *auth_extra = 0; @@ -95,6 +96,7 @@ static param_export_t params[] = { {"use_ruri_flag", INT_PARAM, &use_ruri_flag }, {"auth_extra", PARAM_STRING, &auth_extra_str }, {"radius_avps_mode", INT_PARAM, &ar_radius_avps_mode }, + {"append_realm_to_username", INT_PARAM, &append_realm_to_username }, {0, 0, 0} }; diff --git a/modules/auth_radius/authrad_mod.h b/modules/auth_radius/authrad_mod.h index c6561d3..ac8fe01 100644 --- a/modules/auth_radius/authrad_mod.h +++ b/modules/auth_radius/authrad_mod.h @@ -41,6 +41,7 @@ extern struct extra_attr *auth_extra; extern int use_ruri_flag; extern int ar_radius_avps_mode; +extern int append_realm_to_username; extern auth_api_s_t auth_api; diff --git a/modules/auth_radius/doc/auth_radius.xml b/modules/auth_radius/doc/auth_radius.xml index 5ae4e28..fd02edc 100644 --- a/modules/auth_radius/doc/auth_radius.xml +++ b/modules/auth_radius/doc/auth_radius.xml @@ -38,6 +38,11 @@ <surname>Janak</surname> <email>jan(a)iptel.org</email> </editor> + <editor> + <firstname>Phil</firstname> + <surname>Lavin</surname> + <email>phil.lavin(a)synety.com</email> + </editor> </authorgroup> <copyright> <year>2002</year> diff --git a/modules/auth_radius/doc/auth_radius_admin.xml b/modules/auth_radius/doc/auth_radius_admin.xml index 7977162..0475d57 100644 --- a/modules/auth_radius/doc/auth_radius_admin.xml +++ b/modules/auth_radius/doc/auth_radius_admin.xml @@ -206,6 +206,23 @@ modparam("auth_radius", "radius_avps_mode", 1) </programlisting> </example> </section> + <section id="auth_radius.p.append_realm_to_username"> + <title><varname>append_realm_to_username</varname> (integer)</title> + <para> + If set to 1, the username passed to the RADIUS server will have the + digest realm appended to it, if no domain is provided in the digest + username. + </para> + <para> + Default value is 1. + </para> + <example> + <title><varname>append_realm_to_username</varname> parameter usage</title> + <programlisting format="linespecific"> +modparam("auth_radius", "append_realm_to_username", 0) + </programlisting> + </example> + </section> </section> <section> diff --git a/modules/auth_radius/sterman.c b/modules/auth_radius/sterman.c index 88eef1d..f95fdbc 100644 --- a/modules/auth_radius/sterman.c +++ b/modules/auth_radius/sterman.c @@ -243,7 +243,7 @@ int radius_authorize_sterman(struct sip_msg* _msg, dig_cred_t* _cred, str* _meth * Add all the user digest parameters according to the qop defined. * Most devices tested only offer support for the simplest digest. */ - if (_cred->username.domain.len) { + if (_cred->username.domain.len || !append_realm_to_username) { if (!rc_avpair_add(rh, &send, attrs[A_USER_NAME].v, _cred->username.whole.s, _cred->username.whole.len, 0)) { LM_ERR("unable to add User-Name attribute\n"); goto err;

8 years, 3 months

← Newer
1
2
3
4
5
6
7
8
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2015