sr-dev March 2011

sr-dev@lists.kamailio.org

25 participants
194 discussions

git:master: modules_k/nathelper: add_contact_alias adds <> s around contact URI

by Juha Heinanen

Module: sip-router Branch: master Commit: 3ff9594a30eff2d18e6ea0595c5f82f878eaca1c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=3ff9594… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Fri Nov 26 10:37:30 2010 +0200 modules_k/nathelper: add_contact_alias adds <>s around contact URI Make sure that Contact URI is surrounded by <> when adding ;alias parameter. Otherwise, ;alias parameter may be interpreted as header parameter, because the syntax seems to be ambiguous. (cherry picked from commit f5ef15fee0c3bf09adf2506effa0895f72af9034) --- modules_k/nathelper/nathelper.c | 69 +++++++++++++++++++++++++++++++------- 1 files changed, 56 insertions(+), 13 deletions(-) diff --git a/modules_k/nathelper/nathelper.c b/modules_k/nathelper/nathelper.c index 51c1086..52c5e5f 100644 --- a/modules_k/nathelper/nathelper.c +++ b/modules_k/nathelper/nathelper.c @@ -786,7 +786,7 @@ add_contact_alias_f(struct sip_msg* msg, char* str1, char* str2) struct lump *anchor; struct sip_uri uri; struct ip_addr *ip; - char *param, *at, *port, *start; + char *lt, *gt, *param, *at, *port, *start; /* Do nothing if Contact header does not exist */ if (!msg->contact) { @@ -816,25 +816,63 @@ add_contact_alias_f(struct sip_msg* msg, char* str1, char* str2) return 2; } - /* Add alias param */ + /* Check if function has been called already */ if ((c->uri.s < msg->buf) || (c->uri.s > (msg->buf + msg->len))) { LM_ERR("you can't call alias_contact twice, check your config!\n"); return -1; } + + /* Check if Contact URI needs to be enclosed in <>s */ + lt = gt = param = NULL; + at = memchr(msg->contact->body.s, '<', msg->contact->body.len); + if (at == NULL) { + lt = (char*)pkg_malloc(1); + if (!lt) { + LM_ERR("no pkg memory left for lt sign\n"); + goto err; + } + *lt = '<'; + anchor = anchor_lump(msg, msg->contact->body.s - msg->buf, 0, 0); + if (anchor == NULL) { + LM_ERR("anchor_lump for beginning of contact body failed\n"); + goto err; + } + if (insert_new_lump_before(anchor, lt, 1, 0) == 0) { + LM_ERR("insert_new_lump_before for \"<\" failed\n"); + goto err; + } + gt = (char*)pkg_malloc(1); + if (!gt) { + LM_ERR("no pkg memory left for gt sign\n"); + goto err; + } + *gt = '>'; + anchor = anchor_lump(msg, msg->contact->body.s + + msg->contact->body.len - msg->buf, 0, 0); + if (anchor == NULL) { + LM_ERR("anchor_lump for end of contact body failed\n"); + goto err; + } + if (insert_new_lump_before(anchor, gt, 1, 0) == 0) { + LM_ERR("insert_new_lump_before for \">\" failed\n"); + goto err; + } + } + + /* Create ;alias param */ param_len = SALIAS_LEN + IP6_MAX_STR_SIZE + 1 /* ~ */ + 5 /* port */ + 1 /* ~ */ + 1 /* proto */; param = (char*)pkg_malloc(param_len); if (!param) { LM_ERR("no pkg memory left for alias param\n"); - return -1; + goto err; } at = param; append_str(at, SALIAS, SALIAS_LEN); ip_len = ip_addr2sbuf(&(msg->rcv.src_ip), at, param_len - SALIAS_LEN); if (ip_len <= 0) { - pkg_free(param); LM_ERR("failed to copy source ip\n"); - return -1; + goto err; } at = at + ip_len; append_chr(at, '~'); @@ -842,9 +880,8 @@ add_contact_alias_f(struct sip_msg* msg, char* str1, char* str2) append_str(at, port, len); append_chr(at, '~'); if ((msg->rcv.proto < PROTO_UDP) || (msg->rcv.proto > PROTO_SCTP)) { - pkg_free(param); LM_ERR("invalid transport protocol\n"); - return -1; + goto err; } append_chr(at, msg->rcv.proto + '0'); param_len = at - param; @@ -854,18 +891,24 @@ add_contact_alias_f(struct sip_msg* msg, char* str1, char* str2) } else { start = uri.host.s + uri.host.len; } + + /* Add ;alias param */ anchor = anchor_lump(msg, start - msg->buf, 0, 0); if (anchor == NULL) { - pkg_free(param); - LM_ERR("anchor_lump failed\n"); - return -1; + LM_ERR("anchor_lump for ;alias param failed\n"); + goto err; } if (insert_new_lump_after(anchor, param, param_len, 0) == 0) { - LM_ERR("insert_new_lump_after failed\n"); - pkg_free(param); - return -1; + LM_ERR("insert_new_lump_after for ;alias param failed\n"); + goto err; } return 1; + + err: + if (lt) pkg_free(lt); + if (gt) pkg_free(gt); + if (param) pkg_free(param); + return -1; }

12 years, 10 months

git:master: modules/tm: new implementation of load_contacts()/next_contacts ()

by Juha Heinanen

Module: sip-router Branch: master Commit: e973bbe5e7310861f77b17ce0afaf1cca35fe48a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e973bbe… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Fri May 28 15:38:41 2010 +0300 modules/tm: new implementation of load_contacts()/next_contacts() - Simpler implementation of load_contacts()/next_contacts() functions based on recent changes related to Request-URI handling. - Function next_contacts() does not anymore set any timers. Check contact_avp and call t_set_fr() before calling t_relay() instead. - Removed fr_timer_next module parameter, because it is not needed anymore. --- modules/tm/README | 255 ++++++++++++++------------------------ modules/tm/doc/functions.xml | 51 +++----- modules/tm/doc/params.xml | 73 ----------- modules/tm/doc/tm.xml | 15 +-- modules/tm/t_serial.c | 279 ++++++++++++------------------------------ modules/tm/tm.c | 1 - 6 files changed, 190 insertions(+), 484 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=e97…

12 years, 11 months

lockup("location") doesn't find a "sip" registration if RURI scheme is "sips"

by Iñaki Baz Castillo

Hi, "sip:alice@domain.org" is registered in Kamailio. If the proxy receives a request for "sips:alice@domain.org" and invokes "lookup(location)" the function doesn't retrieve the registration of alice. But it should: RFC 5630 section 3.3: When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address- of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. Note the last phrase: When used by the originator of a request (as would be the case if they employed a SIPS URI as the address- of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. This is, the entire path *until* the proxy responsible for the domain in the RURI must be secure (TLS) but it's not required (local policy) that the destination proxy dellivers the request to the destination user using TLS. So IMHO lockup(location) should not inspect the registration schema. Am I wrong? -- Iñaki Baz Castillo <ibc(a)aliax.net>

13 years, 1 month

question about module function arguments

by Juha Heinanen

i understood that module functions can now have an arbitrary number of string, int and pseudo var arguments, where string arguments can possibly also contain pseudo variables. some time ago i asked an example on how this is done, but didn't get any reply. so i'll try again. for example, allow_trusted function is now defined like this: {"allow_trusted", (cmd_function)allow_trusted_2, 2, fixup_pvar_pvar, fixup_free_pvar_pvar, REQUEST_ROUTE | FAILURE_ROUTE}, how can i add a third argument to the function without needing to define yet another fixup_pvar_pvar_something? -- juha

13 years, 2 months

Possible bug in RLS module

by Peter Dunkley

Hello, I think I may have found a bug in the RLS module. Take two subscribers (alice and bob) who have each other in their contact lists. Log them in (so REGISTER, SUBSCRIBE(presence.winfo), SUBSCRIBE(presence), PUBLISH, and so on). Log one (bob) out. bob's status remains online in alice's client. Restart alice's client (logging her out and in again). bob's status is still shown as online. Has anyone encountered this before? I think it might be related to some errors I am seeing. When my client unSUBSCRIBEs on sign-out I get the following errors (the line numbers may be slightly out from the base 3.1.2 version as I added some diagnostics to try and find the problem): Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls [notify.c:280]: updating in hash table Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls [notify.c:150]: in function agg_body_sendn_update Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls [subscribe.c:638]: failed sending full state notify Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls [subscribe.c:678]: occured in rls_handle_subscribe I believe this is happening because send_full_notify() is called after update_rlsubs() is called in rls_handle_subscribe(). update_rlsubs() will delete the entry from the hash table when "Expires: 0" is set - as is the case for an unSUBSCRIBE. Can anyone suggest what the correct behaviour should be? Thanks, Peter

13 years, 3 months

Kamailio at Google Summer of Code 2011

by Daniel-Constantin Mierla

Hello, for the second year, Kamailio is participating in GSoC program. For 2011, the proposal is to implement a signaling gateway between SIP and JINGLE to enable voice calls between the two networks: http://www.jitsi.org/index.php/GSOC2011/KamailioJingle If you are a student, or you know a student, interested in this project, just write me or to sr-dev(a)lists.sip-router.org. The application starts today and the deadline is April 8, therefore it is quite a short period, you will have to hurry. You can read more about the GSoC program and Kamailio at: http://www.kamailio.org/w/gsoc-2011/ http://www.jitsi.org/index.php/Development/Gsoc2011 Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

13 years, 3 months

preparing kamailio v3.1.3

by Daniel-Constantin Mierla

Hello, it is almost 2 months since we packaged 3.1.2, there are commits accumulated in branch 3.1, therefore I plan to package 3.1.3 Monday or Tuesday next week. If anyone has something to add in this regards, please reply. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

13 years, 3 months

library dir for x86_64 - lib or lib64

by Daniel-Constantin Mierla

Hello, iirc this was at some point discussed, however, I want to go through it again. Many x86_64 distros expect libraries to be placed under a lib64 directory. For example the RPM spec file language returns /usr/lib64 for %{_libdir} variable. In the master branch I committed a patch that does this detection. As I saw some people saying that 'lib' should be the default also for x86_64, my question is then what do you think we should use? Using 'lib' will definitely make building rpms fail unless we do a patch specific for these distros. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

13 years, 3 months

Re: [sr-dev] Fw: 32bit vs 64bit build problems

by Paul Pankhurst

Hi Daniel, Here is the svn diff output against the 3.1.2 version we had in our local svn repo for the clear_stats command. Note I added this as a new command rather than enhancement to the reset one to maintain backwards compatibility. This version outputs details of the values after resetting them, with the old values in brackets so that you can a) see if a variable was read only and thus not reset b) see the final counts at the point of resetting them all Also it makes a call to the bodge function get_stat_val_long in this code fragment. Regards Paul Index: core_stats.c =================================================================== --- core_stats.c (revision 8) +++ core_stats.c (working copy) @@ -95,10 +95,12 @@ static struct mi_root *mi_get_stats(struct mi_root *cmd, void *param); static struct mi_root *mi_reset_stats(struct mi_root *cmd, void *param); +static struct mi_root *mi_clear_stats(struct mi_root *cmd, void *param); static mi_export_t mi_stat_cmds[] = { { "get_statistics", mi_get_stats, 0 , 0, 0 }, { "reset_statistics", mi_reset_stats, 0 , 0, 0 }, + { "clear_statistics", mi_clear_stats, 0 , 0, 0 }, { 0, 0, 0, 0, 0} }; @@ -207,15 +209,44 @@ node = addf_mi_node_child(rpl, 0, 0, 0, "%s:%s = %lu", ZSW(get_stat_module(stat)), ZSW(get_stat_name(stat)), - get_stat_val(stat) ); + get_stat_val_long(stat) ); if (node==0) return -1; return 0; } +inline static int mi_reset_and_add_stat(struct mi_node *rpl, stat_var *stat) +{ + struct mi_node *node; + long old_val, new_val; + if (stats_support()==0) return -1; + old_val=get_stat_val_long(stat); + reset_stat(stat); + new_val=get_stat_val_long(stat); + + if (old_val==new_val) + { + node = addf_mi_node_child(rpl, 0, 0, 0, "%s:%s = %lu", + ZSW(get_stat_module(stat)), + ZSW(get_stat_name(stat)), + new_val); + } + else + { + node = addf_mi_node_child(rpl, 0, 0, 0, "%s:%s = %lu (%lu)", + ZSW(get_stat_module(stat)), + ZSW(get_stat_name(stat)), + new_val, old_val ); + } + + if (node==0) + return -1; + return 0; +} + /* callback for counter_iterate_grp_vars. */ static void mi_add_grp_vars_cbk(void* r, str* g, str* n, counter_handle_t h) { @@ -227,13 +258,43 @@ g->len, g->s, n->len, n->s, counter_get_val(h)); } +/* callback for counter_iterate_grp_vars to reset counters */ +static void mi_add_grp_vars_cbk2(void* r, str* g, str* n, counter_handle_t h) +{ + struct mi_node *rpl; + struct mi_node *node; + counter_val_t old_val, new_val; + + rpl = r; + old_val = counter_get_val(h); + counter_reset(h); + new_val = counter_get_val(h); + if (old_val==new_val) + { + node = addf_mi_node_child(rpl, 0, 0, 0, "%.*s:%.*s = %lu", + g->len, g->s, n->len, n->s, new_val); + } + else + { + node = addf_mi_node_child(rpl, 0, 0, 0, "%.*s:%.*s = %lu (%lu)", + g->len, g->s, n->len, n->s, new_val, old_val); + } +} + + /* callback for counter_iterate_grp_names */ static void mi_add_all_grps_cbk(void* p, str* g) { counter_iterate_grp_vars(g->s, mi_add_grp_vars_cbk, p); } +/* callback for counter_iterate_grp_names to reset counters */ +static void mi_add_all_grps_cbk2(void* p, str* g) +{ + counter_iterate_grp_vars(g->s, mi_add_grp_vars_cbk2, p); +} + static struct mi_root *mi_get_stats(struct mi_root *cmd, void *param) { struct mi_root *rpl_tree; @@ -293,7 +354,66 @@ } +static struct mi_root *mi_clear_stats(struct mi_root *cmd, void *param) +{ + struct mi_root *rpl_tree; + struct mi_node *rpl; + struct mi_node *arg; + stat_var *stat; + str val; + + if(stats_support()==0) + return init_mi_tree( 404, "Statistics Not Found", 20); + + if (cmd->node.kids==NULL) + return init_mi_tree( 400, MI_MISSING_PARM_S, MI_MISSING_PARM_LEN ); + + rpl_tree = init_mi_tree( 200, MI_OK_S, MI_OK_LEN); + if (rpl_tree==0) + return 0; + rpl = &rpl_tree->node; + + for( arg=cmd->node.kids ; arg ; arg=arg->next) { + if (arg->value.len==0) + continue; + + val = arg->value; + + if ( val.len==3 && memcmp(val.s,"all",3)==0) { + /* add all statistic variables */ + /* use direct counters access for that */ + counter_iterate_grp_names(mi_add_all_grps_cbk2, rpl); + } else if ( val.len>1 && val.s[val.len-1]==':') { + /* add module statistics */ + val.len--; + val.s[val.len]=0; /* zero term. */ + /* use direct counters access for that */ + counter_iterate_grp_vars(val.s, mi_add_grp_vars_cbk2, rpl); + val.s[val.len]=':' /* restore */; + } else { + /* reset & return only one statistic */ + stat = get_stat( &val ); + + if (stat==0) + continue; + if (mi_reset_and_add_stat(rpl,stat)!=0) + goto error; + } + } + + if (rpl->kids==0) { + free_mi_tree(rpl_tree); + return init_mi_tree( 404, "Statistics Not Found", 20); + } + + return rpl_tree; +error: + free_mi_tree(rpl_tree); + return 0; +} + + static struct mi_root *mi_reset_stats(struct mi_root *cmd, void *param) { struct mi_root *rpl_tree; From: Daniel-Constantin Mierla Sent: Tuesday, March 29, 2011 11:59 AM To: Paul Pankhurst Subject: Re: [sr-dev] Fw: 32bit vs 64bit build problems Hi Paul, the return of int instead of long is a bug and I will try to fix asap. The new command to reset statistics is an addition and we can add it whenever you want. You don't need to wait for Peter, you can send the patch to sr-dev and will be added into the master branch (devel version). Over the time, if you plan to contribute more code and come with new patches I can just grant you commit access to git, so you can commit directly there, either on master branch or your own one and then merge to master. Thanks, Daniel On 3/29/11 12:53 PM, Paul Pankhurst wrote: Hi Daniel, Anything that calls get_stat_val is potentially a problem – I did a ‘bodge’ fix by adding get_stat_val_long function and calling that from kex/core_stats.c instead of get_stat_val. I wasn’t sure if modifying get_stat_val was going to break something else that relied on the return NOT being a long from this function! Incidentally I have also extended core_stats.c by adding a clear_statistics mi command that takes the same params as get_statistics, thus allowing users to reset a group or all stats at the same time. My intention is to submit this back to the communits(possibly packaged with Peters presence changes unless you’d prefer them separate) Paul From: Daniel-Constantin Mierla Sent: Tuesday, March 29, 2011 11:36 AM To: Development mailing list of the sip-router project Cc: Paul Pankhurst Subject: Re: [sr-dev] Fw: 32bit vs 64bit build problems Hi Paul, indeed, some of these stats are not consistent. I will go through them. General idea is that the old stats framework will be replaced by a new one (present already in the code) that does not need any kind of locking when updating the counters, thus is faster. If you have specific examples of current stats that go nuts in 64b, please report them here so I will start with them then I will go through the rest of sources. Thanks, Daniel On 3/29/11 12:04 PM, Paul Pankhurst wrote: I have noticed that 'kamctl monitor' displays corrupt statistics when kamailio is built for a 64 bit platform. Further investigation has revealed that the reason is the underlying datatype is a long, whilst some of the wrapper functions (e.g. get_stat_val) return unsigned int. On a 32bit machine where a long and int are both the same size it is not a problem, but on a 64 bit machine they are different and hence the problem. Some code uses the wrapper function, other does not, in the case of mi_get_stats it uses both, so depending on paramaters passed to the MI fifo it may work or produce garbage results. Paul _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla http://www.asipto.com -- Daniel-Constantin Mierla http://www.asipto.com

13 years, 3 months

git:3.1: modules/lcr: improved documentation of defunct_gw() function.

by Juha Heinanen

Module: sip-router Branch: 3.1 Commit: a62ce2a6b8d90f7d45e62da92f665d4e1ea141b2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a62ce2a… Author: Juha Heinanen <jh(a)tutpro.com> Committer: Juha Heinanen <jh(a)tutpro.com> Date: Thu Mar 31 16:18:45 2011 +0300 modules/lcr: improved documentation of defunct_gw() function. (cherry picked from commit df7f3bc62783672eff39748450e8845187efb74a) --- modules/lcr/README | 9 +++++---- modules/lcr/doc/lcr_admin.xml | 1 + 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/modules/lcr/README b/modules/lcr/README index 617c0e0..0df413e 100644 --- a/modules/lcr/README +++ b/modules/lcr/README @@ -817,10 +817,11 @@ if (!next_gw()) { 4.3. defunct_gw(period) - Defuncts gateway denoted by lcr_id_avp and defunct_gw_avp for a period - of seconds given as argument. Argument must be a positive integer - constant or a pseudo variable with positive integer value. Value of - defunct column in database is not updated. + Defuncts gateway denoted by lcr_id_avp and defunct_gw_avp (which were + set by previuos next_gw() call) for a period of seconds given as + argument. Argument must be a positive integer constant or a pseudo + variable with positive integer value. Value of defunct column in + database is not updated. Returns 1 on success and -1 in case of error (see syslog). diff --git a/modules/lcr/doc/lcr_admin.xml b/modules/lcr/doc/lcr_admin.xml index 12f2d09..050871f 100644 --- a/modules/lcr/doc/lcr_admin.xml +++ b/modules/lcr/doc/lcr_admin.xml @@ -1049,6 +1049,7 @@ if (!next_gw()) { </title> <para> Defuncts gateway denoted by lcr_id_avp and defunct_gw_avp + (which were set by previuos next_gw() call) for a period of seconds given as argument. Argument must be a positive integer constant or a pseudo variable with positive integer value. Value of defunct column in

13 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2011