[Serusers] Dispatcher questions & suggestion

Erik Versaevel Infopact Netwerkdiensten BV erik at infopact.nl
Wed Dec 29 10:38:36 CET 2004


Hello all,

I'm currently fidling around with the dispatcher module, and it sort of 
works, incomming packets are distributed by callid to the servers listed 
in the file, so far so good, however i'm having troubles in getting the 
replies back to the users.
The users are behind NAT so the request needs to be send back to the 
same port the request came from and from the same IP/Port the request 
was send to, but when the dispatcher sends the request back to the 
client it allways sends it to port 5060, which isn't open so the clients 
behind the NAT never get a response.

A solution would be a sort of 'direct routing' in which the ser machines 
behind the dispatcher have multiple IP adresses and allways send packets 
back to the original UA using the IP of the dispatcher, is that 
possible? This would allso mean that traffic back to the UA's wouldn't 
have to go trought the dispatcher, thus allowing for better performance. 
(This is the way that ldirector works for loadbalancing HTTP). However, 
ser currently sends its replies either to the first VIA or to the IP the 
request was recieved from, that would mean the director would have to 
use the IP of the UA when forwarding to a ser host.

I'm allso concerned with NAT traversal while using the dispatcher 
module, should the dispatching host take care of NAT? since the ser's 
behind the dispatching machine would send their ping to the dispatching 
machine instead of the real NAT host, but that would seriously impact 
the dispatching machine since it would need userloc to store NAT status.

As a functional request, would it be possible for the dispatch module to 
first send an OPTIONS packet to the selected host/port to see if it's 
up? (and if not send the request to another host and execute a shell 
script for example to warn the administrator for a non responsive node)

Kind regards and keep up the good work,

E. Versaevel




More information about the sr-users mailing list