[SR-Users] dmq_usrloc for writing to DB on one machine

Sebastian Damm damm at sipgate.de
Wed Oct 21 09:49:02 CEST 2015


Hi,

I did see that REGISTERs received via DMQ are not replicated. What I was
wondering is, whether registrar 1 at some point discovers registrar 2
through the DMQ pings, and then "automagically" starts replicating its
packets to registrar 2, too.

Best Regards,
Sebastian

On Tue, Oct 20, 2015 at 5:32 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

> Hello,
>
> iirc, if one node doesn't handle a SIP register itself, should not publish
> to other nodes anything. Is this what you are looking for -- one node not
> to send to the others?
>
> Cheers,
> Daniel
>
>
> On 20/10/15 17:24, Sebastian Damm wrote:
>
> Hi,
>
> I evaluated the dmq_usrloc module, and it works pretty good if there are
> two identical machines which replicate their location with each other. But
> what I actually want to do is to send registrations to an extra machine
> which is just there for writing the location into a central DB (in one
> table for all the registrars), from where it can be accessed (by a web page
> for example).
>
> So for example, I have three machines, registrar 1 and registrar 2, and
> receiver. receiver will never interact with customers. It is just there for
> writing the location into the database.
>
> I configured both registrars to send their packets to receiver, and I
> configured the receiver to send its packets (which it actually never does)
> to a dns name containing both registrars. But after reading the content of
> some PING messages and reading something about "autodiscovery" of dmq on
> the mailing list, I'm not sure whether my scenario will work the way I want
> it to.
>
> Can somebody explain whether I can use dmq_usrloc for this purpose? Or is
> it only intended to be used for bidirectional replication?
>
> Best Regards,
> Sebastian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151021/2bc25dcc/attachment.html>


More information about the sr-users mailing list