<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
&nbsp;<br>
<blockquote cite="mid:4B61C83D.3090508@pernau.at" type="cite">
  <blockquote type="cite">Hi,
    <br>
    <br>
I have a special question regarding a mixture of parallel and serial
    <br>
forking, operated by Kamailio-3.0.0.
    <br>
    <br>
First of all I will give you a short background information, what the
    <br>
target will be:
    <br>
    <br>
I have a SIP-server on place A, 3 gateways on place B and 3 gateways
    <br>
on place C). These gateways are registered on SIP server (A) with
    <br>
different Q-values (e.g. GW-B1=1.0, GW-C1=1.0, GW-B2=0.8, GW-C2=0.8,
    <br>
GW-B3=0.6, GW-C3=0.6). The target is, that a call for a gateway MUST
    <br>
be signalled on place B and C in parallel (forking) until the call is
    <br>
finally established over one of the two involved gateways on place B
    <br>
or C. When the prime gateway(s) (with the highest Q-value) fail (e.g.
    <br>
they do not send a provisional response within a timeout or send a
    <br>
negative response), the next gateway(s) should be addressed (with the
    <br>
next lower Q-value), a.s.o.
    <br>
    <br>
The configuration works well in case that both gateways on place B
    <br>
and C fail at the same time (BOTH do not send a response or BOTH send
    <br>
a negative response or one does not send a response and the other one
    <br>
sends a negative response). However, in case that only ONE of the two
    <br>
(always in parallel) addressed gateways fails, it does not work as
    <br>
expected.
    <br>
  </blockquote>
  <br>
What is expected?
  <br>
  <br>
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.
  <br>
  <br>
</blockquote>
The ideal behaviour would be following:<br>
&nbsp;- try reaching a gateway on place B and C until one gateway on every
place (B AND C) sends back a positive (provisional) response - e.g. 180
ringing, 183 session progress<br>
<br>
&nbsp;- in case that one of the two parallel addressed gateways is reachable
and sends back a provisional response (= "it is alive"), keep it<br>
<br>
&nbsp;- in case that the other one (of the two parallel addressed gateways)
has a problem (negative response 480 / 404 / 486 ...) or is unreachable
(= <code class="varname">fr_inv_timer_next</code> timeout), try the
next gateway on this specific place<br>
<br>
<blockquote cite="mid:4B61C83D.3090508@pernau.at" type="cite">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.
  <br>
  <br>
regards
  <br>
klaus
  <br>
</blockquote>
&nbsp;- the parallelism is necessary, because calls over these gateways
are addressed to a usergroup which is split to place B and C behind a
redundant "non-SIP" PBX system with two
active halfs); you can not suspect if a user on place B or a user on
place C
will take the call; therefore the call has to be sent to both places.<br>
&nbsp;<br>
However, the favored behaviour is not standard conform - I know. I
guess therefore I
would need a B2BUA, which is able to establish two independent
(serially forked) preliminary connections to gateways on place B and C
and interconnects the
successful call to the call originator. I fear that no possibility will
be available with Kamailio / a standard SIP server.<br>
<br>
The easiest way would be forking the incoming call to ALL available
gateways in parallel. Any gateway will accept the call. However, this
is not supported by the gateways and the system behind the gateways yet.<br>
<br>
Does anybody have an alternative idea to parallel forking, how this
"requirement" could be solved?<br>
<br>
regards, Klaus F.<br>
</body>
</html>