Klaus,
thank you very much for this suggestion! I will adapt it a little bit and run a second instance of SIP server on the same HW.
So the call will not be sent to the same server again, but to another instance. This will delimit the possibility for internal loops very much.
regards,
Klaus
Am 29.01.2010 10:37, schrieb Klaus Feichtinger:
Klaus Feichtinger schrieb:
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?
Indeed, that should work. You do not even need 3 servers. You can do it completely within one server, just spiraling the request, for example:
A calls sip:group01@domain
proxy at "domain" will fork the call to sip:group01B@domain and
sip:group01C@domain. Thus, the proxy will create 2 branches, sending both branches to itself again.
- proxy will receive the request for sip:group01B@domain and forwards
the request with serial forking, according the the q- values of the contacts registered for sip:group01B@domain.
- further, the proxy proxy will receive the request for
sip:group01C@domain and forwards the request with serial forking, according the the q- values of the contacts registered for sip:group01C@domain.
Every time the request is spiraled into the SIP proxy again, a new transcation is generated and you can define different failure route handling.
regards Klaus