I guess, we could simply use tcp with t_relay using only one process in the module.
On Thu, May 9, 2019, 04:52 Julien Chavanton <[email protected]> wrote: > > Yesterday at Kamailio World there was an interesting question, raising a > concern about replication of user location and DMQ in general, we should > track it in the mailing list and use it as a feature request and I can > share my initial thoughts on the topic. > > The concern was about DMQ reordering transactions. > > With SIP registration this seems like a minor concern, high responsiveness > at the cost of potential small inconsistency seems like a good option. > Considering that, the state will automatically correct itself and that > this can be controlled using the expiration timer. This will become even > more insignificant when the replicas can only be used as primary server > failover. (it becomes a very small concern only when the primary server > fails) > > With other type of data re-ordering may result in more problematic use > cases. > My impression is that DMQ should try to be good only with volatile data, > data that will expire anyway, like caching with expiration, registration, > Dialogs, etc. > > I think it may be worth looking at adding support for ordering/queuing in > DMQ. > > Performance and simplicity could be maintained by doing mainly > transactions in parallel with a configurable re-ordering best effort to > minimize the impact of the problem. > > For example : > 1- trying to re-order for a configurable amount of time. (32 seconds to > match the RFC for SIP re-transmissions) > 2- adding tractability for failed transactions. > 3- the possibility to trigger a re-sync. > > Another option is to look at preserving strict ordering but I can imagine > this could add more problems in some cases ... > > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
