Hi!
I'm playing around with the dispatcher module and got it working but ran into some expected problems. Once I load-balance registrations I do run into the situation that I won't be able to know where to redirect an INVITE, i.e. due to aliases. If I use 'touri' to balance registers (let's pretend all registers have usernames not phone numbers) I can spread those (almost) evenly across multiple servers. Once I receive an invite for a username I can use the dispatcher function with the 'touri' hash to properly forward the request. What happens if I INVITE a phone number? A user might have an alias (aka his phone number) but since he registered with his username and all we know in the INVITE is the phone number the hashes might differ.
I'm thinking about looking up the username for a phonenumber utilizing radius (same should work with the DB backend) and then use ds_select_dst() to get the proper SIP server. So in worst case it adds one hop to the whole thing but prevents me from looking up all aliases on the dispatching box.
Any hints to get this done? Looking at the ds_select_dst() implementation I either have to replace the touri in ser routing in order to pass an already modified *sip_msg to it or add another function to lookup a dst for a given clear text string that I should be able to pull from Radius.
Cheers, Hendrik
On May 13, 2005 at 15:17, Hendrik Scholz hendrik.scholz@freenet-ag.de wrote:
Hi!
I'm playing around with the dispatcher module and got it working but ran into some expected problems. Once I load-balance registrations I do run into the situation that I won't be able to know where to redirect an INVITE, i.e. due to aliases. If I use 'touri' to balance registers (let's pretend all registers have usernames not phone numbers) I can spread those (almost) evenly across multiple servers. Once I receive an invite for a username I can use the dispatcher function with the 'touri' hash to properly forward the request. What happens if I INVITE a phone number? A user might have an alias (aka his phone number) but since he registered with his username and all we know in the INVITE is the phone number the hashes might differ.
Balance the REGISTERs after the to uri and the INVITEs after the request uris (ds_select_dst("..", "3"), not documented but present in unstable).
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. An extra round trip might be involved, but if your users don't use aliases very often it might not be an issue.
Andrei
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
Hello,
On 05/17/05 10:22, Hendrik Scholz wrote:
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.
there could be more complex scenarios, for example if you use speed dials then you have kind of aliases per users and must take in consideration the r-uri and from uri. I have started working on a controller system for dispatcher to be able to do the distribution after interaction with some backend. This has to follow the logic of SIP routing policy prior to user location lookup.
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.
One solution would be the usage of a distributed and replicated database system (cluster) to store user profiles. This will allow an increase of queries with less performance penalties but will add some overhead for maintenance.
Daniel
Hendrik
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Hendrik Scholz