8 Oct
2008
8 Oct
'08
4:52 p.m.
Hi, I've found a document about SIP load balancing in iptel.org website and I
would like to comment an error I've found in the document.
The document is this:
"Towards Effective SIP load Balancing"
http://www.iptel.org/voipsecurity/doc/14%20-%20Kambourakis%20-%20Towards%20…
Page 7 says:
--------------------
SIP Proxies insert a VIA header in all the incoming SIP requests
So…
In case the LB (Load Balancer) is implemented as another proxy
all SIP responses will pass through that proxy
Request that belong to a specific dialog should not pass through LB
--------------------
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.
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.
Thanks a lot for any comment and best regards.
--
Iñaki Baz Castillo
8 Oct
8 Oct
5:19 p.m.
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,
--
Victor Pascual Ávila
5:41 p.m.
El Miércoles, 8 de Octubre de 2008, Victor Pascual Ávila escribió:
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
Well, however this is completely unfeasible since it would involve modifying
all the SIP devices to be compliant with this non RFC3261 specification.
This is: even if a proxy doesn't add a Via header, the response will come
through the proxy because the destination UAS adds to the top Via:
"received=PROXY_IP;"
It doesn't matter if the top Via is the Via inserted by the UAC (since the
proxy didn't add its own Via). However, the UAS will add the "received"
parameter poiting to the proxy IP, so it will send the reply to the proxy.
Also, it's a completely crazy idea. What to do in the following scenarios?
a) UAC --- (udp) --> LB proxy -- (tcp) --> UAS
b) UAC --- (tcp) --> LB proxy -- (udp) --> UAS
Note that replies for a transaction must use the same network transport, so
it's just impossible that UAS in case a) (who receives the request via TCP
from proxy) to reply UAC directly using UDP.
So in conclusion, I think that the document tells about something obvisouly
not tested, in fact, something illegal with the current SIP specification.
Thanks for your comment. Regards.
--
Iñaki Baz Castillo
5:56 p.m.
On Wed, Oct 8, 2008 at 11:41 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
El Miércoles, 8 de Octubre de 2008, Victor Pascual
Ávila escribió:
I'm afraid I don't agree here: one could use a transparent B2BUA (i.e.
B2BUA used as a Proxy Server). The B2BUA would copy the message from
the inbound leg to the outbound leg and could modify the VIA header--
yes, it is not really elegant but still feasible.
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
Well, however this is completely unfeasible since it would involve modifying
all the SIP devices to be compliant with this non RFC3261 specification. Also, it's a completely crazy idea. What to do in
the following scenarios?
a) UAC --- (udp) --> LB proxy -- (tcp) --> UAS
b) UAC --- (tcp) --> LB proxy -- (udp) --> UAS
Note that replies for a transaction must use the same network transport, so
it's just impossible that UAS in case a) (who receives the request via TCP
from proxy) to reply UAC directly using UDP.
I think we already had this discussion in sip-implementors. Anyway, in
this scenario, I consider the LB to act as a simple dispatcher and not
as a "transport converter". But you are right.
Thanks for your comments,
--
Victor Pascual Ávila
13 Oct
13 Oct
4: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,
14 Oct
14 Oct
3:52 a.m.
2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
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.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261.
This is, it's not enough if the vendor customizes the LB, it also
needs to modify the SIP devices after the LB. If not, the
proxies/gateways behind the LB will always reply to the source IP (the
IP of LB) regardless of the content/existance of a Via added (or not)
by LB.
An example: if a vendor just controls the LB and use gateways of
different carriers, the LB will always receive the responses to the
initial INVITE transaction (except if the gateways are not SIP
compliant when sending a response).
I think this is very clear in points 18.2.1 and 18.2.2, am I wrong?
Thanks a lot for your comments.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:14 p.m.
Iñaki Baz Castillo wrote:
2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something.
Regards,
Martin
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.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261.
4:33 p.m.
El Martes, 14 de Octubre de 2008, Martin Hoffmann escribió:
Iñaki Baz Castillo wrote:
Thanks for your comment. Please let me understand what you mean:
" the trick is to give them all the same IP and have the balancers work one
layer below"
Do you mean having various LB proxies all of them with same IP? If it, them
all the proxies behind the LB's will always see the same source IP, and will
reply to that IP, so the responses will arrive, at least, to one LB, am I
wrong?
Anyway, I don't understand the purpose and advantages of this method. If I
understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
- proxy1 sees 1.1.1.1 as source IP so add "received=1.1.1.1" to top Via (the
top Via can be Via added by LB1 or the Via added by UA if LB's don't add
Via).
- proxy1 replies to 1.1.1.1.
- Since that IP is shared by all the LB's the response arrives to LB3.
I suppose I didn't understant well since I see no benefict in this scenario.
Thanks a lot for your comment.
--
Iñaki Baz Castillo
2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something. 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.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261.
6 p.m.
Iñaki Baz Castillo wrote:
El Martes, 14 de Octubre de 2008, Martin Hoffmann
escribió:
Er, no. You have one load balancer (or, if one isn't enough, a cascade
of them) and a set of proxies which all use the same address. From an IP
perspective, the balancers are routers, ie., they don't change IP
addresses or ports in the packets. All they do is pick one of the
proxies and forward the packet there. The proxies are set up in such a
way that they believe to serve the common IP (an alias on loopback,
usually). Then they just do their usual processing.
Iñaki Baz Castillo wrote:
Thanks for your comment. Please let me understand what you mean:
" the trick is to give them all the same IP and have the balancers work one
layer below"
Do you mean having various LB proxies all of them with same IP? If it, them
all the proxies behind the LB's will always see the same source IP, and will
reply to that IP, so the responses will arrive, at least, to one LB, am I
wrong? 2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something. 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.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261. Anyway, I don't understand the purpose and
advantages of this method. If I
understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
Forget about LB2 and LB3 for now. There is a setup where you can have
them, but then you need yet another, even dumber balancer in front.
The LB has 1.1.1.1, the proxies have 1.1.1.1 as aliases. So:
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
Note: It does not change the IP fragment; ie., IP header, UDP or TCP
header and SIP message remain untouched.
- proxy1 sees 1.1.1.1 as source IP so add
"received=1.1.1.1" to top Via (the
top Via can be Via added by LB1 or the Via added by UA if LB's don't add
Via).
- proxy1 sees UA's IP and adds that to the top Via which is UA's Via.
- proxy1 replies to 1.1.1.1.
- proxy1 replies to UA's IP. You can set this up that this either goes
through the LB or directly without the LB seeing the reply. Which of
these depends most likely on how smart your balancer is.
I suppose I didn't understant well since I see no
benefict in this scenario.
The benefit is that you can use regular proxies that are unaware of the
setup. To a certain degree at least -- they do have to share the
location service, of course.
This setup is the easiest to get a redundant and reliable setup if you
use NAT handling nathelper style. In that case, the proxies need to know
the UA's IP and port.
Additionally, you get failover for UDP behind NAT. If proxy1, which was
processing requests from UA1, fails, proxy2 can take over and still talk
to the box behind NAT.
The whole thing, obviously, doesn't work for TCP, but that is an
entirely different can of worms.
Regards,
Martin
6:12 p.m.
El Miércoles, 15 de Octubre de 2008, Martin Hoffmann escribió:
Thanks a lot for so great explanation.
So in conclusion we are speaking about an IP based load balancer, and not
about a SIP load balancer. Also we are playing with IP level exotic technics
(various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
Again thanks a lot.
--
Iñaki Baz Castillo
" the
trick is to give them all the same IP and have the balancers work
one layer below"
Do you mean having various LB proxies all of them with same IP? If it,
them all the proxies behind the LB's will always see the same source IP,
and will reply to that IP, so the responses will arrive, at least, to one
LB, am I wrong?
Er, no. You have one load balancer (or, if one isn't enough, a cascade
of them) and a set of proxies which all use the same address. From an IP
perspective, the balancers are routers, ie., they don't change IP
addresses or ports in the packets. All they do is pick one of the
proxies and forward the packet there. The proxies are set up in such a
way that they believe to serve the common IP (an alias on loopback,
usually). Then they just do their usual processing.
Anyway, I don't understand the purpose and
advantages of this method. If
I understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
Forget about LB2 and LB3 for now. There is a setup where you can have
them, but then you need yet another, even dumber balancer in front.
The LB has 1.1.1.1, the proxies have 1.1.1.1 as aliases. So:
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
Note: It does not change the IP fragment; ie., IP header, UDP or TCP
header and SIP message remain untouched.
- proxy1 sees 1.1.1.1 as source IP so add
"received=1.1.1.1" to top Via
(the top Via can be Via added by LB1 or the Via added by UA if LB's don't
add Via).
- proxy1 sees UA's IP and adds that to the top Via which is UA's Via.
- proxy1 replies to 1.1.1.1.
- proxy1 replies to UA's IP. You can set this up that this either goes
through the LB or directly without the LB seeing the reply. Which of
these depends most likely on how smart your balancer is.
I suppose I didn't understant well since I
see no benefict in this
scenario.
The benefit is that you can use regular proxies that are unaware of the
setup. To a certain degree at least -- they do have to share the
location service, of course.
This setup is the easiest to get a redundant and reliable setup if you
use NAT handling nathelper style. In that case, the proxies need to know
the UA's IP and port.
Additionally, you get failover for UDP behind NAT. If proxy1, which was
processing requests from UA1, fails, proxy2 can take over and still talk
to the box behind NAT.
The whole thing, obviously, doesn't work for TCP, but that is an
entirely different can of worms.
15 Oct
15 Oct
2:13 a.m.
Iñaki Baz Castillo wrote:
So in conclusion we are speaking about an IP based load balancer, and not
about a SIP load balancer. Also we are playing with IP level exotic technics
(various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
The load balancer does need to be aware of SIP. For this to work, it
needs to send all requests for a transaction to the same proxy. If the
proxies are session-aware, it even needs to send all requests for a
dialog to the same proxy.
But you are right, this device is not a SIP element. Which in a way is,
why I like it ;)
Regards,
Martin
4:13 a.m.
2008/10/15 Martin Hoffmann <hn(a)nvnc.de>de>:
Iñaki Baz Castillo wrote:
Ok, completely understood now :)
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
So in conclusion we are speaking about an IP based load balancer, and not
about a SIP load balancer. Also we are playing with IP level exotic technics
(various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
The load balancer does need to be aware of SIP. For this to work, it
needs to send all requests for a transaction to the same proxy. If the
proxies are session-aware, it even needs to send all requests for a
dialog to the same proxy.
But you are right, this device is not a SIP element. Which in a way is,
why I like it ;)
17 Oct
17 Oct
3:10 p.m.
Martin Hoffmann wrote:
Iñaki Baz Castillo wrote:
I don't thinkt that's accurate. For many load-distribution schemes
it needs to parse SIP to make the right routing decision.
So in conclusion we are speaking about an IP
based load balancer, and not
about a SIP load balancer. Also we are playing with IP level exotic technics
(various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
The load balancer does need to be aware of SIP. For this to work, it
needs to send all requests for a transaction to the same proxy. If the
proxies are session-aware, it even needs to send all requests for a
dialog to the same proxy.
I think there is some wording confusion here? What you are
describing is SIP awaraness. (otherwise you can't really send
the same dialog messages to the same proxy)
-jiri
But you are right, this device is not a SIP element. Which in a way is,
why I like it ;)
Regards,
Martin
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:12 p.m.
Jiri Kuthan wrote:
Martin Hoffmann wrote:
Sure. You might want to right my above statement again. It says "does
need", not "does not". ;)
Best regards,
Martin
Iñaki Baz Castillo wrote:
I don't thinkt that's accurate. For many load-distribution schemes
it needs to parse SIP to make the right routing decision.
So in conclusion we are speaking about an IP
based load balancer, and
not about a SIP load balancer. Also we are playing with IP level
exotic technics (various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
The load balancer does need to be aware of SIP. For this to work, it
needs to send all requests for a transaction to the same proxy. If the
proxies are session-aware, it even needs to send all requests for a
dialog to the same proxy.
I think there is some wording confusion here? What you are
describing is SIP awaraness. (otherwise you can't really send
the same dialog messages to the same proxy)
5:19 p.m.
Martin Hoffmann wrote:
Jiri Kuthan wrote:
oh gee, I that I was good in fast scanning :-)
Thanks for the notice, we are in perfect agreement and sorry for the fuss.
-jiri
Martin Hoffmann wrote:
Sure. You might want to right my above statement again. It says "does
need", not "does not". ;) Iñaki Baz Castillo wrote:
I don't thinkt that's accurate. For
many load-distribution schemes
it needs to parse SIP to make the right routing decision.
So in conclusion we are speaking about an IP
based load balancer, and
not about a SIP load balancer. Also we are playing with IP level
exotic technics (various hosts sharing the same IP).
So the above scenario would be valid for any UDP protocol, not just SIP.
The load
balancer does need to be aware of SIP. For this to work, it
needs to send all requests for a transaction to the same proxy. If the
proxies are session-aware, it even needs to send all requests for a
dialog to the same proxy.
I think there is some wording confusion here? What you
are
describing is SIP awaraness. (otherwise you can't really send
the same dialog messages to the same proxy)
Best regards,
Martin
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:07 p.m.
we mean a load-balancer (Which is roughly a crippled proxy), which has
the same IP address as the regular proxy servers behind it.
-jiri
Iñaki Baz Castillo wrote:
El Martes, 14 de Octubre de 2008, Martin Hoffmann
escribió:
Iñaki Baz Castillo wrote:
Thanks for your comment. Please let me understand what you mean:
" the trick is to give them all the same IP and have the balancers work one
layer below"
Do you mean having various LB proxies all of them with same IP? If it, them
all the proxies behind the LB's will always see the same source IP, and will
reply to that IP, so the responses will arrive, at least, to one LB, am I
wrong?
Anyway, I don't understand the purpose and advantages of this method. If I
understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
- proxy1 sees 1.1.1.1 as source IP so add "received=1.1.1.1" to top Via (the
top Via can be Via added by LB1 or the Via added by UA if LB's don't add
Via).
- proxy1 replies to 1.1.1.1.
- Since that IP is shared by all the LB's the response arrives to LB3.
I suppose I didn't understant well since I see no benefict in this scenario.
Thanks a lot for your comment.
2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they
are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something. 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.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261. 
9 Oct
9 Oct
5:25 a.m.
Hola Iñaki,
Hi, I've found a document about SIP load balancing
in iptel.org
website and I
would like to comment an error I've found in the document.
The document is this:
"Towards Effective SIP load Balancing"
http://www.iptel.org/voipsecurity/doc/14%20-%20Kambourakis%20-%20Towards%20…
Page 7 says:
--------------------
SIP Proxies insert a VIA header in all the incoming SIP requests
So…
In case the LB (Load Balancer) is implemented as another proxy
all SIP responses will pass through that proxy
Request that belong to a specific dialog should not pass through LB
--------------------
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.
How many things from RFC3261 can be "avoided" in the real world? :)
Keeping NAT outside of the scope, you can have a load balancer in
"transparent" mode (do not add VIA or Record-Route) so the UAC send
the requests to the LB, the LB to the proxy and the proxy send back
the response directly to the UAC. What's wrong on this?.
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.
Ok, that can be done only for UDP.
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).
Usually, the LB will proxy/resend the requests to a proxy and the
proxy to the UAS so the UAS will reply to the proxy, not the LB (but
you can find so many different scenarios on this topic that is really
difficult to have a clear idea).
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.
As Víctor said, this presentation is done by researchers using the
results of a research project, which by the way i know very well :)
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
5:40 a.m.
2008/10/9 Jesus Rodriguez <jesusr(a)voztele.com>om>:
No no, that's incorrect, the response will always be sent from the
proxy to the LB, even if the transport is UDP and there is no Via
added by the LB. Let's explain it with an example:
UA ----> LB -----> PROXY
The flow:
# UA ---> LB
INVITE sip:xxxxx SIP/2.0
Via: SIP/2.0/UDP UAC_IP:5060
# LB ---> PROXY (LB doesn't add Via)
INVITE sip:xxxxx SIP/2.0
Via: SIP/2.0/UDP UAC_IP:5060
In this point the PROXY receives the request and examinates the top
Via (it's in fact the Via set by the UAC since LB didn't add its own
via. So PROXY checks the IP in Via "sent-by" (this is: UAC_IP). UAC_IP
doesn't match the *real* source IP (this is: LB_IP) so PROXY's
transport layer adds to the top Via:
Via: SIP/2.0/UDP UAC_IP:5060;received=LB_IP
So when PROXY sends a reply it will reply to "received" parameter,
this is, to LB_IP.
18.2.1 Receiving Requests
When the server transport receives a request over any transport, it
MUST examine the value of the "sent-by" parameter in the top Via
header field value. If the host portion of the "sent-by" parameter
contains a domain name, or if it contains an IP address that differs
from the packet source address, the server MUST add a "received"
parameter to that Via header field value. This parameter MUST
contain the source address from which the packet was received. This
is to assist the server transport layer in sending the response,
since it must be sent to the source IP address from which the request
came.
18.2.2 Sending Responses
o Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter
So, the response from PROXY will be like:
# PROXY ---> LB
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP uac_ip:5060
This goes again through the LB.
No, it can't be done neither in TCP or UDP ;)
This is unfeasible from my point of view :)
If a UAS/proxy replies to the IP indicated in the top Via instead of
replying to the real source IP, then taht SIP device is not SIP
compliant.
Thanks for your comments ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
How many things from RFC3261 can be "avoided" in the real world? :)
Keeping NAT outside of the scope, you can have a load balancer in
"transparent" mode (do not add VIA or Record-Route) so the UAC send the
requests to the LB, the LB to the proxy and the proxy send back the response
directly to the UAC. What's wrong on this?. 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.
Ok, that can be done only for UDP. 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).
Usually, the LB will proxy/resend the requests to a proxy and the proxy to
the UAS so the UAS will reply to the proxy, not the LB (but you can find so
many different scenarios on this topic that is really difficult to have a
clear idea).
8:36 a.m.
On Thu, Oct 9, 2008 at 11:25 AM, Jesus Rodriguez <jesusr(a)voztele.com> wrote:
Keeping NAT outside of the scope, you can have a load
balancer in
"transparent" mode (do not add VIA or Record-Route) so the UAC send
the requests to the LB, the LB to the proxy and the proxy send back
the response directly to the UAC. What's wrong on this?.
The issue here is the following: if the 'sent-by' contains an IP that
differs from the real source address, a 'received' is inserted and
used when sending back the response. Hence, the LB receives the
response anyway :-)
Cheers,
--
Victor Pascual Ávila
5722
days inactive
5731
days old
18 comments
5 participants
participants (5)
-
Iñaki Baz Castillo -
Jesus Rodriguez -
Jiri Kuthan -
Martin Hoffmann -
Victor Pascual Ávila