Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Only in master I’m afraid due to a DB schema change. The relevant patches should work fine on 5.1 if you wanted to apply it locally: https://github.com/kamailio/kamailio/pull/1402 https://github.com/kamailio/kamailio/pull/1435 Cheers, Charles On Thu, 3 May 2018 at 12:40, Asgaroth

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Is that available in stable 5.0.x / 5.1.x or is it only available in master branch? On 03/05/18 12:28, Charles Chance wrote: Hi, On Thu, 3 May 2018 at 11:22, Asgaroth <00asgarot...@gmail.com > wrote: Hi Charles, With regards presence, are you using

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Hi, On Thu, 3 May 2018 at 11:22, Asgaroth <00asgarot...@gmail.com> wrote: > Hi Charles, > > With regards presence, are you using dmq module with dmq_t_replicate to > replicate publish messages? > No, recently added integration directly into the presence module:

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

We did that as well. On May 2, 2018 9:07:53 PM EDT, John Petrini wrote: >You can have both. What we did is create a designated writer. A >kamailio >instance that participates in DMQ but handles no SIP traffic and >periodically writes registrations from memory to a

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

You can have both. What we did is create a designated writer. A kamailio instance that participates in DMQ but handles no SIP traffic and periodically writes registrations from memory to a database. The other nodes work out of memory and load registrations from the writer node's db on restart.

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Henning, I would agree with that. All depends on your design priorities. -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Am Mittwoch, 2. Mai 2018, 19:36:11 CEST schrieb Alex Balashov: > By way of further answer: > > The use of a database as an interprocess communication mechanism is > considered an antipattern (the opposite of a "best practice"): > >https://en.wikipedia.org/wiki/Anti-pattern#Software_design >

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

By way of further answer: The use of a database as an interprocess communication mechanism is considered an antipattern (the opposite of a "best practice"): https://en.wikipedia.org/wiki/Anti-pattern#Software_design https://en.wikipedia.org/wiki/Database-as-IPC While relational databases

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

The DMQ advantage still holds due to flattening of the stack/seamlessness, and lack of mediation/marshaling through DB APIs or manual Redis interactions. On May 2, 2018 10:56:41 AM EDT, George Diamantopoulos wrote: >Hello all, > >Do you expect the DMQ vs database

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Hello all, Do you expect the DMQ vs database advantages to still hold true even when considering REDIS as a database (new backend in devel should make this possible)? Or are these points mainly relevant when it comes to traditional, persistent storage databases like mySQL? Thanks! BR, George On

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

On Mon, 30 Apr 2018 at 17:08, Alex Balashov wrote: > On Mon, Apr 30, 2018 at 11:13:13AM +0200, Aleksandar Sosic wrote: > > > We have a scalable dockerized environment and it's difficult to > > configure DMQ having dynamic IPs, instances booting up and scaling > > down

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

(You guys confirmed what I was thinking when I started the thread.. thank you all for your replies, they gave me a lot of confidence on DMQ and I'm already testing it out) On Mon, Apr 30, 2018 at 9:06 AM, Alex Balashov wrote: > On Mon, Apr 30, 2018 at 11:13:13AM

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

On Mon, Apr 30, 2018 at 11:13:13AM +0200, Aleksandar Sosic wrote: > We have a scalable dockerized environment and it's difficult to > configure DMQ having dynamic IPs, instances booting up and scaling > down on demand. A DNS alias that resolves to multiple entries is a great way to do that:

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

On Fri, Apr 27, 2018 at 8:23 PM, Charles Chance wrote: > [...] > In production we use DMQ for htable, usrloc, dialog and presence, where > previously we were using MySQL with Percona - now, performance is vastly > improved and the admin overhead is greatly reduced.

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

PS. In a NAT'd world, thousands of devices with low re-registration intervals are legion. Getting the database out of that business can literally be a tectonic game-changer in terms of the underlying economics in a service provider environment. It's incredibly wasteful and mostly pointless. On

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Another big advantage of DMQ is that it's transported over SIP using a custom request method (KDMQ). This sets up an opportunity to add additional infrastructure to deal with routing and managing those requests intermediately if needed in a large-scale environment. DMQ is a great thing, and we

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Hello Joel, +1 to everything Alex has said. Using DMQ simplifies/flattens the stack and allows for a truly decoupled cluster with fewer points of failure. In production we use DMQ for htable, usrloc, dialog and presence, where previously we were using MySQL with Percona - now, performance is

Re: [SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Hello Joel, Our experience with using DMQ for dialog and usrloc replication has been very positive, and we recommend it wholeheartedly over the crusty database sync-based methods. The primary appeal comes from the fact that the replication is done at a higher level, so there is no need to

[SR-Users] DMQ and/or Database for dialogs, registrations, etc..

Hi all, Just wanted to know what your opinions were on using DMQ modules over database for things like dialog replication, registrations, etc... Is DMQ the "new way to go"? I know that there lots of ways of doing things with each having pros/cons... But I was wondering... What does the