[Freeswitch-users] Questions on Building an application for FreeSWITCH

[Jan Berger]

N+N pools can be used for many things in telecom, but not for all. 

 

An IVR can as an example be a pool - rather than FS running the IVR server
side you connect to a ESL resource and run heavy work client side, maybe
through a pool manager. On this level you can even provide failover schemes
and fall-back schemes. Speech servers are another excellent candidate for
resource pools because speech requires a bit of CPU and it's very nice to be
able to scale up speech capacity by just throwing in more hardware.

 

The challenge comes when you want to do things like ACD on a N+N system. As
you agent's now might be connected to different FS boxes you need a
centralised instance to manage - in which case you can use N2 or simply use
a database that provide redundancy. 

 

Jan

 

  _____  

From: freeswitch-users-bounces at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Steven
Ayre
Sent: 26. mai 2010 12:39
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Questions on Building an application for
FreeSWITCH

 

But if that ESL server fails, your entire system goes down. Having N ESL
servers means one can fail and the other ESL server allows the cluster to
continue running until the failed server is replaced/repaired.

-Steve



On 13 May 2010 21:16, Phillip Jones <pjintheusa at gmail.com> wrote:

What would the advantage of an N to N architecture be though? An ESL server
controlling several FS instances has a view of everything that is going on.
All calls/conferences etc. A real advantage. That is lost when two ESL
servers are run in parallel. State information could be in a DB cluster -
but why not have the in-process app access this directly, cutting out the
middle man? 

How does using ESL make it more scalable and more available with fewer
components? I am sure you are correct - I just don't see it.

 

On Thu, May 13, 2010 at 3:15 PM, Kristian Kielhofner <kris at kriskinc.com>
wrote:

ESL connecting to a socket actually proves to be more scalable and
more available with fewer components.  Why not have N servers running
your socket app with N servers running FreeSWITCH?

OpenSIPS introduces its own issues with failover and I've yet to see
DNS SRV be the reliability/scalability solution it's made out to be.


On Thu, May 13, 2010 at 3:01 PM, Phillip Jones <pjintheusa at gmail.com> wrote:
> And just a general thought of using ESL vs an in process solution like
> mod_managed, or LUA.
>
> My understanding is, that using a separate server/process does potentially
> give you another point of failure and, if you use a single ESL server
> application to control several FS boxes, potentially a single point of
> failure. It is fairly easy to build a scalable and reliable FS cluster and
> using DNS SRV and OpenSIPS in order to avoid any single points of failure.
> Having independent FS boxes that pull data, but can fail with little
impact
> seems attractive to me,

--
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
http://www.submityoursip.com
http://www.voalte.com


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

 


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100526/049b4105/attachment-0001.html