Joining several FS servers in different regions
I'm working on a Saas service that will connect WebRTC (with SIP or Verto for signaling) clients to one another and to PSTN. I'm aware of other such services, but this is tailored to a specific niche. I also want WebRTC media to flow through FS, rather than P2P, so that I can record it. The primary markets are Europe and North America. To keep latency low I need to have servers on both continents. Later on I might want to add more regions. I'm not too worried about high availability or high loads. The clients can keep track of which FS is closest to them and register with that. But this still leaves me with a couple of questions. 1. Maintaining a single user database ===================================== What's the simplest way of maintaining one joint user database? (User directory in FS parlance). The first thing that comes to mind is to generate the xml dynamically from a central database, and force as `reloadxml` on all servers every time there's an update. The communication between central database and FS servers could be via RabbitMQ. mod_xml_curl could also be a part of this I guess. How does that sound? Is there an other simpler way of achiving my goal that I'm not seeing? 2. Keeping track of where a user i currently registered ======================================================= Let's say I have a client Alice who's registered with a FS server in North America and a client Bob who has registered wit a FS server in Europe. Now Alice tries to call Bob. How does the North America server know that Bob is currently registered with the Europe server and that the call should be routed through there? For this second problem I don't even have a tentative solution so I'm curious to hear any ideas. 3. SIP Trunks and geography =========================== If Alice is in North America and wants to call a PSTN endpoint in North America I should obviously be using a SIP trunk in North America, since going over the Atlantic twice will add a lot of latency. But what about when Alice want to call a PSTN endpoint in Europe? Is it better to use a SIP endpoint in Europe or in North America? Thanks in advance Oivvio
On Wed, Feb 24, 2016 at 4:23 PM, Oivvio Polite <mylists@polite.se> wrote:
I'm working on a Saas service that will connect WebRTC (with SIP or Verto for signaling) clients to one another and to PSTN. I'm aware of other such services, but this is tailored to a specific niche. I also want WebRTC media to flow through FS, rather than P2P, so that I can record it.
The primary markets are Europe and North America. To keep latency low I need to have servers on both continents. Later on I might want to add more regions. I'm not too worried about high availability or high loads.
The clients can keep track of which FS is closest to them and register with that. But this still leaves me with a couple of questions.
1. Maintaining a single user database =====================================
What's the simplest way of maintaining one joint user database? (User directory in FS parlance).
The first thing that comes to mind is to generate the xml dynamically from a central database, and force as `reloadxml` on all servers every time there's an update. The communication between central database and FS servers could be via RabbitMQ. mod_xml_curl could also be a part of this I guess.
How does that sound? Is there an other simpler way of achiving my goal that I'm not seeing?
You can use mod_xml_curl for this. Every time FS receives a REGISTER message from the user, it would retrieve a piece of XML from your application HTTP service. As these requests need to be answered quite quickly, you would rather install the HTTP server in the same location as FreeSWITCH. Also keep in mind that every call to "user_data" function would trigger an extra HTTP request for the user's XML. The function is quite convenient if you want to get some user-specific parameters from the directory. Then it's up to you how you synchronize the back-end databases. Probably something like https://ipfs.io/ would help.
2. Keeping track of where a user i currently registered =======================================================
Let's say I have a client Alice who's registered with a FS server in North America and a client Bob who has registered wit a FS server in Europe.
Now Alice tries to call Bob. How does the North America server know that Bob is currently registered with the Europe server and that the call should be routed through there?
For this second problem I don't even have a tentative solution so I'm curious to hear any ideas.
Each successful registration generates an event (if I'm not mistaken), and an entry in FreeSWITCH's own database. So, you should be able to retrieve the IP address of the FreeSWITCH server where the user got registered. Alternatively, you may have one Kamailio cluster in one location of the world, acting as a SIP registrar. A 250ms round-trip delay is not so critical for SIP traffic. Alternatively, you can have one FreeSWITCH cluster acting as a SIP registrar and call routing engine in media pass-through mode. Then few other FreeSWITCH servers would work as media gateways in different regions.
3. SIP Trunks and geography ===========================
If Alice is in North America and wants to call a PSTN endpoint in North America I should obviously be using a SIP trunk in North America, since going over the Atlantic twice will add a lot of latency.
But what about when Alice want to call a PSTN endpoint in Europe? Is it better to use a SIP endpoint in Europe or in North America?
This needs testing. I would expect that global VoIP carriers like Voxbone have better control on their bandwidth and transport networks.
On ons, feb 24, 2016 at 04:49:01 +0100, Stanislav Sinyagin wrote:
You can use mod_xml_curl for this. Every time FS receives a REGISTER message from the user, it would retrieve a piece of XML from your application HTTP service. As these requests need to be answered quite quickly, you would rather install the HTTP server in the same location as FreeSWITCH. Also keep in mind that every call to "user_data" function would trigger an extra HTTP request for the user's XML. The function is quite convenient if you want to get some user-specific parameters from the directory.
Then it's up to you how you synchronize the back-end databases. Probably something like https://ipfs.io/ would help.
Each successful registration generates an event (if I'm not mistaken), and an entry in FreeSWITCH's own database. So, you should be able to retrieve the IP address of the FreeSWITCH server where the user got registered.
Alternatively, you may have one Kamailio cluster in one location of the world, acting as a SIP registrar. A 250ms round-trip delay is not so critical for SIP traffic.
Alternatively, you can have one FreeSWITCH cluster acting as a SIP registrar and call routing engine in media pass-through mode. Then few other FreeSWITCH servers would work as media gateways in different regions.
This needs testing. I would expect that global VoIP carriers like Voxbone have better control on their bandwidth and transport networks.
Thanks Stanislav for your suggestions. I think the idea with a Kamailio cluster (or in my case a single box) might be a good fit for my scenario. I'll go read up on that. regards Oivvio
Hi there, I was recently confronted to a similar challenge. In my case, there was an additional use case where Bob could have multiple phones registered simultaneously both on the North American server and the EU server. I strive to involve as little components as possible to avoid unnecessary breaking points. So what I came up with is a very basic but working solution. I modified my dial string so that user/1000@domain would also ring the alternative server in bypass media mode. I also share the same directory files and dial plan files that I host on a centralized storage space. My gateways are set up strategically to route the EU server to the EU POPs and the U.S. server to the NA POPs. That is for my providers who have multiple POPs distributed geographically. With the set up as described here, both servers are active and passive at the same time in the cluster. And it can easily be expanded. To my knowledge, it’s as optimized as it can get. Best, Emrah
On Feb 24, 2016, at 4:23 PM, Oivvio Polite <mylists@polite.se> wrote:
I'm working on a Saas service that will connect WebRTC (with SIP or Verto for signaling) clients to one another and to PSTN. I'm aware of other such services, but this is tailored to a specific niche. I also want WebRTC media to flow through FS, rather than P2P, so that I can record it.
The primary markets are Europe and North America. To keep latency low I need to have servers on both continents. Later on I might want to add more regions. I'm not too worried about high availability or high loads.
The clients can keep track of which FS is closest to them and register with that. But this still leaves me with a couple of questions.
1. Maintaining a single user database =====================================
What's the simplest way of maintaining one joint user database? (User directory in FS parlance).
The first thing that comes to mind is to generate the xml dynamically from a central database, and force as `reloadxml` on all servers every time there's an update. The communication between central database and FS servers could be via RabbitMQ. mod_xml_curl could also be a part of this I guess.
How does that sound? Is there an other simpler way of achiving my goal that I'm not seeing?
2. Keeping track of where a user i currently registered =======================================================
Let's say I have a client Alice who's registered with a FS server in North America and a client Bob who has registered wit a FS server in Europe.
Now Alice tries to call Bob. How does the North America server know that Bob is currently registered with the Europe server and that the call should be routed through there?
For this second problem I don't even have a tentative solution so I'm curious to hear any ideas.
3. SIP Trunks and geography ===========================
If Alice is in North America and wants to call a PSTN endpoint in North America I should obviously be using a SIP trunk in North America, since going over the Atlantic twice will add a lot of latency.
But what about when Alice want to call a PSTN endpoint in Europe? Is it better to use a SIP endpoint in Europe or in North America?
Thanks in advance Oivvio
_________________________________________________________________________ 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 fre, feb 26, 2016 at 12:24:25 +0100, Emrah wrote:
Hi there, I was recently confronted to a similar challenge. In my case, there was an additional use case where Bob could have multiple phones registered simultaneously both on the North American server and the EU server. I strive to involve as little components as possible to avoid unnecessary breaking points. So what I came up with is a very basic but working solution. I modified my dial string so that user/1000@domain would also ring the alternative server in bypass media mode. I also share the same directory files and dial plan files that I host on a centralized storage space. My gateways are set up strategically to route the EU server to the EU POPs and the U.S. server to the NA POPs. That is for my providers who have multiple POPs distributed geographically.
With the set up as described here, both servers are active and passive at the same time in the cluster. And it can easily be expanded. To my knowledge, it’s as optimized as it can get.
Thank you Emrah, I'm reading up on SIP right now to get a better understanding of my options, but your approach sounds interesting. I might be back with more questions. regards, Oivvio
participants (3)
-
Emrah
-
Oivvio Polite
-
Stanislav Sinyagin