Hi Henning,

Now everything seems to become clear about the usage of the carrierroute module. Now i seem to understand, how the carrier-route module should work.

You wrote: For "if(!cr_rewrite_uri("0", "call_id")){" the default-tree would be used (e.g. carrier1). If i change this to "if(!cr_tree_rewrite_uri("carrier2", "0")){" would the tree of "carrier2" be used? I assume (when looking at the source), i cannot use pseudo-variables here..., right?

Thanks in advance,

Carsten

Am Mittwoch, den 26.09.2007, 13:40 +0200 schrieb Henning Westerholt:

On Tuesday 25 September 2007, Carsten Bock wrote:

...

I have a question regarding carrierroute: In table "route_tree" i would have the following: +----+----------+ | id | carrier | +----+----------+ | 1 | carrier1 | | 2 | carrier2 | +----+----------+

In the table "carrierroute" i have the following: +----+---------+-------------+-------+------+-------+---------------+ | id | carrier | scan_prefix | level | prob | strip | rewrite_host | +----+---------+-------------+-------+------+-------+---------------+ | 1 | 1 | 49 | 0 | 0.5 | 0 | gateway1_1 | | 2 | 1 | 49 | 0 | 0.5 | 0 | gateway1_2 | | 3 | 1 | 49 | 1 | 1 | 0 | gateway1_3 | | 4 | 1 | 49 | 2 | 1 | 0 | gateway1_4 | | 5 | 2 | 49 | 0 | 1 | 0 | gateway2_1 | | 6 | 2 | 49 | 1 | 1 | 0 | gateway2_2 | +----+---------+-------------+-------+------+-------+---------------+

in the routing logic i would do the following:

route { # Calls to PSTN based on RURI if(!cr_rewrite_uri("carrier1", "call_id")){ sl_send_reply("403", "Not allowed"); } else { # In case of failure, re-route the request t_on_failure("1"); # Relay the request to the gateway t_relay(); } }

failure_route(1) { # In case of failure, send it to an alternative route: if (t_check_status("408|5[0-9][0-9]")) { if(!cr_rewrite_uri("carrier1", "call_id")){ t_reply("403", "Not allowed"); } else { t_on_failure("1"); t_relay(); } } }

Questions:

1. Is this configuration right?

Hell Carsten,

well, you should specify the level in cr_rewrite_uri, not the carrier. The mapping of users to a certain carrier is specified in the cr_prefered_carrier column, e.g. in subscriber. But for cr_rewrite_uri only the default carrier is used.

This column is not yet created by the database scripts. Perhaps it makes sense to extend this table, if the extra modules are installed like the SERWEB case.

So for example you could do this:

route { # route calls based on hash over callid # choose route level 0 of the default carrier if(!cr_rewrite_uri("0", "call_id")){ sl_send_reply("403", "Not allowed"); } else { # In case of failure, re-route the request t_on_failure("1"); # Relay the request to the gateway t_relay(); } }

failure_route(1) { # In case of failure, send it to an alternative route: if (t_check_status("408|5[0-9][0-9]")) { #choose route level 1 of the default carrier if(!cr_rewrite_uri("1", "call_id")){ t_reply("403", "Not allowed"); } else { t_on_failure("2"); t_relay(); } } }

failure_route(2) { # further processing }

...

2. Would the call, in this case, go to either gateway1_1 or gateway1_2, in

case of failure to gateway1_3?

The calls (with the config snippet above) would be in the routed to gateway1_1 or gateway1_2, depending of the hash of the callid. If you get an failure, the next (in this case) level of the routing tree is choosen, e.g. gateway1_3 or gateway1_4.

...

3. In case all three fail, it would go to

gateway1_4? (original route would be level 1, 1st failure-route would be level 2, 2nd failure-route would be level 3 and so on?)

You must manually choose another level. You can choose the levels as you like, or choose another carrier with the rewrite_tree function.

...

4. Calls to other

destinations as to destinations starting with "49" in the URI would be rejected, right?

Yes, if you don't have a route with an empty prefix in this tree. You could also block certain prefixes if you specify an empty rewrite.

...

5. Does it cause problems, when "prob" does not result in

1? E.g. does a prob of 1 and 1 result into the same as 0.5 and 0.5?

Yes, this is the same. The actual prob values are "fixed", as you could see in the cr_dump_routes output.

I've extended the carrierroute documentation somewhat with the points you mentioned, i hope that its now more clear.

Cheers,

Henning