28 Jan
2010
28 Jan
'10
6:24 p.m.
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