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/
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/
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/
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
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/
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/
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
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/
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