[Kamailio-Users] carrierroute and scan_prefix value

[Henning Westerholt]

On Wednesday 21 January 2009, Juan Asencio wrote:
> Hi Henning and list, here is a description of the configuration that I’m
> 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 I’m
> 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