Samuel,

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 ?

TIA

Gerry

-----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.

2006/7/5, Ritesh Jalan ritesh.j@net4.in: Hi All

Pls. guide me how can we implement failover on SIP Server located globally, Like one server in USA another in UK.

Ritesh Jalan Mobile: 91-9818616329 MSN: ritesh_jalan@hotmail.com

_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hi

DNS SRV is a Load Balance system, How it can be a fail over.

Only for call initialisation a UAC will search for DNS SRV records, but after the the call starts, if First server (From which call is beaing initiated) goes down then thebye message will not go to second server

net4.in Ritesh Jalan Senior Engineer - Business Solution Net4India Ltd. D-25 Sector - 3 Noida - 201301 India Tel: 91-120-5323500 Mobile: 91-9818616329 Fax: 91-120-5323520 MSN: ritesh_jalan@hotmail.com URL: http://www.net4.in

----- Original Message ----- From: samuel To: G. Jacobsen Cc: seruser List Sent: Friday, July 07, 2006 2:00 PM Subject: Re: [Serusers] Global Failover Server

Following lines are an extract from the SIPit preliminary report regarding supported DNS features in current implementations:

160 people from 16 countries attended SIPit 18 with 73 different SIP implementations:

Full 3263 25 3263 (no naptr,SRV on) 13 A only 22 IP only (no DNS) 9

Which gives a percentage of 38/73 supporting SRV records, so more or less half of the implementations supports this type of load balancing.

This value should be used with care because implementations include both UAs and proxies/redirect/* servers. I can also say that a higher percentage of desktop SIP phones supports DNS SRVs, but since it's just my impression from the ones I have touched I can not assure nor give a percentage...

Hope it helps,

Samuel.

2006/7/6, G.Jacobsen < g_jacobsen@yahoo.co.uk >: Samuel,

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 ?

TIA

Gerry

-----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.

2006/7/5, Ritesh Jalan ritesh.j@net4.in: Hi All

Pls. guide me how can we implement failover on SIP Server located globally, Like one server in USA another in UK.

Ritesh Jalan Mobile: 91-9818616329 MSN: ritesh_jalan@hotmail.com

_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

------------------------------------------------------------------------------

_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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:

Samuel,

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 ?

TIA

Gerry

-----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.

2006/7/5, Ritesh Jalan <ritesh.j@net4.in <mailto:ritesh.j@net4.in>>:

    Hi All

    Pls. guide me how can we implement failover on SIP Server
    located globally, Like one server in USA another in UK.



    Ritesh Jalan
    Mobile: 91-9818616329
    MSN: ritesh_jalan@hotmail.com <mailto:ritesh_jalan@hotmail.com>

    _______________________________________________
    Serusers mailing list
    Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org>
    http://lists.iptel.org/mailman/listinfo/serusers

---

---

Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

I'm not sure if I understand your scenario. A stateless proxy would need a peer for hardware failures and "a bunch of servers" sounds expensive and I'm not sure what you gain. Could you provide some details? (The dispatcher module can be used for stateless proxy; using a SER for load balancing. You can also use 302 REFER to divide load across registrars. However, regardless how you do it, you need some routing between SER servers to make sure that messages to a UA go through the SER server the UA contacted as first hop). g-)

Edson wrote:

Correct me if I'm wrong, but since SER is capable to handle tens or hundreds of thousands of SIP messages per second, why not cut this number down to thousands and compose a HA and Redundancy solution combining some stateless proxy in front of a bunch of servers using cache based (like in 2 -- MySQL cluster, p.ex.)? The stateless proxy could have some local replication (two peers: one active and one inactive) sharing a common IP (registered on SRV) for HA, and the geographic issue could be achieved with a complete replication of this set.

The down-point in this approach is that in a geographic switch there is no guarantee that the clusters would be totally consistent between the two sets. The fall can (and Murphy says it will) occur just before, or in the middle, a big replication DB operation. But if You can accomplish that than I see this as a good solution.

Comments?

Edson.

---

*From:* serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] *On Behalf Of *Greger V. Teigre *Sent:* sexta-feira, 7 de julho de 2006 06:49 *To:* G.Jacobsen *Cc:* seruser List *Subject:* Re: [Serusers] Global Failover Server

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:

Samuel,

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 ?

TIA

Gerry

-----Original Message-----
*From:* serusers-bounces@lists.iptel.org
<mailto: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.

2006/7/5, Ritesh Jalan <ritesh.j@net4.in <mailto:ritesh.j@net4.in>>:

Hi All



Pls. guide me how can we implement failover on SIP Server located
globally, Like one server in USA another in UK.







Ritesh Jalan
Mobile: 91-9818616329
MSN: ritesh_jalan@hotmail.com <mailto:ritesh_jalan@hotmail.com>


_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers

---

---

Serusers mailing list Serusers@lists.iptel.org mailto:Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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-)