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") {
dmq_handle_message();
}
...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...",
"text/plain");
(Receiving side)
if (method == "KDMQ") {
if ($rU == "custom_peer_name") {
#do something here
} else {
#pass it on to be handled by pre-registered peer
dmq_handle_message();
}
}
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,
Charles
On 25 February 2014 21:03, Olle E. Johansson <oej(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
www.sipcentric.com
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.