Open IvanRibakov opened 2 months ago
There is already working solution, but as builtin logic it will be more as part of other project I was mentioning to you. Now different architect could apply yes.
There is already working solution
Are you able to share any details? Is it open source?
part of other project I was mentioning to you
You mean diago
project, right? Is there anything already in place there that I could look at? I'm not necessarily looking for a final working solution, I'm just interested in understanding better the direction that sipgo
/diago
take for tackling the HA problem.
duplicate of #76
@IvanRibakov when you are in control of dialog, and you are dealing this on library level you have all you need. This is what you will basically have with those libraries. I think you just need to imagine that library will not be that closed, and even sipgo, if you look closely is not hiding too much. Of course library will not provide you out of box solution, but I am making sure lately that you can access all data you need. I would try to send you some examples, just give me some time.
What I'm trying to achieve:
I'm working on a highly-available SIP service. The goal is to have 2 instances of a service running simultaneously: one in "active" mode and another in a "hot standby" mode. Should the active instance become unresponsive, the routing will be switched to the backup instance.
The QoS expectations in case of a fail-over are the following:
What I am NOT asking
I do not expect sipgo to support HA/fail-over natively as that is a fairly high-level piece of logic that can take many shapes and forms.
What I am asking
How well are sipgo's Dialog and Transaction types prepared for a use-case where inputs are not coming from the wire (I guess in sipgo's design that would be a Connection?) but are supplied externally? For example, I'm fairly certain that we would need to sync dialogs and dialog states across instances. I'm not 100% sure if we would need to replicate transactions as well.