[OpenSIPS-Users] Dialog distribution

[Vlad Paiu]

Hello,

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.

[1] http://www.opensips.org/html/docs/modules/devel/dialog.html#id295597

Regards,

Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com


On 03/14/2012 03:51 PM, Mariana Arduini wrote:
> Hi Bogdan,
>
> 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.
>
> 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?
>
> Thanks again!
> Mariana.
>
>
>
> On Mon, Mar 12, 2012 at 3:21 PM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Mariana,
>
>     In your description, I identify 2 separate issues:
>
>     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.
>
>     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)
>
>     Regards,
>     Bogdan
>
>
>     On 03/12/2012 05:18 PM, Mariana Arduini wrote:
>>     Hi Bogdan,
>>
>>     Thank you for pointing the possible issues in our solution :)
>>
>>     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: http://s7.postimage.org/a5ex6dqgr/arch.jpg
>>
>>     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?
>>
>>     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?
>>
>>     Thanks a lot again!
>>     Mariana
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120314/a0f4d172/attachment.htm>