<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
You might want to check the dlg_db_sync MI command [1] which was
recently added to the dialog module. If the DB is shared between
your core instances, you could detect the failure in one of the
cores, and have your other cores refresh the Dialog internal memory
information from the DB, so they could also inherit the dialogs that
were ongoing on the failed core.<br>
<br>
[1] <a class="moz-txt-link-freetext"
href="http://www.opensips.org/html/docs/modules/devel/dialog.html#id295597">http://www.opensips.org/html/docs/modules/devel/dialog.html#id295597</a><br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a> </pre>
<br>
On 03/14/2012 03:51 PM, Mariana Arduini wrote:
<blockquote
cite="mid:CABHUZgDjB9wqK5N6r0CQ368po79nbZGhE+L7-X9kyA03mN58SQ@mail.gmail.com"
type="cite">Hi Bogdan,
<div><br>
</div>
<div>I got what you said about how the edge server should work, we
were thinking of something like that. Thanks a lot for pointing
important issues to be solved.</div>
<div><br>
</div>
<div>Back to the question on how to get an OpenSIPS instance to
"see" dialogs created by another OpenSIPS instance... what
direction would you suggest us to achieve this? Would it be
something like creating a new Dialog Module based on a
distributed key-value store using one of the cache_db modules?</div>
<div><br>
</div>
<div>Thanks again!</div>
<div>Mariana.</div>
<div><br>
</div>
<div><br>
<br>
<div class="gmail_quote">On Mon, Mar 12, 2012 at 3:21 PM,
Bogdan-Andrei Iancu <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> Hi Mariana,<br>
<br>
In your description, I identify 2 separate issues:<br>
<br>
1) preserving the ongoing call - when the edge server
learns that instance1 is down, it should take care of
re-routing the sequential requests through a different
core server ; as I guess you do RR on both edge and core,
I assume that sequential requests are Route driven; if so,
the edge, after doing loose_route() for a sequential
request, it should check if the newly set destination (by
loose_route) is still active or not (let's say there is an
extension of LB module to tell if a peer is up or down);
and if the destination pointed by Route hdr is down, the
edge to simply route the call to another core proxy - of
course this assumes that the core proxy should accept
sequential requests with Route IP of one of the other core
server (you need to alias the IPs of the other core
proxies) - at least this will make the core system to
receive, accept and route sequential requests for calls
established through other core servers.<br>
<br>
2) handling failure events for ongoing calls - by the SIP
nature, once the call is established, there is nothing
more going on at SIP level in order to "see" if the call
is still on or not. This is one issue that can be
addressed by in-dialog probing for example; or SST ; A
second issues is what to do - ok, you noticed that core
proxt 1 is down and you have 4 calls going through ?
Considering that the routing info is in the Route headers
(which are learned by end devices), there is not much you
can do to force the dialogs to go through a different
server, rather that what I said to 1)<br>
<br>
Regards,<br>
Bogdan
<div>
<div class="h5"><br>
<br>
On 03/12/2012 05:18 PM, Mariana Arduini wrote:
<blockquote type="cite"> Hi Bogdan,
<div><br>
</div>
<div>Thank you for pointing the possible issues in
our solution :)</div>
<div>
<div><br>
</div>
<div>The initial idea is to use load balancers
running on a HA set. Our OpenSIPS instances will
connect 2 network domains. We'll need a load
balancer in front of each one of the network
domains, as in this figure: <a
moz-do-not-send="true"
href="http://s7.postimage.org/a5ex6dqgr/arch.jpg"
target="_blank">http://s7.postimage.org/a5ex6dqgr/arch.jpg</a></div>
<div><br>
</div>
<div>Besides running the load_balance module, edge
servers would detect when instance 1 goes down
and "transfer" all dialogs to another instance.
I'm aware that this is not implemented in the
current OpenSIPS code, but keeping all the
established calls and being able to handle
sequential requests on them is a requirement in
our project and we'll have to find out how to do
this. First thoughts may include making some
changes on load_balance module, but so far we
don't have a defined strategy. By the way, would
you have any clue on this?<br>
</div>
<div><br>
</div>
<div>Considering everything I've read in this
users list and the way the load_balance module
works (i.e. it just relays all of the sequential
requests to the same server, whatever it is its
status), I feel the current OpenSIPS
implementation is not worried about loosing
established ongoing calls in case of one of the
instances fails, besides the usual lost of early
state calls. Is it a common solution in SIP
systems or is there any planning for improving
this in OpenSIPS on the next releases?</div>
<div><br>
</div>
<div>Thanks a lot again!</div>
<span><font color="#888888">
<div>Mariana</div>
</font></span></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
</blockquote>
</body>
</html>