<div dir="ltr"><p dir="ltr">Thanks William for taking out time to send a detailed reply. I am exploring a scaleable callcentre solution and came across AMQP as an excellent alternative to the external application managing the call flow. <br>
I looked further inside the mod_callcentre.c and yeah I see that events are just sent only which means that sharing events is not enough and we might additionally need to send commands so the FS servers can actually do some action. <br><br><b>Regarding ODBC:</b><br>I have question about Shared ODBC between mod_callcenter, I do see that this module do alot of SQL queries to work, but is that shared ODBC enough to make all FS servers act as one big callcenter ? Last time I read people still had problems with this. I also see "single_box" value hard coded in System-type field and I do see "multi_box" related discussions stating that this is a future goal. The Problem I've heard so far is that when an agent state is changed in one FS rest of the FS servers might not be aware of the changed DB value(as they might've pulled older status) This may be very visible in large call volume. I maybe wrong but this is what I've understood so far.<br><br>I also think that if I modify the mod_callcenter.c file such that instead of making DB connections if it could all be shifted to a memcache mechanism then it may perform a little bit better. </p><p dir="ltr"><b>Regarding AMQP:<br></b><br>I took help from this page: <a href="https://quentustech.com/rabbitmq-support-in-freeswitch.html">https://quentustech.com/rabbitmq-support-in-freeswitch.html</a> and this is what I did:</p><p>1 - Started RabbitMQ Server</p><p>2 - Configured two FS servers with mod_amqp pointing to server in 1.</p><p>3 - Use the perl scripts mentioned on the above page to listen to events. The <a href="http://amqp_command.pl">amqp_command.pl</a> script lets me send a command to ALL of the FS Server.<br></p><p>It was clear to me that a RabbitMQ based approach lets me read on events and also lets me send commands to servers without doing a huge programming effort.</p><p>Next step to do would be to configure each FS server to bind to its unique virtualhost for commands (or use unique binding_key).<br>Then listen to calls+callcenter events from ALL the FS Servers, and based on whatever logic send commands to FS servers such that if an EVENT occurs stating an agent is taking call, send command to rest of the FS servers to mark that agent as "Busy".</p><p>Let me know your thoughts on this. </p><p>Best Regards.<br>Sammy<br><br></p>
<div class="gmail_quote">On Mar 9, 2016 16:13, "William King" <<a href="mailto:william.king@quentustech.com" target="_blank">william.king@quentustech.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sammy,<br>
<br>
Great question. mod_amqp has several different profile types: producer,<br>
commands, logging, and consumer(not yet implemented). The producer<br>
profile type only sends FS events to an amqp exchange(though you can<br>
configure multiple profiles with different event bindings and<br>
destination exchanges).<br>
<br>
To achieve what you're talking about would require mod_amqp profiles to<br>
subscribe and consume events from an amqp exchange, and then<br>
process/fire those events locally.<br>
<br>
Now the second way to handle what you're describing would be to have the<br>
different FS servers configured so that the modules use the same DB<br>
info, so that they're all looking at the same DB state. This would not<br>
require amqp to consume and process the events.<br>
<br>
William King<br>
Senior Engineer<br>
Quentus Technologies, INC<br>
1037 NE 65th St Suite 273<br>
Seattle, WA 98115<br>
Main: (877) 211-9337<br>
Office: (206) 388-4772<br>
Cell: (253) 686-5518<br>
<a href="mailto:william.king@quentustech.com" target="_blank">william.king@quentustech.com</a><br>
<br>
On 3/3/16 10:52 AM, SamyGo wrote:<br>
> Hi All,<br>
><br>
> I am experimenting with mod_amqp , I've a RabbitMQ server deployed. What<br>
> I'm trying to find out is if N number of FreeSwitch Servers are<br>
> connected to the same virtualhost to send and receive events and all<br>
> FreeSwitch servers are connected to same backend Database. In that<br>
> particular situation if one server sends an Update status of a SIP<br>
> endpoint to the MessageBus and rest of the FS receives them, will they<br>
> also consider that SIP endpoint as Busy/On-Call ?<br>
><br>
> Another example could be change in call_centre agent state change. If<br>
> one FS sends an event stating the agent is busy, will rest of the FS<br>
> servers honour this and not assign calls to the agent until a free event<br>
> is received !!<br>
><br>
> Thanks,<br>
> Sammy<br>
><br>
><br>
><br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div>
</div>