So, will the lcr module let me timeout a gateway, and try another if it's
unavailable, as someone else suggested? As soon as I call t_relay(), I hit the
same problem.... it never times out and tries to reach the first gateway
forever.
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:[EMAIL PROTECTED]
Sent: Fri 11/25/2005 2:56 AM
To: Douglas Garstang
Cc: [email protected]
Subject: Re: [Users] Dispatcher module - Does it actually work?
On 11/24/05 22:42, Douglas Garstang wrote:
> Hashing over call-id may work to some degree, and I'll investigate it
more, but hashing over the From: means that the same caller will always get the
same Asterisk box, and your redundancy goes down the toilet.
>
The redundancy you talk about is only in your mind. I never said that
dispatcher supports redundancy. Please read carefully the messages and
have an adequate language.
Besides that, the topic was not about the redundancy, but about traffic
dispatching. To get the right answer put the proper question.
As you said, "The request URI from the phones is always going to be the
same." I suggested to use either call-id or from uri hash algorithm.
Yes, for same From uri the destination will be the same, and also for
same call-id the destination will be the same. Moreover, for different
values, the destination can be the same, since there is hash computation
and some results will overlap.
Cheers,
Daniel
>
> Actually I guess it's down the toilet anyway. The bottom line seems
to be that it doesn't matter whether you use the dispatcher or SRV records to
distribute load, OpenSER will never try to connect to anything else on failure
and at least for us, that makes it use in a production system, not an option.
>
>
>
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:[EMAIL PROTECTED]
> Sent: Thu 11/24/2005 12:19 PM
> To: Douglas Garstang
> Cc: [email protected]
> Subject: Re: [Users] Dispatcher module - Does it actually work?
>
>
>
> On 11/24/05 19:53, Douglas Garstang wrote:
> > The request URI from the phones is always going to be the
same. Doesn't that mean that OpenSER will always just use the same Asterisk box
then?
> if you do hash over r-uri, then yes, all messages will go to
same
> destination.
> > I'm trying to round-robin as evenly (as possible) and
distribute call load amonst multiple Asterisk systems.
> >
> In this case hash over call-id or from is more indicated.
>
> Cheers,
> Daniel
>
> > -----Original Message-----
> > From: Daniel-Constantin Mierla [mailto:[EMAIL PROTECTED]
> > Sent: Thu 11/24/2005 10:25 AM
> > To: Douglas Garstang
> > Cc: [email protected]
> > Subject: Re: [Users] Dispatcher module - Does it
actually work?
> >
> >
> >
> > On 11/24/05 01:37, Douglas Garstang wrote:
> > > 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 read carefully the documentation of the module,
you will see the
> > scope and limitations of the module:
> > http://openser.org/docs/modules/1.0.x/dispatcher.html
> >
> > If something is not according to the documentation,
then it is a bug.
> > Stateless means that the module does not keep any
state, so it cannot
> > select the same destination using algorithm 4 (round
robin) after a
> > authentication request, choose another algorithm
(hashing r-uri,
> > callid). Also, being stateless, it cannot try the next
address if the
> > selected destination fails.
> >
> > The module was not designed to be load balancer, but a
request
> > dispatcher. Load balancing is something more complex.
> >
> > In the last weeks I added destination failover support
in dispatcher
> > (serial forking within the destination set, with
auto-detection of
> > failed destinations). It will be on cvs very soon, I
have to update the
> > documentation and do some testing.
> >
> > Cheers,
> > Daniel
> >
> > >
> > > 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
> > >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > [email protected]
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://openser.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
