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%20E...
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.
Hi Iñaki, thanks for your comments.
On Wed, Oct 8, 2008 at 10:52 PM, Iñaki Baz Castillo ibc@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.
- 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).
- 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,
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.
On Wed, Oct 8, 2008 at 11:41 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
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.
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.
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,
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@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.
- 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).
- 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,
2008/10/13 Jiri Kuthan jiri@iptel.org:
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 wrote:
2008/10/13 Jiri Kuthan jiri@iptel.org:
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.
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
El Martes, 14 de Octubre de 2008, Martin Hoffmann escribió:
Iñaki Baz Castillo wrote:
2008/10/13 Jiri Kuthan jiri@iptel.org:
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.
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.
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 wrote:
El Martes, 14 de Octubre de 2008, Martin Hoffmann escribió:
Iñaki Baz Castillo wrote:
2008/10/13 Jiri Kuthan jiri@iptel.org:
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.
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.
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?
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.
Regards, Martin
El Miércoles, 15 de Octubre de 2008, Martin Hoffmann escribió:
" 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.
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 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
2008/10/15 Martin Hoffmann hn@nvnc.de:
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 ;)
Ok, completely understood now :) Thanks.
Martin Hoffmann wrote:
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.
I don't thinkt that's accurate. For many load-distribution schemes it needs to parse SIP to make the right routing decision.
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Jiri Kuthan wrote:
Martin Hoffmann wrote:
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.
I don't thinkt that's accurate. For many load-distribution schemes it needs to parse SIP to make the right routing decision.
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)
Sure. You might want to right my above statement again. It says "does need", not "does not". ;)
Best regards, Martin
Martin Hoffmann wrote:
Jiri Kuthan wrote:
Martin Hoffmann wrote:
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.
I don't thinkt that's accurate. For many load-distribution schemes it needs to parse SIP to make the right routing decision.
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)
Sure. You might want to right my above statement again. It says "does need", not "does not". ;)
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
Best regards, Martin _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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:
2008/10/13 Jiri Kuthan jiri@iptel.org:
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.
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.
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.
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%20E...
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?.
- 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).
- 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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
2008/10/9 Jesus Rodriguez jesusr@voztele.com:
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?.
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.
- 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).
- 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.
No, it can't be done neither in TCP or 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).
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 ;)
On Thu, Oct 9, 2008 at 11:25 AM, Jesus Rodriguez jesusr@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,
-
Iñaki Baz Castillo -
Jesus Rodriguez -
Jiri Kuthan -
Martin Hoffmann -
Victor Pascual Ávila