Dialog/transaction replication across instances

[IvanRibakov]

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:

1. active calls are preserved
2. transactions that have not been completed may fail and will have to be retried.

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.

[emiago]

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.

[IvanRibakov]

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.

[emiago]

duplicate of #76

[emiago]

@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.

[emiago]

As for dialog replication, this is now refactored to level where now caller has full control over dialog and as stated in readme it should implement own caching. For even better dialog control, diago project was born, which allows even more better handling dialog, but it also includes media stack. For plain proxies diago may be overkill at the moment.

I am closing this, as some POCs are done to prove this is possible. SIP allows reestablishing dialog, but complexity is more in way data is cached and rebuilding invite request from headers. This will not be provided by library at the moment. As for note

• Dialog Invite Request/Response is exposed
• Dialog State can be monitored with hook or read at anytime