[OpenSIPS-Users] [NEW] Dynamic Routing enhancements
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Jan 21 13:31:40 CET 2009
Hi everybody,
I commited some new functionalities in the Dynamic Routing (Drouting) module:
1) attributes for the gateways
2) blacklists based on the GW IPs
3) lists of GWs
4) new function "goes_to_gw"
5) instant startup (no data loading delay)
1) attributes for the gateways
===============================
The definition of the GWs contain a attribute fields use to put custom attribute string. When the GW will be used, the attribute string is available in script.
The idea is to use this atrbute string for stroing GW specific info, like if supports SST, the SST value, vustom timeout to be used for the GW, etc.
See:
http://www.opensips.org/html/docs/modules/devel/drouting.html#id272129
Ex:
modparam("drouting", "ruri_avp", '$avp(s:dr_ruri)')
modparam("drouting", "attrs_avp", '$avp(dr_attrs)')
....
route[0]{
....
do_routing();
xlog("first attempt is %ru, attributes are $avp(dr_attrs)\n")
t_on_failure("1");
....
}
failure_route[1]{
....
if (use_next_gw()) {
xlog("next attempt is %ru, attributes are $avp(dr_attrs)\n")
t_on_failure("1");
}
....
}
2) blacklist based on the GW IPS
=================================
The module allows definition of various blacklists to include the IPs of some types of gateways. This blacklists are to be used to prevent malicious forwarding to GWs (based on DNS lookups) when the script logic does none-GW forwarding (like foreign domains).
The blacklists are automatically generated and update by the module, based on the GW defined via DB.
See:
http://www.opensips.org/html/docs/modules/devel/drouting.html#id272171
Ex:
modparam("drouting", "define_blacklist", 'dr_list= 3,2')
....
route{
.....
if($rU=~"PSTN_REGEXP") {
# call go to PSTN -> do drouting
do_routing();
} else {
# call does not go to PSTN, so protect the GWs with the blacklist
use_blacklist("dr_list");
}
....
}
3) lists of GWs
================
A new table "dr_gw_lists" allows definition of lists of gateways. This pre-defined list of gateways can be directly used from the rules definition and avoid keep listing the same set of gateways for multiple rules
This change is backward compatible and does not affect the behaviour of the module; it is just about how to define data to be used for routing.
Ex:
dr_gw_lists
+----+--------+-------------+
| id | gwlist | description |
+----+--------+-------------+
| 1 | 1,4,6 | |
| 2 | 2,3 | |
+----+--------+-------------+
dr_rules;
+--------+---------+--------+---------+----------+---------+--------+---------------+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist | description |
+--------+---------+--------+---------+----------+---------+--------+---------------+
| 472189 | 0 | 00441 | | 10 | 0 | #1 | use list here |
| 472189 | 0 | 00442 | | 10 | 0 | #1 | use list here |
| 472189 | 0 | 00443 | | 10 | 0 | #1 | use list here |
| 472190 | 0 | 004021 | | 20 | 0 | 2 | use GW 2 here |
+--------+---------+--------+---------+----------+---------+--------+---------------+
4) new function "goes_to_gw"
============================
This function returns true if the destination of the current request (destination URI or Request URI) points (as IP) to one of the gateways. There no DNS lookups done if the domain part of the URI is not an IP.
See:
http://www.opensips.org/html/docs/modules/devel/drouting.html#id272554
5) fast startup
================
The initial load of the routing data from DB is not done in init_module anymore (as it delays the overall starup of opensips). The load is done by the child rank 1.
Shortly, this means that whatever the size of the routing data, the module will instantly initialize and all allow opensips to start. The load is done in parallel, without delaying the statup process.
Regards,
Bogdan
More information about the Users
mailing list