Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem? To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well. Thanks in advance. Best, Colin
Explain more what you want to do. I have dinner it without kamalio. Don't know if that fits your needs Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if
anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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 think that's part of what I'm trying to figure out here. I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain. However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling) Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this). Thanks for the response. Best, Colin On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz < luis.daniel.lucio@gmail.com> wrote:
Explain more what you want to do. I have dinner it without kamalio. Don't know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if
anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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
Take a look at the 2600hz kazoo platform. Will probably do everything you need out of the box.. On Sat, Apr 16, 2016 at 6:01 PM, Colin Morelli <colin.morelli@gmail.com> wrote:
I think that's part of what I'm trying to figure out here.
I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain.
However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling)
Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this).
Thanks for the response.
Best, Colin
On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> wrote:
Explain more what you want to do. I have dinner it without kamalio. Don't know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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
I took a look at that earlier. While it looks nice, it almost opened up more questions than it answered. Mostly because I'm not the type to want to start using something without understanding exactly what it's doing and how. In fact, part of the reason for me asking this question stemmed from looking through what they're doing. Effectively I'm already doing the same things (minus Kamailio). I have mod_amqp pushing channel events to RMQ that are read by my application, mod_httapi making requests out to my application for call routing, etc. I'm not sure I need anything more than that right now, though I acknowledge that it's possible I just don't know enough about the problem domain yet to appreciate everything involved in Kazoo. But I'm also a ways from really needing that. I'll do some more digging, though, and see if I can learn more about it. Thanks, Colin On Sat, Apr 16, 2016 at 8:16 PM Brian :: <bc@iptel.co> wrote:
Take a look at the 2600hz kazoo platform. Will probably do everything you need out of the box..
On Sat, Apr 16, 2016 at 6:01 PM, Colin Morelli <colin.morelli@gmail.com> wrote:
I think that's part of what I'm trying to figure out here.
I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain.
However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling)
Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this).
Thanks for the response.
Best, Colin
On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> wrote:
Explain more what you want to do. I have dinner it without kamalio.
Don't
know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out
large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
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
Warning Kazoo is not designed to creation thousands of devices in one realm. On Sun, Apr 17, 2016, 03:14 Brian :: <bc@iptel.co> wrote:
Take a look at the 2600hz kazoo platform. Will probably do everything you need out of the box..
On Sat, Apr 16, 2016 at 6:01 PM, Colin Morelli <colin.morelli@gmail.com> wrote:
I think that's part of what I'm trying to figure out here.
I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain.
However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling)
Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this).
Thanks for the response.
Best, Colin
On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> wrote:
Explain more what you want to do. I have dinner it without kamalio.
Don't
know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out
large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
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
Hi, Am I understanding correctly? I assume Kamailio would remove itself from
the media flow in this case, leaving just Client --> FS --> Client for media transfer, right?
Correct, Kamailio is not involved in media exchange. It sounds like this still wouldn't remove the need for shared state
management across the FS cluster, though. So, you'd have a Kamailio cluster backed by a database processing SIP registrations and location information, backed by FS with a shared database storing call state. This should allow the failure of either a Kamailio instance and/or FS instance and still allow the call to be recovered. It'll also allow you to offload all SIP registration to Kamailio and it's database, while leaving FS freed up for media/call routing. Does this sound right?
It depends, personally I would not have share db between Freeswitch servers. How often you expect one Freeswitch server to fail? In this case shared DB will help only with call recover, so if one server fails second will take care of a call, but if you don't have this then existing calls on that server will drop with server. Again it depends on your requirements if this death and life question, then probably you need to have shared DB, but in almost all other cases, I doubt. I don't expect that freeswitch will fail often, but shared DB will add much more complexity in to this architecture, so again you need to look to your requirements and then you need to decide what is best way for you. With kind regards, Jurijs On Sun, Apr 17, 2016 at 6:56 AM, Sergey Safarov <s.safarov@gmail.com> wrote:
Warning Kazoo is not designed to creation thousands of devices in one realm.
On Sun, Apr 17, 2016, 03:14 Brian :: <bc@iptel.co> wrote:
Take a look at the 2600hz kazoo platform. Will probably do everything you need out of the box..
On Sat, Apr 16, 2016 at 6:01 PM, Colin Morelli <colin.morelli@gmail.com> wrote:
I think that's part of what I'm trying to figure out here.
I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain.
However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling)
Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this).
Thanks for the response.
Best, Colin
On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> wrote:
Explain more what you want to do. I have dinner it without kamalio.
Don't
know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com> a écrit :
Does anyone have any good references for horizontally scaling out
large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
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
_________________________________________________________________________ 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
This isn't true On Saturday, April 16, 2016, Sergey Safarov <s.safarov@gmail.com> wrote:
Warning Kazoo is not designed to creation thousands of devices in one realm.
On Sun, Apr 17, 2016, 03:14 Brian :: <bc@iptel.co <javascript:_e(%7B%7D,'cvml','bc@iptel.co');>> wrote:
Take a look at the 2600hz kazoo platform. Will probably do everything you need out of the box..
On Sat, Apr 16, 2016 at 6:01 PM, Colin Morelli <colin.morelli@gmail.com <javascript:_e(%7B%7D,'cvml','colin.morelli@gmail.com');>> wrote:
I think that's part of what I'm trying to figure out here.
I'm looking to run a SIP platform that will support multiple tenants and device types (SIP phones, WebRTC clients, etc). Each tenant can be isolated to a subset of hosts, as there's no need to bridge across multiple tenants. My initial thought was to run SIP proxies in front of small clusters of FS servers. Essentially creating cluster A, B, C, and so on, each of which is made up of a few FS hosts. Then, have a much smaller number of Kamailio instances in the front that essentially proxy SIP traffic to the appropriate SIP cluster for the requested domain.
However, I'm not sure how well this scales. I've been reading a lot about FS being great as a media server, but there being better options for the signaling portion. My proposal would still push SIP registration and signaling to FS, just with a proxy in front. The alternative approach is to have Kamailio do all SIP registration and signaling, using FS as a media server, but I'm not sure what implications this has on the ability to do dynamic call routing in FS (for example, how would I use uuid_intercept to intercept a live call if Kamailio is performing all of the signaling)
Most likely my issue is just a lack of depth in the understanding of the roles that Kamailio and FS would play in a hybrid scenario (I'll admit I'm new to this).
Thanks for the response.
Best, Colin
On Sat, Apr 16, 2016 at 12:54 PM Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com <javascript:_e(%7B%7D,'cvml','luis.daniel.lucio@gmail.com');>> wrote:
Explain more what you want to do. I have dinner it without kamalio.
Don't
know if that fits your needs
Le 16 avr. 2016 12:41 PM, "Colin Morelli" <colin.morelli@gmail.com <javascript:_e(%7B%7D,'cvml','colin.morelli@gmail.com');>> a écrit :
Does anyone have any good references for horizontally scaling out
large
multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure. Sergey. сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin _________________________________________________________________________ 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
Hi, It is not mandatory to use Kamailio as registrar server, you can use Freeswitch as registrar server and Kamailio can just load balance all SIP messages to Freeswitch, including registrations... With kind regards, Jurijs On Sat, Apr 16, 2016 at 8:05 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure.
Sergey.
сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin _________________________________________________________________________ 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
Jurijs, That's good to know, since that's what my original plan was. Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility? It would seem that you could have virtually "infinite" scale with this approach. Am I right to assume that you could TCP load balance traffic to a small number of Kamailio servers up front, which then have a database mapping SIP domain -> another cluster of FS servers behind them? So, tenants 1, 2 and 3 go to cluster A, 4, 5, 6 to cluster B, and so on? If so, am I missing why you might want Kamailio to perform the registration at all? Best, Colin On Sat, Apr 16, 2016 at 1:13 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
It is not mandatory to use Kamailio as registrar server, you can use Freeswitch as registrar server and Kamailio can just load balance all SIP messages to Freeswitch, including registrations...
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 8:05 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure.
Sergey.
сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin _________________________________________________________________________ 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 particular advantage, then, to using Kamailio for SIP registrations if this is a possibility?" This simplifies sending messages to the client in a case where it is behind NAT. Sergey сб, 16 апр. 2016 г. в 20:18, Colin Morelli <colin.morelli@gmail.com>:
Jurijs,
That's good to know, since that's what my original plan was. Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility? It would seem that you could have virtually "infinite" scale with this approach. Am I right to assume that you could TCP load balance traffic to a small number of Kamailio servers up front, which then have a database mapping SIP domain -> another cluster of FS servers behind them?
So, tenants 1, 2 and 3 go to cluster A, 4, 5, 6 to cluster B, and so on? If so, am I missing why you might want Kamailio to perform the registration at all?
Best, Colin
On Sat, Apr 16, 2016 at 1:13 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
It is not mandatory to use Kamailio as registrar server, you can use Freeswitch as registrar server and Kamailio can just load balance all SIP messages to Freeswitch, including registrations...
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 8:05 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure.
Sergey.
сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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
Hi, Kamailio is SIP proxy, so it was build to support thousands and millions SIP registrations and it will perform better then freeswitch as registrar server(no offense guys, freeswitch is brilliant software, but it can't be 1st everywhere :D), so from performance perspective, Kamailio is better to use for registration, then Freeswitch, but if you are building set-up for no more then 10K(or even more) extensions, then there is no such huge difference in performance and you can leave registrar server on Freeswitch side... By default I will recommend you to go in standard way - Kamailio as registrar server, but again I don't know your full requirements and maybe this is not best way for you... I would like to emphasize that Freeswitch as registrar server is just one option from several other options and I really don't know which one is best for you. With kind regards, Jurijs On Sat, Apr 16, 2016 at 8:25 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
"Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility?" This simplifies sending messages to the client in a case where it is behind NAT.
Sergey
сб, 16 апр. 2016 г. в 20:18, Colin Morelli <colin.morelli@gmail.com>:
Jurijs,
That's good to know, since that's what my original plan was. Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility? It would seem that you could have virtually "infinite" scale with this approach. Am I right to assume that you could TCP load balance traffic to a small number of Kamailio servers up front, which then have a database mapping SIP domain -> another cluster of FS servers behind them?
So, tenants 1, 2 and 3 go to cluster A, 4, 5, 6 to cluster B, and so on? If so, am I missing why you might want Kamailio to perform the registration at all?
Best, Colin
On Sat, Apr 16, 2016 at 1:13 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
It is not mandatory to use Kamailio as registrar server, you can use Freeswitch as registrar server and Kamailio can just load balance all SIP messages to Freeswitch, including registrations...
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 8:05 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure.
Sergey.
сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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
_________________________________________________________________________ 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 the additional info, Jurijs. This has been very helpful already. Sorry I'm a bit slow here (a lot of this is quite new to me, so I'm trying to absorb as much knowledge as I can). If Kamailio is the registrar, what role does it play in call routing? For example, if a call hits FS and I instruct FS to bridge to a user, how is that performed? Or does all call routing now need to be performed on Kamailio, since it's the one that's aware of where users are (and their associated presence)? I'd just like to better understand the roles that each of these plays in this scenario. Thanks again. Best, Colin On Sat, Apr 16, 2016 at 1:45 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
Kamailio is SIP proxy, so it was build to support thousands and millions SIP registrations and it will perform better then freeswitch as registrar server(no offense guys, freeswitch is brilliant software, but it can't be 1st everywhere :D), so from performance perspective, Kamailio is better to use for registration, then Freeswitch, but if you are building set-up for no more then 10K(or even more) extensions, then there is no such huge difference in performance and you can leave registrar server on Freeswitch side...
By default I will recommend you to go in standard way - Kamailio as registrar server, but again I don't know your full requirements and maybe this is not best way for you...
I would like to emphasize that Freeswitch as registrar server is just one option from several other options and I really don't know which one is best for you.
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 8:25 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
"Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility?" This simplifies sending messages to the client in a case where it is behind NAT.
Sergey
сб, 16 апр. 2016 г. в 20:18, Colin Morelli <colin.morelli@gmail.com>:
Jurijs,
That's good to know, since that's what my original plan was. Is there particular advantage, then, to using Kamailio for SIP registrations if this is a possibility? It would seem that you could have virtually "infinite" scale with this approach. Am I right to assume that you could TCP load balance traffic to a small number of Kamailio servers up front, which then have a database mapping SIP domain -> another cluster of FS servers behind them?
So, tenants 1, 2 and 3 go to cluster A, 4, 5, 6 to cluster B, and so on? If so, am I missing why you might want Kamailio to perform the registration at all?
Best, Colin
On Sat, Apr 16, 2016 at 1:13 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
It is not mandatory to use Kamailio as registrar server, you can use Freeswitch as registrar server and Kamailio can just load balance all SIP messages to Freeswitch, including registrations...
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 8:05 PM, Sergey Safarov <s.safarov@gmail.com> wrote:
Usage of kamailio as registrator and FreeSwitch as call processing server is perfect way to create scalable VoIP infrastructure.
Sergey.
сб, 16 апр. 2016 г. в 19:40, Colin Morelli <colin.morelli@gmail.com>:
Does anyone have any good references for horizontally scaling out large multi-tenant FS clusters? Most of what I've been able to find involving load balancing Kamailio/OpenSIPS is fairly old (2+ years), and there's no recent versions of the information available. Has this not changed or is there a fundamental shift in how people have been tackling this problem?
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
Thanks in advance.
Best, Colin
_________________________________________________________________________ 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
_________________________________________________________________________ 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
On 16 April 2016 at 09:32, Colin Morelli <colin.morelli@gmail.com> wrote:
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
This won't answer all your questions but it will give you an idea of freeswitch + Kamailio: https://www.youtube.com/watch?v=6VsuC7-jHc4 -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si
Hi, If Kamailio is the registrar, what role does it play in call routing? For
example, if a call hits FS and I instruct FS to bridge to a user, how is that performed? Or does all call routing now need to be performed on Kamailio, since it's the one that's aware of where users are (and their associated presence)?
You can configure Kamailio and Freeswitch in anyway you need, Kamailio can be call router, freeswitch can be call router and both of them simultaneously can be call routers :) But if we will take following manual as starting point: http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc Then users location DB will be in Kamilio and information regarding users will be stored in Kamailio, so Freeswitch will not know where user located and all calls between extensions will go through Freeswitch and then will be looped back to Kamailio and Kamailio will decide where to route call. So in this case Kamailio is call router and it decides where to route calls, for example 44 prefix is routed to "vbox"(voicemail). Nevertheless you can add some additional routing on Freeswitch too if necessary, for example if you need to send calls to PSTN and you need transcoding. Nevertheless it is still possible to route PSTN calls directly from Kamailio too, without freeswitch. With kind regards, Jurijs On Sat, Apr 16, 2016 at 10:23 PM, jungle Boogie <jungleboogie0@gmail.com> wrote:
On 16 April 2016 at 09:32, Colin Morelli <colin.morelli@gmail.com> wrote:
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
This won't answer all your questions but it will give you an idea of freeswitch + Kamailio:
https://www.youtube.com/watch?v=6VsuC7-jHc4
-- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si
_________________________________________________________________________ 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
Jungle + Jurijs, Thank you, the combination of the YT video and your description is exactly what I was looking for. So, in summation here, what you'd have is SIP Client ----> Kamailio ----> FS (contains a dialplan to bridge user/1234) ----> Kamailio ----> Other SIP Client Am I understanding correctly? I assume Kamailio would remove itself from the media flow in this case, leaving just Client --> FS --> Client for media transfer, right? It sounds like this still wouldn't remove the need for shared state management across the FS cluster, though. So, you'd have a Kamailio cluster backed by a database processing SIP registrations and location information, backed by FS with a shared database storing call state. This should allow the failure of either a Kamailio instance and/or FS instance and still allow the call to be recovered. It'll also allow you to offload all SIP registration to Kamailio and it's database, while leaving FS freed up for media/call routing. Does this sound right? This has been incredibly helpful, thank you so much. Best, Colin On Sat, Apr 16, 2016 at 5:19 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
If Kamailio is the registrar, what role does it play in call routing? For
example, if a call hits FS and I instruct FS to bridge to a user, how is that performed? Or does all call routing now need to be performed on Kamailio, since it's the one that's aware of where users are (and their associated presence)?
You can configure Kamailio and Freeswitch in anyway you need, Kamailio can be call router, freeswitch can be call router and both of them simultaneously can be call routers :)
But if we will take following manual as starting point:
http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc
Then users location DB will be in Kamilio and information regarding users will be stored in Kamailio, so Freeswitch will not know where user located and all calls between extensions will go through Freeswitch and then will be looped back to Kamailio and Kamailio will decide where to route call.
So in this case Kamailio is call router and it decides where to route calls, for example 44 prefix is routed to "vbox"(voicemail).
Nevertheless you can add some additional routing on Freeswitch too if necessary, for example if you need to send calls to PSTN and you need transcoding.
Nevertheless it is still possible to route PSTN calls directly from Kamailio too, without freeswitch.
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 10:23 PM, jungle Boogie <jungleboogie0@gmail.com> wrote:
On 16 April 2016 at 09:32, Colin Morelli <colin.morelli@gmail.com> wrote:
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
This won't answer all your questions but it will give you an idea of freeswitch + Kamailio:
https://www.youtube.com/watch?v=6VsuC7-jHc4
-- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si
_________________________________________________________________________ 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
participants (7)
-
Brian ::
-
Colin Morelli
-
jungle Boogie
-
Jurijs Ivolga
-
Luis Daniel Lucio Quiroz
-
Michael Jerris
-
Sergey Safarov