TO ALL!!!
The link below describes three alternatives. A forth, quite recently discussed on this list and serdev, should also be there: using dispatcher on a stateless SER. If there are somebody who uses such a setup, feel free to add it to the page!
Also, Nick and others: If the descriptions are a bit short, misleading, or if something misses, feel free to add/change.

The rest is inline.

Nick Hoffman wrote: 
Hi Greger. I have a few questions about the three solutions you've proposed 
in "Failover/redundancy and Scalability Overview" 
(http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview).

  
1. Cacheless usrloc with a mysql cluster as back-end DB combined with
implementation of the Path header (to find the registrar of a given UA).
No replication across servers
    

By "cacheless usrloc", do you mean db_mode(1) for the "usrloc" module?
No, I mean the usrloc-cl module found in experimental (for 0.9.x). Nothing is stored in memory, all queries are thrown at the db.
What do you mean by "implementation of the Path header (to find the 
registrar of a given UA)"?

Would [registration?] replication across servers not be needed because of 
db_mode(1)?
Yep.
With this setup, can any UA register with any SER?
Yep, the path header will be stored in the DB and the info there would be used for routing.

  

    
2.  Multiple SER registrars, each with a standalone, local DB and where
SIP is used to replicate registrations.  By storing replications from a
peer in a location_peer1 table and then lookup using this table, you can
route INVITEs to the registrar being able to pinhole the NAT in front of
a given UA
    

  

  

If each SER has its own local DB, UAs have to register with a specific SER 
rather than any of the available SERs, right?
  



No, each peer is responsible for replicating to the other peers.



  
I'm afraid I don't understand the last sentence you wrote above. Would you 
mind explaining it in a bit more detail please?
  



The UA #1 registers with SER A and call comes from UA #2 on SER B.  SER
B can try to contact UA #1 directly, but if the UA is behind a
symmetric NAT, the NAT will not allow incoming messages from other ip
addresses than SER A. Thus, SER B should send the message to SER A, so
that SER A can contact UA #1 by traversing the NAT.



  

  

    
3. Each SER is connected to a single mysql DB cluster as in #1, but
since usrloc also is in memory (cacheless usrloc is not used),
replication is done between the SER servers and save_memory() is used to
store the location only in memory (the registrar updates the cluster
with save())
    

  

  

With this setup, can any UA register with any SER?
  



Yep.



  

    
Each of these three can be combined with either:
a. call-id sticky front-end load balancer (commercial or modified LVS)
    

  

  

What is that?
  



What is what? LVS, you mean?  http://www.linuxvirtualserver.org/



  
  

  

    
c. Linux HA creating two and two peers
    

  

  

What is "two and two peers"?
  





Linux HA is Linux High Availability; two servers monitor each other and
if one goes down, the other will take the IP address configured on the
HA cluster. VRRP can also be used in combination or standalone.

http://www.linux-ha.org/

http://www.ietf.org/html.charters/vrrp-charter.html

http://www.keepalived.org/



The idea is that each physical server can either run virtualization
(xen/vmware) or use multiple interfaces (one for an active SER and one
for a standby SER), thus enabling each physical server to both be
active and a backup for another SER. Of course, you need to make sure
that one server can take the load of both in case one fails...

g-)