25 Sep
2007
25 Sep
'07
7:49 p.m.
Hi everybody,
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?
2) Would the call, in this case, go to either gateway1_1 or gateway1_2, in case of failure
to gateway1_3?
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?)
4) Calls to other destinations as to destinations starting with "49" in the URI
would be rejected, right?
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?
Thank you in advance,
Carsten
26 Sep
26 Sep
2:40 p.m.
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
2:46 p.m.
On Wednesday 26 September 2007, Henning Westerholt wrote:
> I have a question regarding carrierroute: In
table "route_tree" i would
> have the following:
> +----+----------+
> | id | carrier |
> +----+----------+
> | 1 | carrier1 |
> | 2 | carrier2 |
> +----+----------+
> [..]
Hello Carsten,
i forget something.. :-)
You must add a default carrier to the carrier table with some hosts, to get
the setup mentioned in the previous e-mail working. As alternative you can
change the default_tree module parameter to "carrier1".
Cheers,
Henning
4:57 p.m.
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
5:15 p.m.
On Wednesday 26 September 2007, Carsten Bock wrote:
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?
Yes, carrier2 would be used in this case.
PVs are not implemented for tree_rewrite at the moment. We don't needed this,
as we're lookup the carrier from the database. You probably already noticed
the user_route_uri function that use AVPs, so should be not so hard to
implement. Patches are of course always welcome :-).
Cheers,
Henning
6273
days inactive
6274
days old
4 comments
2 participants
participants (2)
-
Carsten Bock -
Henning Westerholt