[Freeswitch-users] Joining several FS servers in different regions

[Stanislav Sinyagin]

On Wed, Feb 24, 2016 at 4:23 PM, Oivvio Polite <mylists at 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.