[sr-dev] git:master: dmq: added function to broadcast message from config file.

Charles Chance charles.chance at sipcentric.com
Tue Feb 25 23:12:18 CET 2014

Hello Olle,

I may eventually create a sample config, but there are still a few things
missing. However, the htable integration alone has enabled us personally to
replicate things like call profiles (for concurrent call limiting), failed
authentication attempts, etc. across a cluster of servers without having to
define the other node addresses anywhere in the config.

Generally, peers are registered from directly within other modules at
startup (see htable for example). Then at the beginning of config you would
add something like...

        if (method == "KDMQ") {

...and the dmq module would pass the message directly to the already
registered peer for internal handling.

However, each peer is uniquely identified by the user part of the request
URI, so it is equally possible to send an arbitrary message from within
config on one server and handle it directly in config of others, like:

(Sending side)

        dmq_bcast_message("custom_peer_name", "Some serialized data...",

(Receiving side)

        if (method == "KDMQ") {
                if ($rU == "custom_peer_name") {
                        #do something here
                } else {
                        #pass it on to be handled by pre-registered peer

The serialization/deserialization of the body content is entirely up to the
module developer (in code) or server administrator (in config). It can be
anything - or nothing. Currently in the config, we're using it to replicate
PUBLISHes, although I plan to integrate dmq into the presence module
directly in the very near future. Then there is no need for anything
special in the config, just like htable is now - other than setting
modparam to enable it of course.

Best regards,

On 25 February 2014 21:03, Olle E. Johansson <oej at edvina.net> wrote:

> >
> >
> > dmq: added function to broadcast message from config file.
> >
> THanks,
> This commit caused me to re-read the DMQ docs as I am happy to see that it
> is starting to move forward again as a module. What I fail to understand at
> this point is how incoming messages are handled. I see a handler but then -
> what?
> The doc says something about using a library for serialization... Of what?
> How can this be used in a normal configuration example?
> Can event_routes be added to handle incoming messages like normal messages?
> I feel there's a diamond hidden in there somewhere, and fail to find it ;-)
> /O
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham 
B7 4EJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140225/7fc7db29/attachment.html>

More information about the sr-dev mailing list