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

[Charles Chance]

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 <00asgarot...@gmail.com> wrote:

> 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 dmq module with dmq_t_replicate to
>> replicate publish messages?
>>
>
> No, recently added integration directly into the presence module:
>
> https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.p.enable_dmq
>
>
>>
>>
>> On 27/04/18 19:23, 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
>> >
>> >
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> *Charles Chance*
> Managing Director
>
> t. 0330 120 1200m. 07932 063 891
>
> 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 
> Listsr-users@lists.kamailio.orghttps://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
>
-- 
*Charles Chance*
Managing Director

t. 0330 120 1200m. 07932 063 891

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

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

[Asgaroth]

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 dmq module with
dmq_t_replicate to
replicate publish messages?


No, recently added integration directly into the presence module:
https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.p.enable_dmq




On 27/04/18 19:23, 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
>
>


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

--
*Charles Chance*
Managing Director

t. 0330 120 1200    m. 07932 063 891

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

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

[Charles Chance]

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:
https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.p.enable_dmq


>
>
> On 27/04/18 19:23, 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
> >
> >
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
*Charles Chance*
Managing Director

t. 0330 120 1200m. 07932 063 891

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

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

[Alex Balashov]

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 database.
>
>The other nodes work out of memory and load registrations from the
>writer
>node's db on restart.
>
>On Wed, May 2, 2018, 15:14 Alex Balashov 
>wrote:
>
>> 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
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity. 

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

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

[John Petrini]

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.

On Wed, May 2, 2018, 15:14 Alex Balashov  wrote:

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

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

[Alex Balashov]

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
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Henning Westerholt]

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
>https://en.wikipedia.org/wiki/Database-as-IPC
> 
> While relational databases perform the worst at this, the fundamental
> problem is using the database as a work queue for ephemeral/real-time
> data. Simply using a faster, and/or nonrelational database, doesn't
> remove the problem, it just makes the setup perform better. It's a
> difference of degree, not kind.
> 
> Ultimately, databases — including in-memory key-value stores — are for
> storage, not for IPC. This doesn't stop them being routinely used as
> such by people who do not know how to write IPC mechanisms and
> middleware of their own. That's less excusable in an era with lots of
> prefabricated options, whether message queues (e.g. AMQP) or distributed
> systems closer to the application level (like DMQ).

Hello Alex,

you are right of course regarding the comments about the anti-pattern using 
databases as 
IPC.

But IMHO there are valid use cases for storing a registration in a database, 
like access for 
third party applications. E.g. you have a front end that shows  customer care 
if a user is 
registered or not, and you don't want that this PHP GUI access directly your 
Kamailio 
servers. Or you need to access the registration data in a big java enterprise 
middle-ware 
for user contract status.

But in a smaller or more homogeneous environment its of course easier to 
synchronize the 
registration state with DMQ.

Best regards,

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

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

[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
   https://en.wikipedia.org/wiki/Database-as-IPC

While relational databases perform the worst at this, the fundamental
problem is using the database as a work queue for ephemeral/real-time
data. Simply using a faster, and/or nonrelational database, doesn't
remove the problem, it just makes the setup perform better. It's a
difference of degree, not kind.

Ultimately, databases — including in-memory key-value stores — are for
storage, not for IPC. This doesn't stop them being routinely used as
such by people who do not know how to write IPC mechanisms and
middleware of their own. That's less excusable in an era with lots of
prefabricated options, whether message queues (e.g. AMQP) or distributed
systems closer to the application level (like DMQ).

-- Alex

-- 
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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Alex Balashov]

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 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 27 April 2018 at 21:23, 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
>
>> 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@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@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
>>
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity. 

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

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

[George Diamantopoulos]

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 27 April 2018 at 21:23, 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 
> 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@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@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

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

[Charles Chance]

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 on demand.
>
> A DNS alias that resolves to multiple entries is a great way to do that:
>
>
> https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.notification_address
> https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.multi_notify
>


This is how we’re doing it.


> although it'd be great if DMQ could exclude the local host from those
> notification peers automatically, so that one didn't have to set up
> multiple, exclusionary DNS entries for specific instances. Who knows,
> maybe it can.
>

It should be doing this already. If this is not the case, let me know in a
separate thread and I can take a look.

As for initial syncing of data, htable and dialog modules do not do this
currently, although I actually have it implemented locally in htable and
plan to push it soon to master. Dialog should not be difficult to do the
same.

Cheers,

Charles


-- 
*Charles Chance*
Managing Director

t. 0330 120 1200m. 07932 063 891

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

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

[Joel Serrano]

(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 +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:
>
> https://kamailio.org/docs/modules/5.1.x/modules/dmq.
> html#dmq.p.notification_address
> https://kamailio.org/docs/modules/5.1.x/modules/dmq.
> html#dmq.p.multi_notify
>
> although it'd be great if DMQ could exclude the local host from those
> notification peers automatically, so that one didn't have to set up
> multiple, exclusionary DNS entries for specific instances. Who knows,
> maybe it can.
>
> But in principle, such DNS records can be tied to the internal DNS
> resolution of a container discovery mechanism, be it Docker's internal
> mechanism or something more like Consul.
>
> -- Alex
>
> --
> 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@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

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

[Alex Balashov]

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:

https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.notification_address
https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.multi_notify

although it'd be great if DMQ could exclude the local host from those
notification peers automatically, so that one didn't have to set up
multiple, exclusionary DNS entries for specific instances. Who knows,
maybe it can.

But in principle, such DNS records can be tied to the internal DNS
resolution of a container discovery mechanism, be it Docker's internal
mechanism or something more like Consul. 

-- Alex

-- 
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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Aleksandar Sosic]

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.
> [...]

Hi Charles,

can you provide us with more info on how you configured DMQ between
the different kamailio instances?

We have a scalable dockerized environment and it's difficult to
configure DMQ having dynamic IPs, instances booting up and scaling
down on demand.

Also we've noticed that when a new instance comes up it doesn't sync
old values from the other dialogs and hash tables but gets only new
values from the boot time on.

Kind regards and thanks,
Alex

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

Re: [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 
> > 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@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@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
> 
> 
> -- 
> 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@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/

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

[Alex Balashov]

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


-- 
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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Charles Chance]

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

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

[Alex Balashov]

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@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Joel Serrano]

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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users