[OpenSIPS-Users] dialog: send BYE from another opensips instance

[Bogdan-Andrei Iancu]

yes, using that MI function make sense only if you have an already 
running server that needs to take over the calls (like an active-active 
setup or cluster setup).

Also be careful as moving the dialog from one server to another should 
be done with preserving the IP of the server, otherwise in-dialog 
routing will not work at all.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 01/09/2013 04:43 PM, Max Mühlbronner wrote:
> Hi,
>
>
> If the second server is started on-demand (e.g. keepalived) the 
> dialogs are loaded into memory from the DB (where the other opensips 
> stored the dialogs , by db_mode realtime..).
>
> So there would be no need to use dlg_db_sync in this simple failover 
> scenario, right?
>
>
> Best regards
>
> Max M.
>
> On 01/09/2013 02:30 PM, Bogdan-Andrei Iancu wrote:
>> See the MI command dlg_db_sync
>> http://www.opensips.org/html/docs/modules/1.8.x/dialog.html#id295605
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 01/09/2013 02:59 PM, samuel wrote:
>>>
>>> My point was exactly what you state in the last sentence about 
>>> failover scenario. Is there some way to use current dialog module to 
>>> handle these scenarios?
>>>
>>> Thanks a lot,
>>> Samuel
>>>
>>> El 09/01/2013 12:50, "Bogdan-Andrei Iancu" <bogdan at opensips.org 
>>> <mailto:bogdan at opensips.org>> va escriure:
>>>
>>>     Hi Samuel,
>>>
>>>     For dialog module, the primary storage (for dialog info) is all
>>>     the time the mem cache. DB is only a secondary storage and data
>>>     is flushed from mem to DB. At runtime, opensips never reads from
>>>     DB, but only from mem (the primary storage). (db mode REALTIME
>>>     means the DB storage is updated in realtime from mem cache)
>>>
>>>     So, you cannot have 2 opensips sharing dialog info via DB. Or
>>>     you want to implement a failover kind of scenario (like shifting
>>>     dialogs from one box to another) ?
>>>
>>>     Regards,
>>>
>>>     Bogdan-Andrei Iancu
>>>     OpenSIPS Founder and Developer
>>>     http://www.opensips-solutions.com
>>>
>>>
>>>     On 01/07/2013 07:59 PM, samuel wrote:
>>>>     Hi folks,
>>>>
>>>>     I'm started reading about dialog module and how to use it in a
>>>>     distributed environment. I've read about the 'B' flag and how
>>>>     it can be used to send BYEs to the end-points. My question is
>>>>     whether, using db_mode REALTIME, another instance of opensips
>>>>     can use the information stored in the database to send the BYE
>>>>     to a dialog created in another opensips instance.
>>>>
>>>>     The scenario is the next one:
>>>>     1.several opensips sharing the database and one of them
>>>>     receives an INVITE.
>>>>     2.It creates the dialog and sets the B flag. The parameter
>>>>     timeout is then set to the corresponding value.
>>>>     3.Another opensips uses the information from the dialog table
>>>>     to send the BYE either forced by an external t_dlg command or
>>>>     reading from the database (I guess the period can be controlled
>>>>     with the db_update_period parameter).
>>>>
>>>>     Is this possible with the current version?
>>>>
>>>>     Thank you very much in advance and congratulations,
>>>>     Samuel.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Users mailing list
>>>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130109/61e0255f/attachment-0001.htm>