9 Oct
2008
9 Oct
'08
12:40 p.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).