[Freeswitch-users] [OpenSIPS-Users] [SR-Users] ClueCon Slides: Industrial Grade FreeSWITCH, Scaling, Balancing, High Availability, SIP, WebRTC

[Tihomir Culjaga]

On 18 August 2017 at 16:46, Giovanni Maruzzelli <gmaruzz at gmail.com> wrote:

>
>
> On 17 August 2017 at 11:20, Tihomir Culjaga <tculjaga at gmail.com> wrote:
>
>> hi Giovanni, nice presentation!
>>
>> i got few questions tho :=)
>>
>> 1. you mentioned you use FusionPBX to provision. So, can it provision a
>> FS farm without switching from one FS to another ? I mean, can Fusion
>> provision a farm of FS as is not a single node per node ?
>>
>
> FusionPBX, if you use it, is able to provision (eg, to configure,
> reconfigure, etc) the PHONES that are used by the platform
>

To be honest, I tried FusionPBX once and there is a lot of lua under the
hood ... didn't like it at that time as im not that into lua (my fault
:=)). If this fixes phone provision only, i think its better having an
xml_curl config server to feed both PHONES and FreeSWITCH
(configuration/directory) across N number of FS nodes seamlessly .. no need
to partition anything.


>
>
>> 2. what do you use to "distribuite" VERTO calls from kamailio to FS(x).
>>
>
> as explained in the presentation, to distribute VERTO calls you either
> partition them on domain (eg, hash on domain client side as in case of
> multidomain, pbx in the cloud like), or distribute them using different
> redirected port for signaling (each port going to different backend
> machines). You can use iptables or HAProxy. For media, you assign each
> backend machine a different range of rtp ports, and redirect them from the
> front machine. You use iptables. VERTO has no trunking or external registar
> function. Neither has a proxy function.
>

i was planing to use nginx or haproxy to load balance websockets across
Freeswitch farm and iptables for RTP forwarding.


>
>
> 3. how do you configure "static" SIP trunks between FS(x) to allow VERTO
>> to VERTO calls across entire FS farm ?
>>
>
> You can have verto to verto calls only between verto users registered on
> the same machine. For users on different machines you will need to use
> traditional SIP routing, and use traditional sip addressing. Eg
> userA at domainA will call userB at domainB. Each user is registered via VERTO
> on a different machines. Call will be VERTO from userA to machineA SIP from
> machineA to machineB VERTO from machineB to userB
>
>
>
here i was thinking to create a location service on kamailio that will
respond with 302 message pointing to FS node having the correct verto
registration.

e.g.
- verto user1 registers, haproxy balances wss to node1
- verto user2 registres, haproxy balances wss to node2

when user1 calls user2, i can make FS1 ask for location ( INVITE ) to
kamailio, so i get a correct FS node in 302 contact. This way FS1 can place
a call to FS2 without any specific mambo jumbo dialplan... and especially,
anything static.

my goal is to have a setup where i don't need to group specific hosted pbx
group members on the specific node.




> 4. ...and many more but i will stop now :=)
>>
>
> :) Yes, I understand there can be enough for talking and writing for days
> and weeks, and unfortunately I will I will not be able to further discuss
> things in mailing list. But I hope I answered your questions.
>
> That will be matter of a future book, maybe, and for sure for next
> presentations.
>
>



> So, get ready for ClueCon 2018, and the other important meetups of our
> community like OpenSIPS Summits, Kamailio World, FOSDEM, etc :)
>
> Thank you for nice words
>
> -giovanni
>
>
>
>>
>> Regards,
>> Tihomir
>>
>>
>> On 17 August 2017 at 07:37, Giovanni Maruzzelli <gmaruzz at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 17 August 2017 at 02:32, Adrian Georgescu <ag at ag-projects.com> wrote:
>>>
>>>> Giovanni,
>>>>
>>>> The creature on page 55 and 56 is a dude, man!
>>>>
>>>
>>>
>>> I was more focused on the other one, but yes, he's a dude. An happy dude
>>> :)
>>>
>>> -giovanni
>>>
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.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
>>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.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
>>
>
>
>
> --
>
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170818/a12f6cb0/attachment.html>