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