Hi!
Andrei Pelinescu-Onciul wrote:
Balance the REGISTERs after the to uri and the INVITEs
after the request
uris (ds_select_dst("..", "3"), not documented but present in
unstable).
I already found those when backporting the dispatcher module to 0.8.14.
If the uri is an alias (e.g.
lookup("aliases") returns true) balance the
message again after the request uri/send it back to the load balancer.
Let's pretend this:
I register UA 'a' and it get's balanced to SER backend 'Y'.
I register UA 'b' and it get's balanced to SER backend 'Z'.
Now 'a' also has an alias (a phone number) of '123456'.
If I call 'a' the load balancer takes care of everything and backend 'Y'
can process the call.
Now '123456' get's balanced to 'Z' due to the hash algorithm.
Since the initial register of 'a' was on 'Y' the 'Z' backend
doesn't
know anything about the alias.
Or am I getting something wrong here?
My idea was to get the alias from Radius instead of the incomplete
usrloc DB. The additional hop involved is needed to push the
request to the backend ('Y') where 'a' initially registered on.
An extra round trip might be involved, but if your
users don't use
aliases very often it might not be an issue.
We do have many aliases and all calls from the PSTN have to be
looked up but I think it's easier to do the lookup on the backend
rather than having a usrloc DB on the load balancer.
Hendrik
--
freenet Cityline GmbH, Hamburger Chaussee 2-4, 24114 Kiel, Germany
Phone: +49 (0)431 9020552, Fax: +49 (0)431 9020559
Internet:
http://www.freenet.de, eMail: hendrik.scholz(a)freenet-ag.de