[Freeswitch-users] help in architecture

[Stanislav Sinyagin]

How about an open-design and open-source project? Many companies want
the same, and now they have to design and build the whole thing from
scratch. Everyone could actually benefit from a joint effort instead.

I think residential mass service should be completely separated from
business PBX service, as they have completely orthogonal requirements.

I would propose something like this for residential users:

1. Kamailio cluster handles user registrations and SIP OPTIONS pings.
It also blocks some basic scanning and DOS attacks. The user
registrations are stored in a backend SQL database.

2. Calls from users are handled by Kamailio's DISPATCHER module, and
it sends them to a pool of FreeSWITCH media servers in round-robin or
hash-based fashion.

3. As the call from a user arrives to FreeSWITCH server, it places it
to &park() application. Then, an external routing program catches this
event via ESL, and makes the routing decision: if the destination is
one of our own users, we take the user's location from Kamailio's
registrar database and send the call to Kamailio for further
forwarding to the user (the SIP INVITE toward the user should come
from registrar's IP address and port, otherwise NAT firewalls will
block it).

4. If the destination is not our own user, the routing program sends
the call to one of PSTN trunks. Here it may also have some logic, like
cost optimization and trunk status monitoring.

5. Incoming calls from PSTN are also parked and handled by our routing program.

6. If the SIP user is not reachable, the routing program looks up in
user's preferences and sends the call to voicemail or forwarding
destination. The user may also have some calendar or time-of-day
options -- the program should actually be modular and extendable, so
that new features are added as needed, and also third parties can add
their own functionality.

Golang.org is probably one of the best choices for such a routing program.

-----------------

for business PBX, it makes sense to register users at FreeSWITCH --
then we have BLF and notofocations working out of the box. Kamailio
can still be used for security screening and fault tolerance. Also
business customers will want conference bridges, and probably video
calls or video conferencing. So, here it's a completely different
challenge, and needs to be designed separately. User registrations
could be served with mod_xml_curl, and call routing could also be
routed by an external program via ESL.


I would be glad to jump in onto such a project if it were open-source
and open-design.







On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas at gmail.com> wrote:
> Thanks your for reply.
>
> Alex: We are planning some pbx related functions too. Like voicemail, ivr,
> block numbers.
> Thats why we chose to keep registrations at freeswitch end.
>
> On 10 June 2015 at 14:38, Aqs Younas <aqsyounas at gmail.com> wrote:
>>
>> Thanks for your reply.
>>
>> Stanislav Sinyagin : Majority of them are residential users with simple
>> service.
>>
>>
>> On 10 June 2015 at 14:13, Stanislav Sinyagin <ssinyagin at gmail.com> wrote:
>>>
>>> Are those residential users with a uniform and simple service, or
>>> business customers with small work groups and business-specific call
>>> routing?
>>>
>>> On Jun 10, 2015 10:54 PM, "Aqs Younas" <aqsyounas at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Hope you all are having a good day. :)
>>>>
>>>> I need some suggestions in designing SIP trunking with freeswitch.
>>>> We are required to register more than 10,000 users on multiple
>>>> freeswitch instances sharing same database.
>>>>
>>>> How can we load balance registration on each freeswitch so, they have
>>>> equal number of registrations.
>>>>
>>>> I know with mod_xml_curl i can have freeswitch share same database. But
>>>> how can i load balance registrations?
>>>> (inbound calls must be directed to that freeswitch with which user is
>>>> registered)
>>>>
>>>> Or any suggestion how we can achieve this, so, that we can add more
>>>> freeswitch in future.
>>>>
>>>> Thanks for your help.
>>>>
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> 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
>>
>>
>
>
> _________________________________________________________________________
> 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