Hi Mariana,
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.
Let me explain:
(1) dialog is created through instance X with IP1, so call is
record routed with this IP1
(2) instance X goes down, but you have another instance Y up and
running with IP2
(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 ?
Regards,
Bogdan
On 03/09/2012 09:18 PM, Mariana Arduini wrote:
Hello Bodgan,
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.
Despite all this, you sound like this is not an appropriate solution.
If so, what other directions would you suggest?
Thanks for your help!
Mariana.
On Fri, Mar 9, 2012 at 2:12 PM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hello Mariana,
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 ?).
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.
Regards,
Bogdan
On 03/09/2012 02:36 PM, Mariana Arduini wrote:
Hello,
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.
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 values, flags along with other dialog state
information 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...
Is this
http://lists.opensips.org/pipermail/users/2012-February/020657.html 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...
Thanks a lot for any pointer or help.
Mariana.
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
