Hi, which would be the more ellegant way to allow users to call just a few destinations (based on prefix)?
Of course I could do it simply by creating a custom table: "allowed_destinations" with columns:
[int_prefix] [description] 34 Spain 44 England ...
and latter extract the international prefix from the E164 converted RURI and do a SQL query. But I'd like to avoid using avp_db_query() function.
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
What do you suggest? should I implement my custom method for this?
Thanks.
On Tuesday 19 February 2008, Iñaki Baz Castillo wrote:
Hi, which would be the more ellegant way to allow users to call just a few destinations (based on prefix)? [..]
and latter extract the international prefix from the E164 converted RURI and do a SQL query. But I'd like to avoid using avp_db_query() function.
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
What do you suggest? should I implement my custom method for this?
Hi Iñaki,
we've written a custom module for this to handle black (and white) lists on a global and per-user basis. I'm also interested if there are another means to achieve a functionality like this. If this is not possible, then perhaps i'll be able to contribute this module to 1.4.
But of course it would be better to use existing code to achieve this.
Cheers,
Henning
El Tuesday 19 February 2008 13:16:46 Iñaki Baz Castillo escribió:
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
It seems that PDT could be valid using: prefix2domain("2"); since "rewrite_mode = 2" means: "the user part of the URI is not changed"
And I've tested that this function returns -1 when the translation was NOT made, so the doc is wrong:
"Returns 1 when the translation was made or there was nothing to translate (user part of the URI is empty, it does not match the prefix parameter or there is no domain associated with a possible prefix from user part). Returns -1 in error cases."
El Tuesday 19 February 2008 13:34:17 Iñaki Baz Castillo escribió:
El Tuesday 19 February 2008 13:16:46 Iñaki Baz Castillo escribió:
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
It seems that PDT could be valid using: prefix2domain("2"); since "rewrite_mode = 2" means: "the user part of the URI is not changed"
And I've tested that this function returns -1 when the translation was NOT made, so the doc is wrong:
"Returns 1 when the translation was made or there was nothing to translate (user part of the URI is empty, it does not match the prefix parameter or there is no domain associated with a possible prefix from user part). Returns -1 in error cases."
Ops, after more testing this is not valid for me since it needs each field "domain" being different for the same "sdomain". So if for example I set two entries:
1) - sdomain: * - prefix: +34 - domain: gateway_IP
2) - sdomain: * - prefix: +44 - domain: gateway_IP
It will fail as "DUPLICATED" :(
Iñaki Baz Castillo wrote:
El Tuesday 19 February 2008 13:34:17 Iñaki Baz Castillo escribió:
El Tuesday 19 February 2008 13:16:46 Iñaki Baz Castillo escribió:
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
It seems that PDT could be valid using: prefix2domain("2"); since "rewrite_mode = 2" means: "the user part of the URI is not changed"
And I've tested that this function returns -1 when the translation was NOT made, so the doc is wrong:
"Returns 1 when the translation was made or there was nothing to translate (user part of the URI is empty, it does not match the prefix parameter or there is no domain associated with a possible prefix from user part). Returns -1 in error cases."
Ops, after more testing this is not valid for me since it needs each field "domain" being different for the same "sdomain". So if for example I set two entries:
- sdomain: *
- prefix: +34
- domain: gateway_IP
- sdomain: *
- prefix: +44
- domain: gateway_IP
It will fail as "DUPLICATED" :(
Hi,
are you using 1.3? On devel I introduced a new parameter (check_domain) that disables the checking of domain duplicity.
Regards, Ramona
El Tuesday 19 February 2008 15:04:34 Ramona Modroiu escribió:
Hi,
are you using 1.3? On devel I introduced a new parameter (check_domain) that disables the checking of domain duplicity.
Hi Ramona, it seems that the parameter "check_domain" exists for devel version but not for 1.3. It doesn't appear in the 1.3 code neither in the doc (but it appears in the devel version module doc):
http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.0/modules/pdt/pdt... http://www.openser.org/docs/modules/1.3.x/pdt.html
El Tuesday 19 February 2008 15:35:48 Iñaki Baz Castillo escribió:
El Tuesday 19 February 2008 15:04:34 Ramona Modroiu escribió:
Hi,
are you using 1.3? On devel I introduced a new parameter (check_domain) that disables the checking of domain duplicity.
Hi Ramona, it seems that the parameter "check_domain" exists for devel version but not for 1.3. It doesn't appear in the 1.3 code neither in the doc (but it appears in the devel version module doc):
http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.0/modules/pdt/pd t.c?revision=3367&view=markup http://www.openser.org/docs/modules/1.3.x/pdt.html
After reading again you comment I understand that this is exactly what you meant: "are you using 1.3? On devel I introduced a new parameter (check_domain)"
XD
So this function is not available in 1.3... :(
Iñaki Baz Castillo wrote:
El Tuesday 19 February 2008 15:35:48 Iñaki Baz Castillo escribió:
El Tuesday 19 February 2008 15:04:34 Ramona Modroiu escribió:
Hi,
are you using 1.3? On devel I introduced a new parameter (check_domain) that disables the checking of domain duplicity.
Hi Ramona, it seems that the parameter "check_domain" exists for devel version but not for 1.3. It doesn't appear in the 1.3 code neither in the doc (but it appears in the devel version module doc):
http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.0/modules/pdt/pd t.c?revision=3367&view=markup http://www.openser.org/docs/modules/1.3.x/pdt.html
After reading again you comment I understand that this is exactly what you meant: "are you using 1.3? On devel I introduced a new parameter (check_domain)"
XD
So this function is not available in 1.3... :(
yes, you have to backport the patch for yourself if you really need this feature. The patch is here http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/pdt/pdt.c?r1...
Regards, Ramona
El Tuesday 19 February 2008 16:12:13 Ramona Modroiu escribió:
So this function is not available in 1.3... :(
yes, you have to backport the patch for yourself if you really need this feature. The patch is here http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/pdt/pdt.c?r 1=3707&r2=3711&view=patch
Ok, I'll do it. Thanks.
Hi Iñaki,
It looks like you may have settled on a solution already but I'd like to add that carrierroute will do what you are looking for as well with a little work, as I do exactly this already. I have some customers that are only allowed to call certain prefixes (more specific than entire countries, but same principle).
What you do is create a route tree for every unique situation you have, and then add the allowed routes to each tree. For your example it would look something like this (requires openser 1.3):
route_tree table:
id carrier --- ---------- 1000 es-uk (This name could be anything, I just made it up to match your prefixes)
carrierroute table: id carrier scan_prefix domain prob strip rewrite_host rewrite_prefix rewrite_suffix comment -- ---------- ---------------- ---------- ------- ------ ----------------- ------------------- ------------------ -------------- 0 1000 34 primary 1.0 0 <pstn_gw_ip> Spain 1 1000 44 primary 1.0 0 <pstn_gw_ip> England
The domain is something arbitrary you make up. I use several domains for failover (primary, fail1, fail2, etc) because unlike lcr, carrierroute doesn't handle failover gracefully at this time, so I do it myself in the script.
In your script, you can select the route tree either by subscriber or some other criteria such as the source IP of the call. To use src ip for example you might do something like:
# Load AVPs for the client IP address avp_db_load("$si", "s/client_avps");
# This assumes the route tree name is indicated in $avp(s:route_tree) # The second arg matches the domain column in carrierroute. if(!cr_tree_rewrite_uri("$avp(s:route_tree)", "primary")) { # If the prefix is not 34 or 44, you will fall in here. Do something # about it like return SIP error, log to acc, etc. } ### # Assume you didn't get here unless there was a prefix match ### # HEre's a cheap way to do a blackhole route using this stuff. # You create a carrierroute entry and instead of a gateway host in the rewrite_host # column, just us ethe string "blackhole". Then you can do something like this: if($rd == "blackhole") { acc_db_request("403 Blackhole route", "acc"); sl_send_reply("403", "Forbidden"); }
If you are doing it based on the subscriber table, you would follow the docs in carrierroute module to extend your subscriber schema, and then use cr_user_rewrite_uri instead of cr_tree_rewrite_uri passing in the subscriber username and domain in SIP URI form, and not worry about loading an avp.
I use this as part of an overall PSTN routing solution that completely replaced lcr for me, so I'm mentioning it in case anyone else has a similar situation. In my case, I have a default route tree in addition to the restricted ones, that allows calls to anywhere. YMMV, because if you don't need all of carrierroute's power, you might get away with a simpler solution.
Good luck, Phil
On Feb 19, 2008 7:16 AM, Iñaki Baz Castillo ibc@in.ilimit.es wrote:
Hi, which would be the more ellegant way to allow users to call just a few destinations (based on prefix)?
Of course I could do it simply by creating a custom table: "allowed_destinations" with columns:
[int_prefix] [description] 34 Spain 44 England ...
and latter extract the international prefix from the E164 converted RURI and do a SQL query. But I'd like to avoid using avp_db_query() function.
I've reading about PDT, LCR and CarrierRoute modules but they seems to be supposed to other aims. The most similar could be PDT but it needs to strip my prefix XD
What do you suggest? should I implement my custom method for this?
Thanks.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Tuesday 19 February 2008 18:36:36 Phil D'Amore escribió:
Hi Iñaki,
It looks like you may have settled on a solution already but I'd like to add that carrierroute will do what you are looking for as well with a little work, as I do exactly this already. I have some customers that are only allowed to call certain prefixes (more specific than entire countries, but same principle).
What you do is create a route tree for every unique situation you have, and then add the allowed routes to each tree. For your example it would look something like this (requires openser 1.3):
route_tree table:
id carrier
1000 es-uk (This name could be anything, I just made it up to match your prefixes)
carrierroute table: id carrier scan_prefix domain prob strip rewrite_host rewrite_prefix rewrite_suffix comment
0 1000 34 primary 1.0 0 <pstn_gw_ip> Spain 1 1000 44 primary 1.0 0 <pstn_gw_ip> England
The domain is something arbitrary you make up. I use several domains for failover (primary, fail1, fail2, etc) because unlike lcr, carrierroute doesn't handle failover gracefully at this time, so I do it myself in the script.
In your script, you can select the route tree either by subscriber or some other criteria such as the source IP of the call. To use src ip for example you might do something like:
# Load AVPs for the client IP address avp_db_load("$si", "s/client_avps");
# This assumes the route tree name is indicated in $avp(s:route_tree) # The second arg matches the domain column in carrierroute. if(!cr_tree_rewrite_uri("$avp(s:route_tree)", "primary")) { # If the prefix is not 34 or 44, you will fall in here. Do something # about it like return SIP error, log to acc, etc. } ### # Assume you didn't get here unless there was a prefix match ### # HEre's a cheap way to do a blackhole route using this stuff. # You create a carrierroute entry and instead of a gateway host in the rewrite_host # column, just us ethe string "blackhole". Then you can do something like this: if($rd == "blackhole") { acc_db_request("403 Blackhole route", "acc"); sl_send_reply("403", "Forbidden"); }
If you are doing it based on the subscriber table, you would follow the docs in carrierroute module to extend your subscriber schema, and then use cr_user_rewrite_uri instead of cr_tree_rewrite_uri passing in the subscriber username and domain in SIP URI form, and not worry about loading an avp.
I use this as part of an overall PSTN routing solution that completely replaced lcr for me, so I'm mentioning it in case anyone else has a similar situation. In my case, I have a default route tree in addition to the restricted ones, that allows calls to anywhere. YMMV, because if you don't need all of carrierroute's power, you might get away with a simpler solution.
Thanks a lot for so good info. For now it's enough valid for me the PDT module but in a future I will need something as you propose.
Realy thanks a lot ;)
On Tuesday 19 February 2008, Phil D'Amore wrote:
It looks like you may have settled on a solution already but I'd like to add that carrierroute will do what you are looking for as well with a little work, as I do exactly this already. I have some customers that are only allowed to call certain prefixes (more specific than entire countries, but same principle).
What you do is create a route tree for every unique situation you have, and then add the allowed routes to each tree. For your example it would look something like this (requires openser 1.3):
route_tree table: [...] # HEre's a cheap way to do a blackhole route using this stuff. # You create a carrierroute entry and instead of a gateway host in the rewrite_host # column, just us ethe string "blackhole". Then you can do something like this: if($rd == "blackhole") { acc_db_request("403 Blackhole route", "acc"); sl_send_reply("403", "Forbidden"); }
Hi Phil,
just to give a little bit more informations, the solution you use if of course also valid.. If you want to blacklist some prefixes on a global level then you could also use something like this approaches:
1. - use a sufficient long strip value - add a prefix, e.g. "blacklist" - set rewrite_host to some asterisk box
This way the the resulting URI will transformed like this:
4912@proxy.domain -> blacklist@asterisk.domain
The call will be routed to a asterisk box, where you could play some user information matching to the prefix.
2. - use a empty rewrite_host string
This way the resulting URI will be invalid, and not routed.
Cheers,
Henning
Hi all,
I'm in the process of upgrading my openser to 1.3 from 1.1. I've updated my script, database, my sems server and configured my serweb to access the new database.
Because of new "id" parameter in pending & subscriber database, serweb is not able to "move" the information upon confirmation of the new account. Anyway, I've removed this confirmation process by directly adding the user account into the subscriber database.
My last issue is still about serweb:
start openser login as a user into serweb: all his fine access another page or reload the same a second time: no http answer...
If I restart openser, I can login again and the second time I access a serweb page, it locks again.
I think the problem might be in fifo? Any hints to help me to debug this issue? What additionnal info should I provide to get help?
I got no error message from openser and serweb.
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/
Iñaki Baz Castillo writes:
Hi, which would be the more ellegant way to allow users to call just a few destinations (based on prefix)?
if you use radius, you could return user's allowed prefixes as reply items when user is authenticated.
if the list is long, this is not very practical and you may need to implement a separate check for it. it is quite hard to avoid db query in that check especially if each domain/user may have its own list.
-- juha
El Martes, 19 de Febrero de 2008, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, which would be the more ellegant way to allow users to call just a few destinations (based on prefix)?
if you use radius, you could return user's allowed prefixes as reply items when user is authenticated.
if the list is long, this is not very practical and you may need to implement a separate check for it. it is quite hard to avoid db query in that check especially if each domain/user may have its own list.
Thanks. The fact is that I don't need per user allowed prefixed, just a dynamic list of them (so DB storage) and a way to reload it.
Using PDT module (in a not very common way) solves my problem since I use PDT table for storage and can reload with a FIFO command.
Regards.
-
Aymeric Moizard -
Henning Westerholt -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
Phil D'Amore -
Ramona Modroiu