<p>Hi,</p>
<p>If I were you, I'd prefer to have a memcached register of active conference room on their server(s), if the primary server fails to accept my call or it has reached a max.confernece.participant limit (N lets say) then I would append custom header in the failure route which tells which server and which conference room this call belongs to and route it to any End point FreeSwitch. </p>
<p>Call gets accepted on newer server, add it into the previously stated opensips registry. Then at the new FreeSwitch server add few scripts to detect those custom headers..initiate a new conference and a new call to dial to the server in header and add it into my current conference as participant. This is really interesting to initiate a call between two (freeswitches or more) and adding it as participant in local conference. </p>
<p>Thats what I always find more practical.</p>
<p>Any new call to same conference will again consult memcache from opensips and hence gets routed to the last inserted server IP with participant vacancy.</p>
<p>I hope I made some sense. </p>
<p>Thanks<br>
Sammy</p>
<div class="gmail_quote">On Dec 6, 2012 7:05 PM, "Emrah" <<a href="mailto:lists@kavun.ch">lists@kavun.ch</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is most interesting and I am curious to know the answer as well.<br>
<br>
Cheers,<br>
E<br>
On Dec 5, 2012, at 5:16 PM, Daniel Eiland <<a href="mailto:daniel.eiland@gmail.com">daniel.eiland@gmail.com</a>> wrote:<br>
<br>
> Hi guys,<br>
><br>
> I'm trying to deploy a conferencing solution using FreeSWITCH and running into a small issue with fail over / hot-standbys.<br>
><br>
> In my environment, I've got multiple FreeSWITCH/Conference endpoints registered with an OpenSIPS proxy. When calls come into OpenSIPS they are routed to the FreeSWITCH endpoints based on their q-values. If a FreeSWITCH instance fails (namely the one with the highest q-value), the call is simply routed to the next instance. This works great in most situations, however in some cases (namely network congestion) the FreeSWITCH w/highest priority is simply temporarily unavailable and callers to the same conference endpoint land on different servers.<br>
><br>
> I'm wondering if there is a mechanism for distributing (or sharing) a conference room across multiple FreeSWITCH instances. Namely, if a user lands in a conference hosted on server A while another lands in the same conference on server B, is there a mechanism in FreeSWITCH to connect the two servers/conferences (Presumably some "static" connection between the servers/rooms) so they can still talk with each over?<br>
><br>
> Thanks,<br>
> Daniel<br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div>