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
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher!