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