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

[Klaus Feichtinger]

> 
> 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.
> >>
> > The ideal behaviour would be following:
> >  - 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
> > 
> >  - in case that one of the two parallel addressed gateways is reachable 
> > and sends back a provisional response (= "it is alive"), keep it
> > 
> >  - in case that the other one (of the two parallel addressed gateways) 
> > has a problem (negative response 480 / 404 / 486 ...) or is unreachable 
> > (= |fr_inv_timer_next| timeout), try the next gateway on this specific
> place
> 
> 
> I'm still not sure if I understand it correct. May examples help:
> 
> the call is forwarded to B1 and C1. B1 does not send back anything, C1 
> sends back 100 trying. What is the expected behavior?
> - CANCEL C1 and send the call to B2 and C2?
> - keep C1 and send another call to B2?
> - stay with B1 unreachable and possible C1 answering the call?
> 

The second variant with "keep C1 and send another call to B2" is the expected behaviour.

> >  - 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.
> 
> Ok.
> 
> > 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.
> 
> Maybe you can achieve the wanted behavior by modifying tm module to 
> CANCEL all branches if a single branch fail (similar to processing of 
> 6xx error response, which also cancels all branches).
> 
> Depending on the exact needed behavior you might be able to do it with 
> Asterisk.
> 
> regards
> klaus
> 

an alternative solution I think about (but have not yet tested) might be following:
 - SIP server on place A fork the call to SIP servers on place B and C (both with a fix usrloc contact => parallel forking to two fix destinations)
 - SIP server on place B fork the call to the gateways on place B serial
 - SIP server on place C fork the call to the gateways on place C serial

The advantage of this solution might be that not one server is responsible for making the mixture of serial AND parallel forking. Each server is responsible for making EITHER parallel (= place A) OR serial (= places B and C) forking.

Could this be a practicable alternative?

regards
Klaus F.

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01