<!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">
Hi Mariana,<br>
<br>
Well, having the dialog module sharing the dialog info between
multiple instances, it is on the roadmap for next releases.<br>
<br>
What you can play with for the moment is the new functionality Vlad
already mentioned.<br>
<br>
Regards,<br>
Bogdan<br>
<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>
<br>
<div class="gmail_quote">On Mon, Mar 12, 2012 at
12:14 PM, Mariana Arduini <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:marianarduini@gmail.com"
target="_blank">marianarduini@gmail.com</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;">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:</div>
<div><br>
</div>
<div><br>
</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?</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>
<div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Mon, Mar 12,
2012 at 9:08 AM, Bogdan-Andrei Iancu <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bogdan@opensips.org"
target="_blank">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>
Well, before considering how
opensips can "see" the dialogs
created by other opensips
instance, you should consider how
the sequential request will get to
the other instance.<br>
Let me explain:<br>
(1) dialog is created through
instance X with IP1, so call is
record routed with this IP1<br>
(2) instance X goes down, but
you have another instance Y up and
running with IP2<br>
(3) considering that
sequential requests tries to go to
IP1, how do you make them being
routed (Ip level) to IP2 where the
Y instance is running ?<br>
<br>
Regards,<br>
Bogdan
<div>
<div><br>
<br>
<br>
On 03/09/2012 09:18 PM,
Mariana Arduini wrote:
<blockquote type="cite">Hello
Bodgan,
<div><br>
</div>
<div>The problem is
sequential requests in
that dialog would not be
delivered to the end-user,
since the server would
have gone down. BYE and
re-INVITE messages
wouldn't be relayed,
affecting billing and
features like call hold
and call transfer. Also,
we wouldn't be able to
release media gateways
resources.
<div> <br>
</div>
<div>Despite all this, you
sound like this is not
an appropriate solution.
If so, what other
directions would you
suggest?</div>
<div><br>
</div>
<div>Thanks for your help!</div>
<div>Mariana.<br>
<br>
<div class="gmail_quote">
On Fri, Mar 9, 2012 at
2:12 PM, Bogdan-Andrei
Iancu <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:bogdan@opensips.org" target="_blank">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">
Hello Mariana,<br>
<br>
Currently there is
no way you can
share the dialog
state between 2
running instances
of opensips.
Probably this will
be available in
the next versions
(1.9 maybe ?).<br>
<br>
But my question is
how comes you have
such a scenario
that requests of
the same dialog
end up on
different servers
?? may you such
consider fixing
that part.<br>
<br>
Regards,<br>
Bogdan
<div>
<div><br>
<br>
On 03/09/2012
02:36 PM,
Mariana
Arduini wrote:
</div>
</div>
<blockquote
type="cite">
<div>
<div>Hello,
<div><br>
</div>
<div>I've been
searching a
lot on how to
have more than
one OpenSIPS
handling
messages from
the same
dialog (for
example, the
initial
request goes
to server #1
and the
sequential
requests go to
server #2, in
case server #1
goes down).
I've tried
pointing the
db_url to the
same database
on both
servers,
setting
db_mode
parameter to 1
(flush all
dialog data
into DB
immediately),
setting the
db_update_period
to a smaller
value than the
default but
didn't work,
except for
when we stop
server #1
smoothly. Even
so, some
header
translations
we should do
were not
performed.</div>
<div><br>
</div>
<div>I'm
supposed to
find out how a
distributed
key-value
store like
Redis can be
useful on
that. I've
seen the
example in the
Key-value
Interface
Tutorial but I
have no idea
on how to
transfer
dialog <span
style="font-family:
Helvetica,Arial;
font-size:
12px;">values,
flags </span><span
style="font-family:
Helvetica,Arial;
font-size:
12px;">along
with other
dialog state
information</span><span
style="font-family:
Helvetica,Arial;
font-size:
12px;"> from
the database
to a KVP
store. Would
it be
something like
having a whole
new dialog
module that
uses a
distributed
cache_db
instead?
Sounds hard to
accomplish...</span></div>
<div><span
style="font-family:
Helvetica,Arial;
font-size:
12px;"><br>
</span></div>
<div><span
style="font-family:
Helvetica,Arial;
font-size:
12px;">Is
this </span><a
moz-do-not-send="true"
href="http://lists.opensips.org/pipermail/users/2012-February/020657.html"
target="_blank">http://lists.opensips.org/pipermail/users/2012-February/020657.html</a> supposed
to do what I
need? Is there
any example of
use anywhere?
What I got
from it is
just profiling
distribution,
I don't get
how could this
allow all
dialog state
to be
shared...</div>
<div><br>
</div>
<div>Thanks a
lot for any
pointer or
help.</div>
<div>Mariana.<br>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div>
<div class="im">
<pre cols="72">--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a moz-do-not-send="true" href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
</body>
</html>