Hello,
Based on our project policy to support officially the last two stable
branches, I was thinking of packaging kamailio 1.5.5 to mark its end.
New fixes will go to svn if it is the case, but no new release in 1.5.x
series will be done.
Also, since testing for 3.1.0 brought some fixes to 3.0.x, we should do
as well 3.0.4. My proposal is next week, Wednesday, Oct 20.
Don't forget to report issues you are aware for these two branches.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
this call caused sr from master branch to crash at startup:
t_set_fr("@cfg_get.local.invite_timeout", "@cfg_get.local.gw_timeout");
i had misspelled the name of the configuration variable when i set it at
the top of the script.
-- juha
Oct 19 18:16:37 squeeze /usr/sbin/trunk-proxy[1738]: ERROR: <core> [cfg/cfg_select.c:117]: ERROR: cfg_parse_selects(): unknown variable: local.gw_timeout
Oct 19 18:16:37 squeeze /usr/sbin/trunk-proxy[1738]: : <core> [main.c:1519]: could not …
[View More]initialize shared configuration
Oct 19 18:16:37 squeeze kernel: [ 338.729036] trunk-proxy[1738]: segfault at 10 ip 081638ad sp bf984d70 error 4 in trunk-proxy[8048000+184000]
[View Less]
On Monday 18 October 2010, Nicolas Rüger wrote:
> [..]
> I'd like to add some functionality to the userblacklist module and
> therefore I'd like to modify the function
>
> check_blacklist ([string table])
>
> because I need a check for the CALLER's URI _instead_ of the CALLEE's URI.
Hello Nicolas,
i understand. At the moment this function does not support parameters, but
patches are of course welcome. :-)
> I want to change that for me, as I do deal with SPIT-…
[View More]prevention and I need
> a global_list to be able to block or delay some caller's URIs globally and
> whitelist others (like hospitals and stuff) for incoming calls.
> [..]
> I had a look at "userblacklist.c" and I guess that's the one to patch. My
> idea is to implement the changes and name the method "check_blacklist1()".
>
> Here it seems the the URI that's checked is stored in "req_number".
>
> [...]
>
> if ((parse_sip_msg_uri(msg) < 0) || (!msg->parsed_uri.user.s) ||
> (msg->parsed_uri.user.len > MAXNUMBERLEN)) { LM_ERR("cannot parse msg
> URI\n");
> return -1;
> }
> strncpy(req_number, msg->parsed_uri.user.s, msg->parsed_uri.user.len);
>
> [...]
>
>
> I guess I have to change "msg->parsed_uri.user.s" to something that returns
> the CALLER instead of the CALLEE!?
You could indeed change the c-code like this.
> I had a look at the struct "sip_uri" (in msg_parser.h) because that's the
> type of variable "parsed_uri" and found the following...
> [..]
> So user is just a string (pointer to first char + length) and so it seems I
> have even to replace "parsed_uri" by something else.
>
> Then I had a look to struct "sip_msg" (in msg_parser.h) as it's the type of
> "msg" and next level of abstraction. There I found...
> [..]
> Another idea is to extend the parameter array of "check_blacklist()" so
> that one can pass the URI which has to be checked as an extra parameter.
>
> What do you think is the better way???
I'd think that adding functionality to parse arbitrary parameter is the better
and more flexible way instead of the req_number change you proposed above.
Take a look to the check_userblacklist functions to get some ideas for the
implementation.
> Furthermore I need a function that checks the global list for whitelisted
> entries.
>
> The flag "whitelist" is already present but there's no method to query it,
> as "check_blacklist()" returns true, when the prefix is whitelisted and
> the same when it's not on the list (so there's no way to distinguish
> between both possibilities yet)
Maybe you would like to add some functionality like the check_userwhitelist
functionality, for the check_blacklist function?
Regards,
Henning
[View Less]
Hi,
avpops module documentation still mentions onreply_avp_mode which is
obsolete now:
http://kamailio.org/docs/modules/3.1.x/modules/avpops.html
<<AVPs are persistent per SIP transaction, being available in "route",
"branch_route" and "failure_route". To make them available in
"onreply_route" armed via TM module, set "onreply_avp_mode" parameter of
TM module (note that in the default "onreply_route", the AVPs of the
transaction are not available).>>
Please remove the …
[View More]references. Thank you.
--
Sincerely,
Andrew Pogrebennyk
[View Less]