|
|
|
|
|
by runT1ME
5660 days ago
|
|
>Simply the wrong tool for that, which Twilio has learned the hard way. Citation from something they said, or just deducting this the same way I did? (experience with Asterisk...) >While Freeswitch has better scale, it suffers from some of the same fundamental architectural issues Asterisk has for large distributed telephony applications. What are the same 'fundamental' architectural issues? They've seem to taken quite a different approach, or do you just feel C is the wrong way to go for a highly concurrent, scalable system? |
|
http://www.slideshare.net/twilio/reinventing-the-dialplan-sl...
Plus they have said publicly in other places that they built upon Asterisk.
As for Freeswitch. It is a great platform. Both Freeswitch and Asterisk may be made to scale, but it is not trivial and takes a fair amount of time and resources to do so and then to maintain over time. The issue for both of them is that the applications and media services tend to run in the same process. Digium's answer to this is SCF which is now under active development.
The approach we take (and others like Oracle, JBoss, Avaya, etc) is to deploy apps in SIP Servlet containers (Java) and your media in dedicated media servers (C/C++ for example). Employing a clear demarcation between application logic and media processing using MRCP (http://bit.ly/32Bnpu) between them.
Now, of course Freeswitch does have 'Mod unimrcp' (http://bit.ly/hmqvdq) which may be used to talk to our media servers (http://bit.ly/f9lUH3) and turn Freeswitch into an application platform. But when most people think of Freeswitch, they think of the equivalent of Asterisk and deploy that way.