[SR-Users] Request for a special parallel + serial forking scenario

[Klaus Darilion]

Klaus Feichtinger schrieb:
> Hi,
> 
> I have a special question regarding a mixture of parallel and serial
> forking, operated by Kamailio-3.0.0.
> 
> First of all I will give you a short background information, what the
> target will be:
> 
> I have a SIP-server on place A, 3 gateways on place B and 3 gateways
> on place C). These gateways are registered on SIP server (A) with
> different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8,
> GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST
> be signalled on place B and C in parallel (forking) until the call is
> finally established over one of the two involved gateways on place B
> or C. When the prime gateway(s) (with the highest Q-value) fail (e.g.
> they do not send a provisional response within a timeout or send a
> negative response), the next gateway(s) should be addressed (with the
> next lower Q-value), a.s.o.
> 
> The configuration works well in case that both gateways on place B
> and C fail at the same time (BOTH do not send a response or BOTH send
> a negative response or one does not send a response and the other one
> sends a negative response). However, in case that only ONE of the two
> (always in parallel) addressed gateways fails, it does not work as
> expected.

What is expected?

Do you want to trigger failover to lower priority even if one the 
gateways is still working fine? You can not do that with sip-router. sr 
implements parallel forking according to RFC3261, this means it will not 
generate a failure response as long as one of the branches is still 
active, maybe sending 200 ok.

> It does nothing and/or waits for an eventually negative
> response or the call setup timeout.

Finally, a call can only be established via one gateway, so either the 
GW at B or C sends the 200 OK. If you always trigger failover to lower 
priority gateways if one of the gateways failed, there is no benefit of 
doing parallel forking at all - at least I do not see a benefit of 
having redundant gateways.

regards
klaus

> 
> Configuration is done as described in the README of the TM module. It
> is a mixture of the main route and a failure_route in combination
> with the functions t_load_contacts() and t_next_contacts().
> 
> Does anybody have an idea how this problem could be solved or any
> alternative solution for this special requirement of parallel
> signalisation in any case?
> 
> Thanks in advance!
> 
> Regards, Klaus
>