Hi, I have used t_replicate a lot in the past, it is a great strait forward solution in general.

With DMQ_USERLOC, when you restart a node, it will retrieve all the contacts from the other nodes.

You could try to do that by using a USRLOC DB backend, but I believe you will may end up facing other limitations and introducing another SPOF.

I found that DMQ_USRLOC, is working great to ensure you quickly recover a clean state on every node.

Reusing the features provided by other modules seems like a great option to me because we are more users using the same code/logic in the end.

I even like modules that tare exposing small API to other modules, because they are more likely to be use by more users/devs.

I hope you will find the best solution for your needs

Regards

Julien

On Tue, Apr 23, 2019 at 10:24 AM Gholamreza Sabery <gr.sabery@gmail.com> wrote:

Dear Charles,

I think this module is a little bit misleading. At first, it seems, by using it, one can implement a multi-active Kamailio cluster, and the module will, by itself, handle Path-related operations. However, all it does is a simple replication that can be done using t_replicate, or dmq_t_replicate.

Regards

On Tue, Apr 23, 2019 at 4:17 PM Charles Chance <charles.chance@sipcentric.com> wrote:
Hello,

The lookup() function acts in exactly the same way as it would usually. The purpose of dmq_usrloc is to replicate contacts between all nodes - encapsulating them inside the KDMQ messages you see being exchanged. Therefore, if a contact registers to node A and you perform a lookup on node B, the result of the lookup will be essentially the same as if it were performed on node A.

Of course, if your clients are behind NAT, then you'll probably need any outgoing messages to be routed via the node on which the client is registered. Utilising the Path-related parameters of the registrar module can help here.

The db_mode makes no difference either - dmq_usrloc interacts with the usrloc module completely independently of the storage method used. I would, however, argue that the main point of dmq_usrloc is to provide completely in-memory storage and replication, improving performance and removing the additional layer of storage/replication, so using db_mode 3 seems somewhat counterproductive.

Cheers,

Charles

On Mon, 22 Apr 2019 at 14:12, Gholamreza Sabery <gr.sabery@gmail.com> wrote:
Hi,

Recently, I started to use dmq_usrloc module. I successfully set it up. Unfortunately, the documentation does not specify the behavior of dmq_usrloc module with other Kamailio modules. For example, I see a bunch of KDMQ messages are exchanged between nodes, but how the lookup() function behaves with dmq_usrloc, or what is it's effect on a db_mode of 3!

Regards
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users