After many many fruitless hours spent on trying to get OpenSER to work with DNS 
SRV records (I made a post to the group earlier today on this), I stumbled 
across the dispatcher module, and have been trying to get it to work instead.
 
The module was designed to load balance, right? It doesn't seem to have been 
designed very well, unless I am missing something.
 
If you set the algorithm with ds_select_dst() to 4, round robin, it doesn't 
work! Here's what happens.
 
1. UA sends INVITE to OpenSER
2. OpenSER forwards INVITE to the first proxy in the dispatcher list.
3. Proxy sends back a digest challenge for authorisation credentials to OpenSER.
4. OpenSER forwards the challenge back to the UA.
5. The UA sends the INVITE again to OpenSER, this time with the requested 
credentials.
6. OpenSER forwards the new INVITE to the _OTHER_ proxy in the dispatcher list.
 
This is where things start to fall over. This proxy has not issued a challenge 
request yet so it _again_ sends a digest challenge back to the UA through 
OpenSER. The UA does not like to receive a second challenge to what it's 
already sent and gives up.
 
If you set the algorithm to something else besides 4, say 0, to hash to the 
callid, then OpenSER tries to use an arbitrary proxy from the list. Given that 
it's hashed against the callid it doesn't switch proxies like it does above in 
mid call. However, if that proxy is down, it _NEVER_ tries another proxy, thus 
rending the dispatcher module as a load balancer completely useless.
 
If this module was designed to be a load balancer, how have people gotten it to 
work? I find it incredibly hard to believe that the dispatcher module was not 
designed with the above scenarios in mind. I'm so frustrated because what I am 
trying to do is so simple (had issues with SRV behaving in a similar way). Send 
requests from OpenSER to another proxy/pbx in a redundant and load balanced 
fashion. If a system is down, simply go to the next! It's that simple!
 
Btw, the 'proxy' that OpenSER is forwarding too is Asterisk (yeah ok so it 
isn't a proxy) and the UA's are Polycom 301/501/601 phones.
 
Help very much appreciated!
 
Thanks.
 
 
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users

Reply via email to