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@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