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
Show replies by date