Re: [Sipping] Server Load Balancer Integration?

Steve Gardell wrote:
> 
> Thanks Henning!
> 
> I take this as an analysis of why this SLB
> sort of technology sometimes isn't always necessary.
> I'd love to convince myself that this is generally
> true since the solution you propose is ever so
> much easier and cheaper. We need to consider SIP
> entities that aren't quite as "easy"
> as a stateless proxy. For example, an array of
> media servers or 3'rd party call control entities
> in the fashion of draft-rosenberg-sip-3pcc-02.txt.
> 
> Let me test whether I understand what you propose: Implement
> two stateless proxies (for redundancy). Access to these
> is via DNS/SRV. Each stateless proxy directs calls
> "intelligently" to the stateful entities (UAS, B2BUA, etc.)
> This seems to work fine for load balancing (which was
> of course the thread title...) Hmmm, do we really need
> the stateless proxies for this? - I guess that depends on
> whether the simple DNS mechanisms are deemed adequate.
> 
> SLB's in general also provide Failover/Redundancy support, which
> I must admit, is at least as big a concern to me. I
> believe that this DNS/SRV approach doesn't support mid-call
> failures since I can't expect SIP UAC's or proxies to
> re-try DNS during a call (can I?). I believe that the
> SLB approach would support mid-call failures if state is
> replicated across end-points.
> 

This only matters if proxies are call (not just transaction) stateful.
Since things in the network that keep state are a source of complexity
and failures, SIP tried hard not to introduce such entities. Except
possibly for firewall controllers, I have a hard time seeing the need
for proxies that need to be around "in person" to keep up a call.
Generally, why would you need mid-call signaling to keep a call up? This
isn't SS7... (If you're willing to replicate state across a set of
servers, it doesn't matter which server is visited mid-call, so even
there, SRV-style solutions work.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP