13 Oct
2008
13 Oct
'08
11:49 p.m.
The thing here is that actually a load-balancer vendor is free to build
stuff his way -- he is not compelled to build a proxy or B2BUA and go to
some certification authority, he is supposed to build something that
load-balances well. I'm intimately aware of some load-balancers that are
close to being a kind of "transparent proxy", which is just fine: it
doesn't put itself in signaling and it handles routing by state table.
-jiri
Victor Pascual Ávila wrote:
Hi Iñaki,
thanks for your comments.
On Wed, Oct 8, 2008 at 10:52 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
This is completely true, but next page (8) says:
--------------------
Transparency for responses
Prevent Load Balancer from inserting a VIA header
E.g. in SER utilizing the SEND core command
Modify the SIP's Proxy core to ignore the VIA-header
added by the Load Balancer
-------------------
There is an important error that unfortunatelly I've realized it's very
common. Section 18.2.2 of RFC 3261 says clearly that the responses are
*always* sent through the same nodes the request came from. So the response
should always traverse the load balancer.
1) Load balancer --- (SIP UDP) ---> UAS
In this case the UAS would always reply to the *real* source IP (if this is
different of the Via "sent-by" then UAS adds "received" parameter and
replies
there).
2) Load balancer --- (SIP TCP/SCTP) ---> UAS
By definition a UAS must reply using the incoming TCP connection.
I agree this should be the proper behavior as per RFC3261.
So it's extrange for me that a document about
SIP load balancing tries to
offer solutions that are not SIP compliant and also unfeasible (UAS will
always reply to the real source IP regardless of the Via content).
Since the document proposes SER based solutions (using "SEND" command) I'd
just like to confirm if I'm completely right, or maybe it's common those not
SIP compliant methods by some vendors in order to provide a load balancing
solution.
Actually I understand this document to be part of a research project.
I don't believe that ignoring a VIA header or preventing a SIP entity
from inserting a VIA header is a common praxis in the industry. But as
you might imagine, research is research and prototypes are prototypes
:-)
Thanks,