18 Oct
2010
18 Oct
'10
6:09 p.m.
Hello,
Marius Zbihlei has patched the userblacklist module, so that it can handle characters as
well (NOT in main release 3.1 yet). Thanks Marius.
Therefore it might now be possible to filter general SIP-URIs!??
My idea is simple and described here. Please give some Feedback!!!
As the "prefix"-functionality up to now was referring to SIP-URIs consisting of
digits (=real telephon numbers) like
004930123456(a)1and1.de
the general URI might be something like
user_123(a)server.domain.de
So far the "prefix"-functionality works because usernames that are real
telephone numbers, that always start with country-code, followed by town- or regional-code
and end with a unique number of the user (in this example 0049=Germany, (0)30=Berlin,
123456=user's unique number).
To use "prefix"-functionality with general (including non-digits) URIs it must
be evaluated reverse (from back to front) as the domain ends with the country- or
top-level-domain and becomes more detailed the reverse way.
So the IDEA is:
Insert the domain as prefix in userblacklist-table in reverse, to use the functionality.
I would use a perl-script to reverse the SIP-URI of the calling party in routing logic and
then check it against the already reverted domain in the userblacklist-table.
Do you think this is a good/well-working idea???
Any concerns or suggestions are appreciated...
Regards,
Nicolas
--
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
20 Oct
20 Oct
10:54 a.m.
On 10/18/2010 07:09 PM, "Nicolas Rüger" wrote:
Hello,
Marius Zbihlei has patched the userblacklist module, so that it can handle characters as
well (NOT in main release 3.1 yet). Thanks Marius.
Therefore it might now be possible to filter general SIP-URIs!??
My idea is simple and described here. Please give some Feedback!!!
As the "prefix"-functionality up to now was referring to SIP-URIs consisting of
digits (=real telephon numbers) like
004930123456(a)1and1.de
the general URI might be something like
user_123(a)server.domain.de
So far the "prefix"-functionality works because usernames that are real
telephone numbers, that always start with country-code, followed by town- or regional-code
and end with a unique number of the user (in this example 0049=Germany, (0)30=Berlin,
123456=user's unique number).
To use "prefix"-functionality with general (including non-digits) URIs it must
be evaluated reverse (from back to front) as the domain ends with the country- or
top-level-domain and becomes more detailed the reverse way.
Hello,
I understand your need, and it seems a fairly good feature request. I
have a few worries. I don't agree with evaluating everything in reverse.
I think usernames are to be evaluated in normal order, and only
domain(DNS part), if present should be evaluated in reverse. So when
trying to match user_123(a)server.domain.de (as prefix field) it should be
matched by either user_12 or .domain.de . Wouldn't this make more sense?
What do you think?
So the IDEA is:
Insert the domain as prefix in userblacklist-table in reverse, to use the functionality.
I would use a perl-script to reverse the SIP-URI of the calling party in routing logic
and then check it against the already reverted domain in the userblacklist-table.
Do you think this is a good/well-working idea???
This looks to me like a hack. I was thinking that the userblacklist
module should better provide this match instead of the script writer
hacking with some perl. I "direction" parameter might do the trick, but
this will require some big changes to this and dtrie. This also affects
every module that uses dtrie in its implementation like carrierroute and
so on(They all do prefix matching).
As Henning W. already said in the previous thread, until now there
wasn't much need for doing this, as interoperability with PSTN caused
using a user scheme resembling classic telephony.
Marius
Any concerns or suggestions are appreciated...
Regards,
Nicolas
21 Oct
21 Oct
6:36 p.m.
Hey Marius,
yes you're right! Thanks for the detailed feedback. The motivation was just to re-use
the functionality of the dtrie stuff.
But there's a even bigger problem, when just inserting the URIs in reverse.
For example the blacklisting of the URI
"r(a)domain.com"
would result in the implicit blacklisting of the URI
"peter(a)domain.com"
even if "(a)domain.com" would be explicitly whitelisted.
Therefore the idea of evaluating these URIs in reverse is not usable with the given
functionality of dtrie.
I guess I gonna try to solve that somehow else.
Thanks for your help!
Regards,
Nicolas
-------- Original-Nachricht --------
Datum: Wed, 20 Oct 2010 11:54:55 +0300
Von: marius zbihlei <marius.zbihlei(a)1and1.ro>
An: sr-users(a)lists.sip-router.org
Betreff: Re: [SR-Users] Reverse Filterlists idea
On 10/18/2010 07:09 PM, "Nicolas Rüger"
wrote:
Hello,
I understand your need, and it seems a fairly good feature request. I
have a few worries. I don't agree with evaluating everything in reverse.
I think usernames are to be evaluated in normal order, and only
domain(DNS part), if present should be evaluated in reverse. So when
trying to match user_123(a)server.domain.de (as prefix field) it should be
matched by either user_12 or .domain.de . Wouldn't this make more sense?
What do you think?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Hello,
Marius Zbihlei has patched the userblacklist module, so that it can
handle
characters as well (NOT in main release 3.1 yet). Thanks Marius.
Therefore it might now be possible to filter general SIP-URIs!??
My idea is simple and described here. Please give some Feedback!!!
As the "prefix"-functionality up to now was referring to SIP-URIs
consisting of digits (=real telephon numbers) like
004930123456(a)1and1.de
the general URI might be something like
user_123(a)server.domain.de
So far the "prefix"-functionality works because usernames that are real
telephone numbers, that always start with country-code, followed by town-
or regional-code and end with a unique number of the user (in this example
0049=Germany, (0)30=Berlin, 123456=user's unique number).
To use "prefix"-functionality with general (including non-digits) URIs
it must be evaluated reverse (from back to front) as the domain ends with
the country- or top-level-domain and becomes more detailed the reverse way.
So the IDEA is:
Insert the domain as prefix in userblacklist-table in reverse, to use
the
functionality.
I would use a perl-script to reverse the SIP-URI of the calling party in
routing
logic and then check it against the already reverted domain in the
userblacklist-table.
Do you think this is a good/well-working idea???
This looks to me like a hack. I was thinking that the userblacklist
module should better provide this match instead of the script writer
hacking with some perl. I "direction" parameter might do the trick, but
this will require some big changes to this and dtrie. This also affects
every module that uses dtrie in its implementation like carrierroute and
so on(They all do prefix matching).
As Henning W. already said in the previous thread, until now there
wasn't much need for doing this, as interoperability with PSTN caused
using a user scheme resembling classic telephony.
Marius
> Any concerns or suggestions are appreciated...
>
> Regards,
>
> Nicolas
22 Oct
22 Oct
4:30 p.m.
New subject: db connect needed by perl
Hello,
I have PERL script that's executed for every(!) initial INVITE message from the
routing logic.
The script needs to lookup a table in the database. Therefore I need to connect to the
database each time a initial INVITE is routed.
That might kill the performance (not tested yet, but pretty sure).
How can PERL get access to the database without establishing a _new_ connection each
time???
Regards,
Nicolas
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
6:05 p.m.
New subject: db connect needed by perl
On 10/22/2010 10:30 AM, "Nicolas Rüger" wrote:
Hello,
I have PERL script that's executed for every(!) initial INVITE message from the
routing logic.
The script needs to lookup a table in the database. Therefore I need to connect to the
database each time a initial INVITE is routed.
That might kill the performance (not tested yet, but pretty sure).
How can PERL get access to the database without establishing a _new_ connection each
time???
You can try pgpool or mysqlproxy for persistent connections.
Otherwise, Perl scripts don't persist that way in this module.
Can't you do what you need to do with 'sqlops'?
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:49 p.m.
New subject: db connect needed by perl
Hello Alex,
thank you for the tips.
I had a look at SQLOPS and it seems that it will open a new connection as well, every time
that "sql_query(connection, query, result)" is called.
so 2 questions...
1.) Is that true or am I wrong?
2.) Will using SQLOPS lead to a much better performance than querying the database from
perl scripst?
Thank you...
Regards,
Nicolas
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
The script
needs to lookup a table in the database. Therefore I need to
connect to the
database each time a initial INVITE is routed.
That might kill the performance (not tested yet, but pretty sure).
How can PERL get access to the database without establishing a _new_
connection
each time???
You can try pgpool or mysqlproxy for persistent connections.
Otherwise, Perl scripts don't persist that way in this module.
Can't you do what you need to do with 'sqlops'?
7:06 p.m.
New subject: db connect needed by perl
On Oct 22, 2010, at 12:49 PM, "Nicolas Rüger" <NicolasRueger(a)gmx.de>
wrote:
Hello Alex,
thank you for the tips.
I had a look at SQLOPS and it seems that it will open a new
connection as well, every time that "sql_query(connection, query,
result)" is called.
No, the connection handles are persistent. That is one of the
advantages.
so 2 questions...
1.) Is that true or am I wrong?
You are wrong. :-)
2.) Will using SQLOPS lead to a much better performance than
querying the database from perl scripst?
Yes, much less overhead; no external script invocation required, not
as much blocking, connection already open, etc. Unless you have a
specific need to run a Perl script because only Perl can do something
you especially need, definitely use sqlops for general DB operations.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
7:34 p.m.
New subject: db connect needed by perl
Hello Alex,
so I will. Thank you for the help.
I might still have to call PERL for some cases but I guess even then it's better to
use SQLOPS for the database part and send the result via parameter to the PERL script.
Regards,
Nicolas
Yes, much less overhead; no external script invocation
required, not
as much blocking, connection already open, etc. Unless you have a
specific need to run a Perl script because only Perl can do something
you especially need, definitely use sqlops for general DB operations.
--
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
23 Oct
23 Oct
3:03 p.m.
New subject: db connect needed by perl
2010/10/22 "Nicolas Rüger" <NicolasRueger(a)gmx.de>de>:
I had a look at SQLOPS and it seems that it will open
a new connection as well, every time that "sql_query(connection, query, result)"
is called.
*Every* Kamailio/SER module accessing to a database creates a
persistent connection for each running process when initializing the
modules.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4954
days inactive
4959
days old
8 comments
4 participants
participants (4)
-
"Nicolas Rüger" -
Alex Balashov -
Iñaki Baz Castillo -
marius zbihlei