13 Apr
2009
13 Apr
'09
10:40 p.m.
Hi gentlemen,
I'm configuring some balance and failure routes with CarrierRoute module.
I have the following topology:
-----------> Carrier1
--------> GW1
-----------> Carrier2
Kamailio
-----------> Carrier1
--------> GW2
-----------> Carrier2
The idea will be to select a carrier using carrierroute going out through
GW1. If GW1 fails (timeout) i want the call to go to the same carrier
through the other GW. I assume the hash value calculated on cr_route will be
the same for the failure route, but I need to verify the fields used on the
DB to calculate a hash_index and the way that they are calculated so I can
assure the previous behavior.
Thanks in advance!
Uriel
14 Apr
14 Apr
4:11 p.m.
On Monday 13 April 2009, Uriel Rozenbaum wrote:
I'm configuring some balance and failure routes
with CarrierRoute module.
I have the following topology:
-----------> Carrier1
--------> GW1
-----------> Carrier2
Kamailio
-----------> Carrier1
--------> GW2
-----------> Carrier2
The idea will be to select a carrier using carrierroute going out through
GW1. If GW1 fails (timeout) i want the call to go to the same carrier
through the other GW.
Hi Uriel,
I assume the hash value calculated on cr_route will
be the same for the failure route, but I need to verify the fields used on
the DB to calculate a hash_index and the way that they are calculated so I
can assure the previous behavior.
The hash index is only configurable in the config file mode. This is for
example usable if you use it in front of a registrar cluster that access a
partioned database. I.e. the user location information for user that hash to
index 1 is stored in DB A, hash index 2 is stored in DB B and so on.. Then
you can ensure that all users that hash to 1 goes to the appropriate
registrar server.
But for your use case you probably don't need to configure this. If you want
to configure a failover logic like this then you only need to setup the
routing rules appropriate. Example for carrierroute:
- carrier1, prop 50%, domain0 -> GW1 (Carrier 1)
- carrier1, prop 50%, domain0 -> GW2 (Carrier 1)
- carrier2, prop 50%, domain0 -> GW1 (Carrier 2)
- carrier2, prop 50%, domain0 -> GW2 (Carrier 2)
- carrier1, prop 100%, domain1 -> GW2 (Carrier 1)
- carrier2, prop 100%, domain1 -> GW2 (Carrier 2)
- carrier1, prop 100%, domain2 -> GW1 (Carrier 1)
- carrier2, prop 100%, domain2 -> GW1 (Carrier 2)
carrier_failure_route:
- reply match 408, hostname GW1, carrier1 -> next_domain 1
- reply match 408, hostname GW1, carrier2 -> next_domain 1
- reply match 408, hostname GW2, carrier1 -> next_domain 2
- reply match 408, hostname GW2, carrier2 -> next_domain 2
Hope that helps.. If you don't like to specify the failover logic manually
like this, you could use the dispatcher module instead, which supports
detection of dead GWs and provides methods of trying the "next" GW in failure
route.
Cheers,
Henning
5:12 p.m.
Hi Henning,
I'm using something like you described. I'll rely on the probabilities to
make the trick and that's all.
Thanks for the quick reply!
Uriel
On Tue, Apr 14, 2009 at 8:11 AM, Henning Westerholt <
henning.westerholt(a)1und1.de> wrote:
On Monday 13 April 2009, Uriel Rozenbaum wrote:
I'm configuring some balance and failure
routes with CarrierRoute module.
I have the following topology:
-----------> Carrier1
--------> GW1
-----------> Carrier2
Kamailio
-----------> Carrier1
--------> GW2
-----------> Carrier2
The idea will be to select a carrier using carrierroute going out through
GW1. If GW1 fails (timeout) i want the call to go to the same carrier
through the other GW.
Hi Uriel,
I assume the hash value calculated on cr_route
will
be the same for the failure route, but I need to verify the fields used
on
the DB to calculate a hash_index and the way that
they are calculated so
I
can assure the previous behavior.
The hash index is only configurable in the config file mode. This is for
example usable if you use it in front of a registrar cluster that access a
partioned database. I.e. the user location information for user that hash
to
index 1 is stored in DB A, hash index 2 is stored in DB B and so on.. Then
you can ensure that all users that hash to 1 goes to the appropriate
registrar server.
But for your use case you probably don't need to configure this. If you
want
to configure a failover logic like this then you only need to setup the
routing rules appropriate. Example for carrierroute:
- carrier1, prop 50%, domain0 -> GW1 (Carrier 1)
- carrier1, prop 50%, domain0 -> GW2 (Carrier 1)
- carrier2, prop 50%, domain0 -> GW1 (Carrier 2)
- carrier2, prop 50%, domain0 -> GW2 (Carrier 2)
- carrier1, prop 100%, domain1 -> GW2 (Carrier 1)
- carrier2, prop 100%, domain1 -> GW2 (Carrier 2)
- carrier1, prop 100%, domain2 -> GW1 (Carrier 1)
- carrier2, prop 100%, domain2 -> GW1 (Carrier 2)
carrier_failure_route:
- reply match 408, hostname GW1, carrier1 -> next_domain 1
- reply match 408, hostname GW1, carrier2 -> next_domain 1
- reply match 408, hostname GW2, carrier1 -> next_domain 2
- reply match 408, hostname GW2, carrier2 -> next_domain 2
Hope that helps.. If you don't like to specify the failover logic manually
like this, you could use the dispatcher module instead, which supports
detection of dead GWs and provides methods of trying the "next" GW in
failure
route.
Cheers,
Henning
5510
days inactive
5511
days old
2 comments
2 participants
participants (2)
-
Henning Westerholt -
Uriel Rozenbaum