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.
One of the best scenario would be to to have Opensips or kamailio in front of the FS servers to load balance registration requests and media to FS. On Wed, Jun 10, 2015 at 4:53 PM, Aqs Younas <aqsyounas@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
For residential, AS Alex suggested, having Kamailio or opensips will be best. Some people choose to have dedicated server for Voicemail so that all the files are recorded at one place. Rest everything can be load balanced on multiple freeeswitch servers. -Jai Rangi www.didforsale.com On Wed, Jun 10, 2015 at 2:38 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Stanislav: I may not have too much experience in FS + Kamailio setups, but I'll gladly contribute to this open project if you set it up. On Wed, Jun 10, 2015 at 11:24 PM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
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@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@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@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- NOUSHI Fayçal
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only). That would greatly simplify things. Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too. -giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
Why not OpenSIPS? I find OpenSIPS documentation way better and both projects are quite similar El 10/06/2015 19:21, "Giovanni Maruzzelli" <gmaruzz@gmail.com> escribió:
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only).
That would greatly simplify things.
Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too.
-giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FusionPBX has load balancing, and with a little DNS work you can have an HA in the cloud Luis Daniel Lucio Quiroz CISSP, CISM, CISA Linux, VoIP and much more fun www.okay.com.mx Need LCR? Check out LCR for FusionPBX with FreeSWITCH Need Billing? Check out Billing for FusionPBX with FreeSWITCH 2015-06-11 8:17 GMT-04:00 Victor Medina <victor.medina@cibersys.com>:
Why not OpenSIPS? I find OpenSIPS documentation way better and both projects are quite similar El 10/06/2015 19:21, "Giovanni Maruzzelli" <gmaruzz@gmail.com> escribió:
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <ssinyagin@gmail.com
wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only).
That would greatly simplify things.
Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too.
-giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I like Kamailio, but actually both can do this job nicely. We could even create a config that works for both :-) we only need to find enough business interest and sponsorship for such a project. On Thu, Jun 11, 2015 at 2:17 PM, Victor Medina <victor.medina@cibersys.com> wrote:
Why not OpenSIPS? I find OpenSIPS documentation way better and both projects are quite similar
El 10/06/2015 19:21, "Giovanni Maruzzelli" <gmaruzz@gmail.com> escribió:
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only).
That would greatly simplify things.
Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too.
-giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Kamailio is a natural choice for a lot of the "Class 4" call processing that doesn't require higher-order/application-level media services in general. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. Original Message From: Stanislav Sinyagin Sent: Thursday, June 11, 2015 09:20 To: FreeSWITCH Users Help Reply To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] help in architecture I like Kamailio, but actually both can do this job nicely. We could even create a config that works for both :-) we only need to find enough business interest and sponsorship for such a project. On Thu, Jun 11, 2015 at 2:17 PM, Victor Medina <victor.medina@cibersys.com> wrote:
Why not OpenSIPS? I find OpenSIPS documentation way better and both projects are quite similar
El 10/06/2015 19:21, "Giovanni Maruzzelli" <gmaruzz@gmail.com> escribió:
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only).
That would greatly simplify things.
Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too.
-giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks guys for your valuable pointers. Stanislav : I feel sorry to say that we are not that expert to help you, both programmatically or financially. We will use opensips at front end(since we are more comfortable with it) and for else freeswitch. Once again Thanks a lot. Have a good day. On 11 June 2015 at 06:27, Alex Balashov <abalashov@evaristesys.com> wrote:
Kamailio is a natural choice for a lot of the "Class 4" call processing that doesn't require higher-order/application-level media services in general.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry. Original Message From: Stanislav Sinyagin Sent: Thursday, June 11, 2015 09:20 To: FreeSWITCH Users Help Reply To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] help in architecture
I like Kamailio, but actually both can do this job nicely. We could even create a config that works for both :-)
we only need to find enough business interest and sponsorship for such a project.
On Thu, Jun 11, 2015 at 2:17 PM, Victor Medina <victor.medina@cibersys.com> wrote:
Why not OpenSIPS? I find OpenSIPS documentation way better and both projects are quite similar
El 10/06/2015 19:21, "Giovanni Maruzzelli" <gmaruzz@gmail.com> escribió:
On Thu, Jun 11, 2015 at 12:24 AM, Stanislav Sinyagin <
ssinyagin@gmail.com>
wrote:
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.
Also, you can have the same database table used by Kamailio for registrations (read-write), used also by FreeSWITCH (read-only).
That would greatly simplify things.
Add a NAS for configurations and media storage (prompts, voicemails, etc), some logic for having (audio|video) conferences participants to go on the same box, and you have an interesting solution, that keep most of the logic on FreeSWITCH side, and can permit to dish out "advanced" services to residential customers too.
-giovanni
On Wed, Jun 10, 2015 at 11:47 PM, Aqs Younas <aqsyounas@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@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@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@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@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@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@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@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@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@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@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@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 Cell : +39-347-2665618
Professional FreeSWITCH Consulting Services: consulting@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Is there some particular reason you want to have these users register to a Freeswitch-based registrar? Kamailio can easily handle 10,000 registrants in one instance. Call processing services can then (if you so desire) be provided to those users from Freeswitch. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
participants (9)
-
Adolphe Cher-Aime
-
Alex Balashov
-
Aqs Younas
-
fayçal noushi
-
Giovanni Maruzzelli
-
Jai Rangi
-
Luis Daniel Lucio Quiroz
-
Stanislav Sinyagin
-
Victor Medina