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

[Alex Balashov]

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 Fri, Apr 27, 2018 at 02:38:37PM -0400, Alex Balashov wrote:

> 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 owe one to Charles & co.
> 
> On Fri, Apr 27, 2018 at 07:23:51PM +0100, Charles Chance wrote:
> 
> > 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 vastly
> > improved and the admin overhead is greatly reduced.
> > 
> > Disclaimer: I am possibly very slightly biased!
> > 
> > Cheers,
> > 
> > Charles
> > 
> > 
> > On Fri, 27 Apr 2018 at 16:45, Alex Balashov <abalashov at evaristesys.com>
> > wrote:
> > 
> > > 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 contend with issues surrounding the
> > > degree of two-way coupling that DB-backed modules have. For instance,
> > > the dialog module has both "runtime" and "persistent" components to its
> > > backing, so while the dialog module can store dialog info in a DB table,
> > > it can't store profile info. Replicating dialogs via DMQ allows one to
> > > share profile state.
> > >
> > > And in general, it's a lot more efficient. If you have 3 or 4
> > > registrars, you have a reasonable degree of persistence if you use in
> > > memory-only storage for usrloc with DMQ replication. That takes an
> > > enormous workload off the database.
> > >
> > > Databases are for storage; they aren't great for highly ephemeral,
> > > short-lived, real-time data, though they're often (mis)used for that
> > > purpose:
> > >
> > > https://en.wikipedia.org/wiki/Database-as-IPC
> > >
> > > DMQ solves a much-needed gap here in Kamailio, and I hope it is extended
> > > to provide transport for other components too.
> > >
> > > -- Alex
> > >
> > > On Fri, Apr 27, 2018 at 08:31:56AM -0700, Joel Serrano wrote:
> > >
> > > > 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 community think on this topic?
> > > >
> > > > Are you guys taking advantage of the DMQ modules or are you still relying
> > > > on database as much as possible? Maybe a combination of both?
> > > >
> > > > Cheers,
> > > > Joel.
> > >
> > > > _______________________________________________
> > > > Kamailio (SER) - Users Mailing List
> > > > sr-users at lists.kamailio.org
> > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > >
> > >
> > > --
> > > Alex Balashov | Principal | Evariste Systems LLC
> > >
> > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> > > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> > >
> > > _______________________________________________
> > > Kamailio (SER) - Users Mailing List
> > > sr-users at 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 at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/