22 Jan
2009
22 Jan
'09
12:32 p.m.
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