Yes, but this depends on your
deployment setup and
policies. Obviously, you cannot support all features with all UAs.
Three-way
conferencing for example. There's no guarantee that REFER and NOTIFYs
work for
three random UAs from different vendors. There are still too many bugs
around.
So, you need to say: If you have this and that UA, you will probably
not get
three-way conferencing. Not much difference from saying: If you have
this
and that UA, you may experience service outages.
There are several ways of creating server-side redundancy and
scalability.
Unfortunately, none are trivial. There are three I have heard have been
successfully used in large-scale setups:
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
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
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())
Each of these three can be combined with either:
a. call-id sticky front-end load balancer (commercial or modified LVS)
b. DNS SRV
c. Linux HA creating two and two peers
Only b) combined with either 1) or 3) or 2+c) can give geographic,
client and
server-side redundancy and scalability.
Scalability and redundancy is sort of a pet project of mine... I would
like to
see a simple, clear-documented and code-supported setup that satisfies
most
common requirements. Currently I'm leaning against #2 (which actually
can be
implemented in vanilla SER 0.9.x, but would be easier and better with
built-in
support). I'm thinking about a setup where two and two servers are
peers to eachother
using Linux HA. Both servers would have one active SER instance and one
inactive ready for taking over for the peer.
I have posted this overview to:
http://www.iptel.org/drupal/failover_redundancy_and_scalability_overview
See also:
http://www.iptel.org/drupal/ser/wishlist
g-)
G.Jacobsen wrote:
Do you happen to know what
percentage of UAs out there
are really "Compliant" UAs ?
My
impression so far regarding SRV DNS
records is that they are theoretically a nice feature but unfortunately
almost
useless since one needs to cater for those non-compliant UAs anyway. I
would
love to be convinced of the contrary.
Can anyone
supply real usage figures
regarding compliant/non-compliant UAS ?
-----Original
Message-----
From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]On Behalf Of samuel
Sent: Donnerstag, 6.
Juli 2006
14:52
To: Ritesh Jalan
Cc: seruser List
Subject: [Bulk] Re:
[Serusers]
Global Failover Server
Look at RFC 3623.
Cofigure two SRV entries in
your DNS, one pointing to the UAS SERver and another to the UK server.
"Compliant" UAs will try to contact the other proxy upon failure of
their current one.
Samuel.
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers