Ovidiu Sas wrote:
> Both modules are doing this. The idea is to be able to do run time
> config changes.
Yep. The only real benefit from the modules in this setup is the fact
that they provide an interface to dynamic and variable-length lists of
gateways to cycle through according to certain
Both modules are doing this. The idea is to be able to do run time
config changes.
On 9/25/08, Alex Balashov <[EMAIL PROTECTED]> wrote:
> You make a compelling point.
>
> Then again, considering there are only two gateways involved at present,
> using a low inv_timer (tm) value and FAILURE-ROUTE
You make a compelling point.
Then again, considering there are only two gateways involved at present,
using a low inv_timer (tm) value and FAILURE-ROUTE will probably give me
the behaviour I need too. :-)
Ovidiu Sas wrote:
> Hello Alex,
>
> The lcr module is not complicated compared with dis
Hello Alex,
The lcr module is not complicated compared with dispatcher module ...
The complexity is pretty much the same.
Please check the sample config file that I created for openser 1.3 version:
http://voipembedded.com/resources/openser_dbtext_lcr.cfg
This will give you exactly the behavior tha
Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
> > > I would think that using one gateway primarily, with a secondary as a
> > > standby, is a very, very common use case. What is the best way to do
> > > this with dispatcher?
>
> i haven't followed this thread, but is there a rea
Daniel-Constantin Mierla writes:
> > I would think that using one gateway primarily, with a secondary as a
> > standby, is a very, very common use case. What is the best way to do
> > this with dispatcher?
i haven't followed this thread, but is there a reason why you can't use
lcr module fo
On 09/24/08 22:58, Alex Balashov wrote:
> Daniel,
>
> Daniel-Constantin Mierla wrote:
>
>
>>> I would think that using one gateway primarily, with a secondary as a
>>> standby, is a very, very common use case. What is the best way to do
>>> this with dispatcher?
>>>
>>>
>> Add a n
Daniel,
Daniel-Constantin Mierla wrote:
>> I would think that using one gateway primarily, with a secondary as a
>> standby, is a very, very common use case. What is the best way to do
>> this with dispatcher?
>>
> Add a new algorithm as you described, that is very simple, i will have
> it
Hello Alex,
On 09/24/08 20:11, Alex Balashov wrote:
> Hi Daniel,
>
> Kamailio is most definitely not re-enabling the gateway. I will look
> into it as you suggest and pass along what I find.
>
ok
> As far as the "algorithm" used by ds_next_dst()/domain(), why is there
> not an algorithm impl
Hi Daniel,
Kamailio is most definitely not re-enabling the gateway. I will look
into it as you suggest and pass along what I find.
As far as the "algorithm" used by ds_next_dst()/domain(), why is there
not an algorithm implemented which simply uses the first gateway in the
route set? Why do
Hello,
kamailio should automatically enable the gateway. The mechanism used is
based n internal tm callbacks. If the gateway is not brought back, then
there is something wrong with matching it when reply comes back.
Can you run on debug mode and send the messages along with sip trace?
Cheers,
There seems to be no way to assign a FAILURE-ROUTE to be associated with
the OPTIONS pings either, because the transactions are originated
internally by the module and not accessible via the stateful tracking
within script.
So, the question remains -- how do I make Kamailio notice that the
gat
How does one go about resurrecting gateways that have been marked into
"probing" mode back into the "active" set once they start replying to
the pings that the dispatcher facility sends?
I see the OPTIONS pings going through, and I see the UAs generating
replies to them whey come back up. But
13 matches
Mail list logo
