[Freeswitch-users] Scaling Freeswitch
colin.morelli at gmail.com
Mon Apr 18 18:46:11 MSD 2016
Doesn't sound like a lazy answer at all - it's perfectly fair. Hopefully I
didn't come off as trying to avoid learning SIP - that wasn't my goal here
at all. I'm actively reading up as much about SIP as I can reasonably
absorb. For me, trying to get a real example of something running so I can
rip it apart and play with it is the best way for me to learn, that's all I
was really going for here.
That said, note taken - I'll be diving back into learning more about the
protocol overall. I agree if I knew more about this it would probably
naturally fall together a lot easier. I picked up the FreeSWITCH book and
will get the OpenSIPS book as well. Thanks for the recommendation.
Thanks again everyone else for all of your input.
On Mon, Apr 18, 2016 at 10:39 AM Benjamin Cropley <
benjamin.cropley at gmail.com> wrote:
> This might sound like a lazy answer, but will help in the long term..
> I'd suggest learning about SIP as a protocol before you do anything else.
> You'll find learning the protocol itself inherently dictates how to scales
> across multiple servers. For example, in defining what the role of a
> Registrar is, SIP explains that a single 'server/process' can handle that
> job independently of any other SIP related activity. It likewise discusses
> that what a SBC is, and thereby helps understand that you can seperate the
> handling of SIP and RTP to a proxy and media server.
> Once you understand SIP properly, it's easy to come in and say "Well I
> need a registrar.. that's OpenSIPS or Kamailio.. Now I need a server to
> handle Media.. well FreeSWITCH does that.. I need a server to handle
> presence.. well presence can utilise dialog info to produce this I might as
> well use OpenSIPS or Kamailio".
> If you do implement it using Kazoo, using a guide, or whatever, you'll
> find yourself learning about SIP anyway. Why don't you just attack it head
> on, and you'll understand it all a bit better?
> The latest OpenSIPS book has a good chapter on SIP I think is worth the
> I think this is why a lot of people are responding with 'it depends'. What
> they really mean is, "SIP is a flexible protocol, and it's really your
> choice in how you want to implement its various components".
> On Mon, Apr 18, 2016 at 2:04 PM, Sergey Safarov <s.safarov at gmail.com>
>> Luis with all due respect to you and your work still...
>> as i said it depends on how you use it. it doesn't make sense to call the
>>> api to fetch a list of 200.000 devices or callflows. use v2 for paging
>>> and/or use the search api.
>> If you look at KAZOO-4326
>> <https://2600hz.atlassian.net/browse/KAZOO-4326> one more time, you can
>> see that I stores one callflow via kazoo API. For database containing about
>> 20 000 callflows 30 sec to save one callflow is much. Think saving 200 000
>> callflows via kazoo API took about 1-2 months.
>>> also, the question was about same realm not same account. you can have a
>>> common realm for many accounts.
>> I has tried assign same realm to two accounds but get error.
>> finally, as with any other software, kazoo does is not "completed" and
>>> there are optimizations tat can be done.
>> I completely agree with you. Moreover, I believe that what I have
>> described would not require major change in the kazoo. And soon kazoo can
>> be successfully used for the described case.
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> Official FreeSWITCH Sites
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> Official FreeSWITCH Sites
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users