[Serusers] forward() and t_relay() differences

Jiri Kuthan jiri at iptel.org
Tue Oct 5 00:31:31 CEST 2004


At 07:07 PM 10/4/2004, Michael Shuler wrote:
>Thanks, I already read that.  What I was concerned about was more of if they
>modified the SIP message differently before being sent.  

I don't think there is a difference in the way these two functions modify
the outoging request. The difference is that the stateful forwarding needs
the reply to visit the same server. (Which should IMHO happen since it 
prints its real IP in Via.)


>For example I have
>a layer 4 switch in front of 2 SER servers which runs a virtual IP of
>198.88.216.84.  The real servers ser0 and ser1 have IP's of 198.88.216.87
>and 198.88.216.89 respectively.  The problem I am having is that when I run
>2 SER seems to get confused when a gateway starts talking to ser0 while a
>client is talking to ser1.  

So what happens is as follows?: a) ser0 forwards a request to a UAS 
b) load balancer rewrites source IP to virtual IP c) UAS sends back to the 
virtual IP (as in RFC3261, source transport address matters more than
content of Via does), d) LB forwards to SER1, e) SER0 times out.

I don't have sufficient information to judge if this is the problem you
are facing, I'm just speculating on what "SER gets confused" means. 
If my wild guess are right, you should make sure that either:
- you use stateless forwarding -- there is then no proxy to time out. however,
  all stateful features will be gone (see the URL I sent previously)
- you make sure that messages from SERs will not be translated. This may 
  be problematic too with replies to natted clients which are expecting
  the replies to come back from the same IP (i.e., the virtual one). 

  To resolve these problem with the scheme you are using you would have 
  to differentiate between replies (to preserve virtual IP) and forward 
  requests (to preserve real IP).  A way to do so would be an additional 
  hop (whose IP will not be translated for request forwarding) but I don't 
  think that one extra box in the chain is a good solution to dealing with load ;)
  Another solution would be to force SER to use a speficic source address for
  resending requests -- this address would not be SER0 and would not be
  mangled by load balancer. There is however no such feature today. (We just
  spoke with Andrei about it for some other reasons recently.)

>Since the layer 4 switch is doing reverse NAT so
>all traffic coming from the 2 ser servers appears as 198.88.216.84 this
>causes a problem when they stick themselves in the Via line as their real IP
>and not as 198.88.216.84.

I don't think that presence of the real IP in Via is exactly the problem. 
On the contrary, the virtual IP in transport may be. If the other entities 
used the real address  then things would be just fine, I guess. I speculate 
that the problem is that the load balancers dispatches different parts of 
transaction to different servers. 

-jiri  




More information about the sr-users mailing list