<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
I see there are some new functions prefixed with kazoo_, using a
terminology familiar with presence extensions. Also, looking at the
source code a bit, the module doesn't seem to be an implementation
of a database connector. Am I right? I mean, just for example, it
cannot be used as a replacement for db_mysql.<br>
<br>
If it is not a database connector, then I would suggest to remove
the db_ prefix from the name of the module, because it creates
confusion. Several years ago, database connectors used to have any
kind of name, but it was decided to prefix them with 'db_' to be
easier to spot and manage.<br>
<br>
As I see it right now, I would choose either simply 'kazoo',
'amqp_kazoo' or something else without db_ prefix.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 09/09/14 14:12, Luis Azedo wrote:<br>
</div>
<blockquote
cite="mid:6FFC6465A51B5B4C80DD111E16112FD1BC2146@mbx022-w1-ca-4.exch022.domain.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">Hi Daniel,
<div><br>
</div>
<div>you can check our current code
at <a class="moz-txt-link-freetext" href="https://github.com/2600hz/kazoo-kamailio/tree/4.0">https://github.com/2600hz/kazoo-kamailio/tree/4.0</a><a
moz-do-not-send="true"
href="https://github.com/2600hz/kazoo-kamailio/tree/4.0"
target="_blank">https://github.com/2600hz/kazoo-kamailio/tree/4.0</a></div>
<div><br>
</div>
<div>this is already compatible with master from kamailio (tests
running ok).</div>
<div><br>
</div>
<div>we will start to update the docs when we commit to master
and will get it ready before 4.2.</div>
<div><br>
</div>
<div><span style="font-size: 16px;">>>For a better
clarification, do the json payloads flowing via AMQP have a
structure specific for kazoo? I mean the object structure,
how are the fields name set, from the name of the columns?
Is there a >>wrapper to specify the command (e.g.,
insert, delete, select)? Or maybe you can provide an example
of such object...</span><br style="font-size: 16px;">
</div>
<div><br>
</div>
<div>No, the payloads are what you want. here's a sample on how
we are using to handle REGISTER messages</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div> if ($sht(auth_cache=>$Au) != $null
&& pv_auth_check("$fd", "$sht(auth_cache=>$Au)",
"0", "0")) {</div>
<div> xlog("L_INFO", "$ci|log|authenticated $Au
via cached SIP creds");</div>
<div> } else {</div>
<div> ## RABBITMQ - Credentials fetch</div>
<div> ## build the payload</div>
<div>>>> $var(amqp_payload_request) =
"{'Event-Category' : 'directory' , 'Event-Name' :
'authn_req', 'Method' : 'REGISTER', 'Auth-Realm' : '" + $fd
+ "', 'Auth-User' : '" + $fU + "', 'From' : '" + $fu + "',
'To' : '" + $tu +"' }";</div>
<div><br>
</div>
<div> $var(amqp_routing_key) = "authn.req." +
$(fd{kz.encode}); <span style="font-size: 10pt;">//</span><span
style="font-size: 10pt;"> kz.encode is a helper function
to encode properly to amqp</span></div>
<div><br>
</div>
<div><br>
</div>
<div> if(kazoo_query("callmgr",
$var(amqp_routing_key), $var(amqp_payload_request))) {
<span style="font-size: 10pt;">//</span><span
style="font-size: 10pt;"> kazoo_query publishes and
expects answer</span></div>
<div> xlog("L_DBG", "$ci|log|amqp_result =
$kzR"); <span style="font-size: 10pt;">// $kzR is the
result payload</span></div>
<div> $var(password) =
$(kzR{kz.json,Auth-Password}); </div>
<div><span style="font-size: 10pt;"> //
kz.json is a helper to extract values from payload, nested
values are permitted</span></div>
<div> // it could be something like <span
style="font-size: 10pt;">$(kzR{kz.json,</span><b>Channels[0].switch_url</b> <span
style="font-size: 10pt;">})</span><span style="font-size:
10pt;"> </span></div>
<div> if($var(password) != $null) {</div>
<div> if (!pv_auth_check("$fd",
"$var(password)", "0", "0")) {</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>we build the payload and publish it to rabbitmq, in this
case we wait for a correlated msg to get the result.</div>
<div>kazoo_publish -> sends only</div>
<div>kazoo_query -> sends and waits for correlated answer</div>
<div><br>
</div>
<div>here's an example on how we subscribe to a exchange</div>
<div><br>
</div>
<div>
<div>event_route[kazoo:mod-init]</div>
<div>{</div>
<div> #!ifdef PRESENCE-ROLE</div>
<div><span style="font-size: 10pt;"> $var(payload) = "{
'exchange' : 'dialoginfo' , 'type' : 'direct', 'queue' :
'BLF-QUEUE-MY_HOSTNAME', 'routing' : 'BLF-MY_HOSTNAME',
'auto_delete' : 0, 'durable' : 1, 'no_ack' : 0,
'wait_for_consumer_ack' : 1 }";</span></div>
<div><span style="font-size: 10pt;">
kazoo_subscribe("$var(payload)");</span></div>
<div> #!endif</div>
<div>}</div>
<div><br>
</div>
</div>
<div><span style="font-size: 10pt;">and how we react when we get
a message</span></div>
<div><br>
</div>
<div>
<div>event_route[kazoo:consumer-event-presence-update]</div>
<div>{</div>
<div> xlog("L_INFO", "received
$(kzE{kz.json,Event-Package}) update for
$(kzE{kz.json,From})");</div>
<div> kazoo_pua_publish($kzE);</div>
<div> pres_refresh_watchers("$(kzE{kz.json,From})",
"$(kzE{kz.json,Event-Package})", 1);</div>
<div>}</div>
</div>
<div><br>
</div>
<div>the event_route name is built from the payload we receive
on the subscription</div>
<div>kazoo:consumer-event - fixed</div>
<div>-presence - taken from parameter amqp_consumer_event_key</div>
<div>-update - taken from parameter amqp_consumer_event_subkey</div>
<div><br>
</div>
<div>amqp_consumer_event_key and amqp_consumer_event_subkey are
for now parameters for the module but we want to make by
subscription.</div>
<div>from the above example we will change it to </div>
<div>$var(payload) = "{ <b>'key' : 'fieldname', 'subkey' :
'fieldname'</b>, 'exchange' : 'dialoginfo' , 'type' :
'direct', 'queue' : 'BLF-QUEUE-MY_HOSTNAME', 'routing' :
'BLF-MY_HOSTNAME', 'auto_delete' : 0, 'durable' : 1, 'no_ack'
: 0, 'wait_for_consumer_ack' : 1 }";</div>
<div><br>
</div>
<div>right now, all interaction is made from configuration
script.</div>
<div>the long term will be to create a bind structure so that
other modules can interact directly with it.</div>
<div><br>
</div>
<div>let me know if that helps</div>
<div><br>
</div>
<div>Best</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div style="font-family: Times New Roman; color: #000000;
font-size: 16px">
<hr tabindex="-1">
<div id="divRpF929445" style="direction: ltr;"><font
face="Tahoma" color="#000000" size="2"><b>From:</b>
Daniel-Constantin Mierla [<a class="moz-txt-link-abbreviated" href="mailto:miconda@gmail.com">miconda@gmail.com</a>]<br>
<b>Sent:</b> Tuesday, September 09, 2014 4:45 AM<br>
<b>To:</b> Kamailio (SER) - Development Mailing List;
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<b>Cc:</b> Engineering<br>
<b>Subject:</b> Re: [sr-dev] new module db_kazoo<br>
</font><br>
</div>
<div>Hello,<br>
<br>
thanks for this contribution!<br>
<br>
Do you have a link to the module source code or can you
send it attached? We need to review a bit and check if
everything is in place (e.g., license, documentation).<br>
<br>
For a better clarification, do the json payloads flowing
via AMQP have a structure specific for kazoo? I mean the
object structure, how are the fields name set, from the
name of the columns? Is there a wrapper to specify the
command (e.g., insert, delete, select)? Or maybe you can
provide an example of such object...<br>
<br>
Kazoo is an open source application, therefore the new
module has no barrier in getting inside kamailio
repository. My questions were related more to see if worth
considering a new name.<br>
<br>
To get it in our git repository, we expect that you or
someone else from 2600hz is willing to maintain it for at
least one year. You will get write access over ssh to git
repository to be able to push the new module and commit to
it in the future. I will write a separate email directly
to you with the required details for access.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 09/09/14 12:22, Luis Azedo
wrote:<br>
</div>
<blockquote type="cite">
<style type="text/css" id="owaParaStyle"></style>
<div style="direction:ltr; font-family:Tahoma;
color:#000000; font-size:10pt">
<div>Hello Awesome Kamailio Community,</div>
<div>We are writing on behalf of 2600hz, where we have
been using Kamailio for some time now and are very
pleased with our results! So, seems time to commit
something back, dontchya think?</div>
<div><br>
</div>
<div>We would like to present to you a new module, to
hopefully be included in master. We call it
db_kazoo (although a new name is fine too).</div>
<div><br>
</div>
<div>db_kazoo is a general purpose AMQP connector
(connects to our rabbitmq-server). It exposes
publish/consume capabilities into Kamailio. Why is
this amazing, you ask? Well even if you didn’t ask,
we will explain…</div>
<div><br>
</div>
<div>From a high-level, the purpose of the module
might be for things like:</div>
<div>- Integrate to an AMQP application to make
real-time routing decisions (instead of using, say,
a SQL database)</div>
<div>- Provide a real-time integration into your
program, instead of your database, so you can
overlay additional logic in your preferred language
while also utilizing a message bus</div>
<div>- Utilize messaging to have a distributed
messaging layer, such that machines processing
requests/responses/events can go up/down or share
the workload and your Kamailio node will still be
happy</div>
<div><br>
</div>
<div><br>
</div>
<div>With this module, someone can:</div>
<div>1 - publish json payloads to rabbitmq</div>
<div>2 - publish json payloads to rabbitmq and wait
for correlated response message</div>
<div>3 - subscribe to an exchange with a routing key</div>
<div><br>
</div>
<div>The module works with a main forked process that
does the communication with rabbitmq for issuing
publishes, waiting for replies and consuming
messages. When it consumes a message it defers the
process to a worker process so that it doesn't block
this main process.</div>
<div><br>
</div>
<div>The worker process issues an event-route where we
can act on the received payload. The name of the
event-route is composed by values extracted from the
payload.</div>
<div><br>
</div>
<div>Consumed messages have the option of being
acknowledge in two ways:</div>
<div>1 - immediately when received </div>
<div>2 - after processing by the worker</div>
<div><br>
</div>
<div>One unique feature of our implementation revolves
around failover of the message bus itself. In our
design, the module supports multiple RabbitMQ
servers and will fallback from one to the next in a
list of RabbitMQ servers if the connection fails to
the current connected server. When using acknowledge
in db_kazoo with clustering in RabbitMQ, we have
simulated and experienced full reconnects while in
the middle of processing pending messages. In this
way, when we get disconnected from one server we
proved that, even at high speeds, we are able to
connect to the next in the list and continue
interacting with our application.</div>
<div><br>
</div>
<div>We have run a variety of sipp load tests on this
module and believe it is ready for prime time. We
monitored memory, response accuracy and overall
stability and it seemed OK. But we would, of course,
love for others to help us find what we have missed,
or contribute more features, or overall just use the
work we slaved over for so many hours. Or just make
comments and suggestions!</div>
<div><br>
</div>
<div>If nothing else, we hope we’ve provided something
useful to the Kamailio community, as you all have
provided useful items to us.</div>
<div><br>
</div>
<div>Thanks to everyone for all the work on Kamailio
and related products.</div>
<div><br>
</div>
<div>Look forward to hearing from you all.</div>
<div><br>
</div>
<div>This is our first formal / large contribution to
Kamailio so if we’ve done something wrong process,
code or otherwise please let us know!</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader" target="_blank"></fieldset>
<br>
<pre>_______________________________________________
sr-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany</pre>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany</pre>
</body>
</html>