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 ;)