Actually, you know, now that I think about it, what I think should happen is
that OpenSER should _never_ switch to another proxy when the Dialog/Callid is
the same. This just confuses everyone.
It doesn't matter if you use the dispatcher module or DNS SRV. Either one when
configured for round robin has the potential to send a second INVITE with
requested auth credentials (with the same call-id) to another proxy server.
This is bad. This was happening with DNS SRV and it's why I started looking at
the dispatcher module instead.
There has to be a way to do this....
Doug
-----Original Message-----
From: Douglas Garstang
Sent: Wed 11/23/2005 4:37 PM
To: [email protected]
Cc:
Subject: [Users] Dispatcher module - Does it actually work?
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
