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 &lt;oej(a)edvina.net&gt; wrote: -- 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.