[Serusers] About a SIP load balancing document involving SER

[Jiri Kuthan]

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 at 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,