There are several things you must consider and there are many alternatives.
Here is a list of issues.
1. Reliability and scalability issues
-----------
Scenario: Tens of thousands or hundreds of thousands of users require a reliable and scalable infrastructure
Goal: Find a good reference scenario for building a reliable and scalable infrastructure of seri [1] servers.
Problems: Everybody tries to solve this their own way and most keep their solutions as a secret because it is a competitive advantage not to tell anybody.
Solution: Use RADIUSi [2] (and possibly LDAPi [3] back-ends) for everything but
usrloc is one solution. Or use usrloc-cl to keep usrloc in a mysql cluster. Do you have one server center with
load balancing or geographically-distributed server centers? It will influence your needs.
2. Usrloc replication across standalone ser servers.
------------
Scenario: Independent servers with independent databases run either with some sort of load balancing and/or DNS SRV.
Goal: Make sure that all ser servers have updated usrloc information, so each can handle any SIP message.
Problems: Distribute REGISTER messages to all servers; Make sure that server unavailability does not corrupt the usrloc DB state
Solution: t_replicate: a) uses SIP messages b) uses a best-effort algorithm c) can be used between several servers, but when you introduce a new server, you need to change each server's ser.cfg. t_replicate does not have guaranteed mode of replication. Alternatively you can use the mysql cluster and usrloc-cl.
3. Network-based provisioning of new users, aliases, etc
------------
Scenario: One server need to be provisioned from a web server or process running on a remote server
Goal: Allow ser to receive TCP/IP based provisioning messages
SERi [4] 0.10.x (headi [5]) has a new management interface with (among other) XMLRPC interface.
4. Replication of user database, aliases, etc across standalone ser servers.
------------
Scenario: Independent servers with independent databases run either with some sort of load balancing or DNS SRV and subscriber information is stored in sql tables
Goal: Make sure that each server recognizes all subscribers, aliases, etc
Problems: Make sure that all servers have updated database tables
Solution: RADIUS/LDAP solutions do not need to do this as RADIUS servers, LDAP replication etc take care of both reliability and scalability.
With SQL-based scenarios, three are two solutions:
a) Rely on sql-based replication
b) Implement provisioning systems so that each ser server is updated through
the TCP/IP-based FIFO
5. Handling far-end NATi [6] traversal
------------
Scenario: NATed clients must be assumed are behind a symmetric NAT and only the registration server will be able to send network traffic to the user agent (as the NAT will only open incoming traffic to IP addresses/ports where outgoing traffic has been registered)
Goal: Make sure the user agent can be reached regardless of which server originally received the INVITE (or other message destined for UA) or the registration server went down
Solution: Make sure you don't have NATed clients. Or make sure all messages to UA go through the registration server. Each server needs to be able to look up the registration server of a registered contac. SER currently has no good way of doing this, but it can be implemented in ser.cfg. OpenSER >0.10 has Path functionality implemented in usrloc (use db_mode). Anyway, if the server goes down, the UA cannot be reached.
Only solution is a) make sure the UA detects a server failure and reREGISTER with another (using DNS SRV for failover) or create an active-passive solution using some network-level protocol/solution for taking over the IP address of the failed server