On Wednesday 21 January 2009, Juan Asencio wrote:
Hi Henning and list, here is a description of the configuration that Im trying to test with carrierroute:
I have 4 groups of customers calling to 6 different destinations. Each customerGroup has specific rules about the destinations that are allowed to call. For ex. CustomerGroup 1 can call to S-fix, S-mob, N-fix and DK-fix, but not to N-mob or DK-mob CustomerGroup 2 can call to N-fix, N-mob, S-fix and DK-fix, but not to S-mob or DK-mob CustomerGroup 3 can call to DK-fix, DK-mob, S-fix and N-fix, but not to S-mob or N-mob CustomerGroup 4 can call to all destinations.
Hi Juan,
ok, understand. Additional to least cost routing you use cr to blacklist certain destinations depending on the user group.
So, in order to apply the different rules to each customerGroup, I could assign to each customerGroup a Carrier on the subscriber table, and each carrier would have its rules about where is allowed to call using scan_prefix on the carrierroute table.
But then I will need to have almost the same host information for every carrier, but with the exceptions mentioned above. My point is that it would be a lot of information that is repeated, is this really necessary?
Duplicating this routing rules would be the easiest solution. But you could probably implement something like this with the flags/ mask functionality, present in cr from 1.4.x. It can match routing rules against message flags you set in the script.
It is anyway to avoid repeating all this rewrite_host and scan_prefix information? Because in this example is just 6 rewrite_hosts that Im calling again and again on the different carriers, but in my implementation it would be a lot more of Interconnect companies that I need to add. Also, the same scan_prefix, would be called again for each carrier.
In the upcoming 1.5.0 release we removed some of the duplication, additional to the carriers also the domain names are now read from seperate tables on startup. We thought also a few times about moving the rewrite_host to a seperate table, but came not to a final conclusion about this if it makes really sense. After all, memory and disk storage are way more cheaper then developer brains. ;-) And so far even with larger installation (several 100k routes) this was not an issue.
Additional, if you enter individual numbers as scan_prefix (e.g. fraud, QS issues with certain GWs..), you're matching table would be get quite large.
As well, I see that I could put all hosts under 1 domain, but then what it is the point of having different domains?
You can use it for failure routing, for example. Lets say, domain 1 is your first try, use the cheapest route. It fails, you go to domain 2, which is more expensive. If it fails again, you try again the first route, or a third one. Or you've a certain domain that diverts the call to a announcement box, for certain response classes..
Am I trying to do with carrierroute something that the module was not build for?
No, it was created for something like this.
+----+---------+--------+-------------+-------+------+---------------+ | id | carrier | domain | scan_prefix | flags | prob | rewrite_host | +----+---------+--------+-------------+-------+------+---------------+ | 1 | 1 | 1 | 462 | 0 | 1 | host1.s-fix | | 2 | 1 | 1 | 465 | 0 | 1 | host2.s-mob | | 3 | 1 | 2 | 472 | 0 | 1 | host3.n-fix | | 4 | 1 | 2 | 473 | 0 | 1 | host3.n-fix | | 5 | 1 | 2 | 474 | 0 | 1 | host3.n-fix | | 6 | 1 | 3 | 452 | 0 | 1 | host5.dk-fix | | 7 | 1 | 3 | 453 | 0 | 1 | host5.dk-fix | | 8 | 1 | 3 | 454 | 0 | 1 | host5.dk-fix | | 9 | 2 | 1 | 462 | 0 | 1 | host1.s-fix | | 10 | 2 | 2 | 472 | 0 | 1 | host3.n-fix | | 11 | 2 | 2 | 475 | 0 | 1 | host4.n-mob | | 12 | 2 | 3 | 452 | 0 | 1 | host5.dk-fix | | 13 | 3 | 1 | 462 | 0 | 1 | host1.s-fix | +----+---------+--------+-------------+-------+------+---------------+
If you just want to blacklist certain destinations you can also do it another way:
+----+---------+--------+-------------+-------+------+---------------+ | id | carrier | domain | scan_prefix | flags | prob | rewrite_host | +----+---------+--------+-------------+-------+------+---------------+ | 1 | 1 | 1 | 47 | 0 | 1 | host3.n-fix | | 2 | 1 | 1 | 475 | 0 | 1 | | +----+---------+--------+-------------+-------+------+---------------+
Just combine the rules to host3.n (prefix 472, 473, 474), and explicitly blacklist the mobile you don't want for this users. Normally there a quite a lot of optimization possibilities like this, you could use some custom scripts to generate and optimize the routing rules.
Cheers,
Henning