sr-users February 2010

sr-users@lists.kamailio.org

59 participants
109 discussions

[Kamailio-Users] preparing kamailio 1.5.4 and 1.4.5 releases
by Daniel-Constantin Mierla 02 Feb '10

02 Feb '10

Hello, soon I will start preparing the 1.5.4 and 1.4.5. The only issue reported and not clarified yet is the tcp failover that I tried to reproduce today without luck, might be dependent of (triggered faster on) particular architecture. It can be fixed once gathering more details or being able to reproduce. If you are aware of something else, please report to devel list. 1.4.5 will mark the official support for 1.4.x series, although some fixes may go back there from time to time, but I don't think will be another release of that branch. I recommend to update to newer version or stick to svn for updates. Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] PV bug in modules_k/acc/acc_extra.c in K 3.0.0
by Alex Balashov 02 Feb '10

02 Feb '10

I ran into a very interesting problem last night with 'acc' that took me a few hours to solve, so I am posting my workaround for collective benefit. It is probably not the cleanest and most appropriate solution because I am not extensively familiar with the 'acc' code; this is my first dive into it. Thus, I do not presume to submit an actual patch. The problem I had was that PVs read from the db_extra parameter that had an internal type of integer (TYPE_INT) because of their lexical scope were not being correctly evaluated, resulting in bizarre values being put in the database. I am using K 3.0.0 on 64-bit Xen guest running CentOS with db_postgres. I did not check to see if this problem occurs with db_mysql as I do not have MySQL anywhere nearby, but I don't believe it is happening at the database layer anyhow. I also know this problem was not present in 1.5.x, or several of my installations would be non-functional; this must have something to do with use of new 'srdb1' stuff in the database side of 'acc', I hypothesise. Anyway, the actual problem went like this. Let us say, for simplicity of example, that I am using 'acc' with Postgres backing and have something like this: modparam("acc", "db_extra", "account_id=$avp(s:account_id)") ... modparam("acc", "db_flag", 1) What was happening was that if I did this in a request route: $avp(s:account_id) = 42; ... setflag(1); if(!t_relay()) sl_reply_error(); exit; Very strange and occasionally bizarre values, mostly duplicates of other values I have in db_extra, would be written to acc.account_id (a column of type 'integer') - at any rate, certainly not 42. I enabled SQL statement logging on my PostgreSQL database to ensure that the data being inserted was literally not 42, rather than this being some sort of database-layer type conversion / representation problem. Sure enough, it was true, although I also did notice that 'acc' encloses all inserted values in single quotes to be treated as string literals. But this is immaterial, because RDBMs automatically cast such input: INSERT INTO acc (..., account_id) VALUES(..., '12'); Now, I could fix the problem by simply assigning the AVP a string literal instead: $avp(s:account_id) = '42'; Now the data was inserted normally. I also tested with user variables ($var(...)) and the same was true, so the problem is not AVP-specific. Also, all other evaluative contexts for PVs with these values work fine, such as printing them. The problem does not seem to be with 'db_postgres', neither with 'pv', nor with 'avpops' -- it is particular to 'acc'. After some hours of investigation I found that what was happening is that the type of the PV being referenced is not being correctly packed into the various arrays populated by extra2strar() in modules_k/acc/acc_extra.c, and thus was being misread when iterated in acc_db_request() in modules_k/acc/acc.c. Specifically, this check was inadequate: if (value.rs.s+value.rs.len==static_detector) { val_arr[n].s = int_buf + r*INT2STR_MAX_LEN; val_arr[n].len = value.rs.len; memcpy(val_arr[n].s, value.rs.s, value.rs.len); r++; LM_INFO("New int tenant: %s\n", val_arr[n].s); } else { val_arr[n] = value.rs; LM_INFO("New str tenant: %s\n", value.rs); } In my debugging, all PV values were showing up as "New str tenant" regardless of whether they were natively integers, and regardless of what the PV spec type was actually set to. The type was set correctly on the PV spec, so of course the integer value got stored correctly in int_var[] below: if (value.flags&PV_VAL_INT) { int_arr[n] = value.ri; type_arr[n] = TYPE_INT; } else { type_arr[n] = TYPE_STR; } ... but since 'acc' wants to treat all extra values as strings, this was not sufficient, because what was failing was this condition: if (value.rs.s+value.rs.len==static_detector) I guess value.rs.s in case of the PV value being PV_VAL_INT is not null terminated properly? This I truly do not know. In any event, I just added a check on the PV flags to see if it is an integer value and this fixed my problem: if (value.rs.s+value.rs.len==static_detector || value.flags & PV_VAL_INT) { ... however, I do not know that this was the most insightful solution. This is rather critical I think, because it means anyone trying to store PV values that are initialised with a natively numerical type in script (or extracted as a numerical value from a database, e.g. sql_query("SELECT account_id::integer FROM table ..."), I found this to be a problem as well) cannot store them in the database reliably using 'db_extra'. Thanks! -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/

2 3

[Kamailio-Users] isup in invite
by Eric Hiller 02 Feb '10

02 Feb '10

I have an issue where my sip endpoint is sending ISUP information in the invite. IE: sip:+1xxxxxxxxxx;npdi=yes;cic=+1-0110@xxxx:5060 and when I run the enum query I am getting: 0(24410) enum_query(): uri user is not an E164 number This is most likely due to the fact that $rU=+17794294010;npdi=yes;cic=+1-0110 Does openser not read the user properly? Is there a way to correct this? I am running openser 1.2.2 notls Thanks for any help! -Eric _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/196390709/direct/01/

6 24

[Kamailio-Users] append_rpid_hf add privacy?
by alex pappas 02 Feb '10

02 Feb '10

Dear friends, I'm trying to give to a user the option to have privacy in a call. I'm trying to do that by adding an extra header with: append_rpid_hf("sip", ";party=calling;id-type=subscriber;privacy=off;screen=no"); I'm using this header in the begining of the kamailio.cfg if(($rU=="99999") || ($rU=="77777")) { append_rpid_hf("sip", "$ru;party=calling;id-type=subscriber;privacy=off;screen=no"); xlog("alx ------- We have rU match --------"); } When I see the sip messages I don't see this extra header added into it. Does anyone had experience in this ? Thank you Alex

2 3

[Kamailio-Users] new feature: remote user registration
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, if you follow the sr-dev mailing list, you may have noticed some new features added in master branch (for the 3.1.0). I will send more details about each, now: remote user registration. The uac module can register in behalf of users to remote servers. The user details (credentials, local and remote username/domain) are loaded from database. The module sends registration at start-up and then refreshes just before expiration time. If the REGISTER is challenged for authentication, uac will re-send the REGISTER with proper credentials. A typical scenario is when users have accounts to many voip providers and they want to receive calls to those accounts via your sip server (inbound traffic). Of course, the user has to give details such as username/password to you. Other use case can be dynamic interconnection/peering. you can imagine a scalable solution where you have a traffic dispatcher and worker servers. When an worker becomes active, it registers to traffic dispatcher for receiving traffic... and examples can continue. Hope will help you in various cases! Readme at: http://sip-router.org/docbook/sip-router/branch/master/modules_k/uac/uac.ht… SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

4 4

[Kamailio-Users] new module: mtree
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, the master branch got a new module named mtree. It is able to load database records in the form of (key,value) and index them in shared memory trees based on key. One db table is loaded in one mtree, you can define as many trees as you need. The typical use case is to load arbitrary data related to DIDs or prefixes, offering very fast lookup even with large number of records. The value can be string or digested in a runtime structure, so far being able to digest dstid:weight values, useful for prefix matching on weight rather than longest match. The trees are read only, with option to reload via mi command (rpc to be added soon). Online readme at: http://sip-router.org/docbook/sip-router/branch/master/modules/mtree/mtree.… Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] kamailio 1.4 cpc
by Asim Riaz 01 Feb '10

01 Feb '10

Hi List, Is it possible to add diffrent CPC(calling party catagory) for diffrent type of the number in the INVITE before sending out to an upstream SIP server? INVITE ----> Kamailio(add CPC) -------> SIP_Proxy_2 Thanks, Asim

3 9

[Kamailio-Users] Fosdem 2010 - reminder
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, a reminder for those that already received (also sorry for cross-posting) and invitation for new ones, Fosdem 2010 happens this weekend in Brussels and we will have the traditional SIP routing dinner on Saturday Feb 6, trying to get all of us up-to-date regarding projects such as ser, kamailio (openser), sip-router, sems, asterisk, freeswitch, a.s.o. If you plan to attend, please confirm till Wednesday (send me an email), we need to have a fair estimation of attendees number to make the restaurant reservation. See more at: http://sip-router.org/2010/01/31/fosdem-2010-meeting-in-brussels/ See you at Fosdem, Daniel -- Daniel-Constantin Mierla eLearning Class for Kamailio 3.0.0 Starts Feb 8, 2010 * http://www.asipto.com/

1 0

[Kamailio-Users] project updates
by Daniel-Constantin Mierla 01 Feb '10

01 Feb '10

Hello, I do not know how many noticed so far, for several days the management web page was update to reflect an enlarged group of people that represent Kamailio project. Since the collaboration within SIP Router project proved fruitful, it is clear that the future development is related to that project, therefore devel decisions will happen there (join sr-dev(a)lists.sip-router.org to be in touch). The last year and half was filled with heavy integration work and testing, most of it not very challenging, but had to be done, so we wanted to acknowledge the help given by our most active community contributors. As a project policy, we maintain officially the latest two stable releases, now being 1.5.x and 3.0.x. The efforts of the group will be directed in advocating and promoting Kamailio and SIP Router projects world wide. Also some of them sponsor and take care of maintaining resources such as servers, dns and web pages. http://www.kamailio.org/mos/view/Management/ Given the big amount of work done for 3.0.0, the feedback so far is very good, in these tree weeks we discovered few issues, most relevant affecting sip_trace and uac modules, with a pretty active discussions pool about this version. 3.0.0 branches are run by some open voip providers for quite some time now (e.g., voipuser.org and iptel.org), servicing thousands of active users, ensuring that the core modules (e.g., acc, tm, auth, nat traversal, group, dialog, presence, dispatcher, pv, textops, ...) are working smooth. As a side note, I have it in other several production systems. While I encourage everyone to send feedback about 3.0.0, worth to mention that devel version (git master branch to become 3.1.0) has already quite a lot of new features, so if you are looking for adventures or need Lua API, geoip location, in memory tree indexed data, Python API, user registrations to remote SIP servers (for inbound calls), check-out git master and give it a try. Note that master is as stable as 3.0.0 branches so far regarding old code, new additions haven't touched other parts, being stand alone. Looking forward to 3.1.0 as introducing new features but also providing more tight integration with SIP Router, especially on some common used modules. Cheers, Daniel

1 0

2025

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 February 2010