On 22/05/15 15:31, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> in order to avoid confusion, perhaps it should list in which modes the
>>> variable has effect.
>>>
>> Add anything that is relevant to docs. The feature came via a patch from
>> the community, iirc -- maybe the docs
Daniel-Constantin Mierla writes:
> > in order to avoid confusion, perhaps it should list in which modes the
> > variable has effect.
> >
> Add anything that is relevant to docs. The feature came via a patch from
> the community, iirc -- maybe the docs were not clear as the commit comments.
i cann
On 22/05/15 14:53, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>>> Just to make sure, does handle_lost_tcp now work also in DB-Only mode?
>>>
>> IIRC, the intitial implementation was based on iterating through the
>> records in memory and checking if the associated connection still
Daniel-Constantin Mierla writes:
> > Just to make sure, does handle_lost_tcp now work also in DB-Only mode?
> >
> IIRC, the intitial implementation was based on iterating through the
> records in memory and checking if the associated connection still
> exists. It is in the same iteration to detec
On 21/05/15 20:27, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> On the other hand, usrloc has option to remove the location record when
>> the tcp connection is detected to be closed. This might give you pretty
>> much what you need.
> Just to make sure, does handle_lost_tcp now w
Daniel-Constantin Mierla writes:
> On the other hand, usrloc has option to remove the location record when
> the tcp connection is detected to be closed. This might give you pretty
> much what you need.
Just to make sure, does handle_lost_tcp now work also in DB-Only mode?
-- Juha
_
Hello,
I don't recall right now any config function that will check if a
connection is still open.
The connection id is stored in the location record and checking if the
connection id is open, will not be complex at all. There might be a
solution using rpc commands, because one is listing the act
Greetings.
I want to modify INVITE answers processing in this way:
1) receive INVITE answer
2) check if recipient is registered but has no TCP/TLS connection now
3) suspend answer for 30 seconds (for example)
4) resume answer if REGISTER comes from lost client in these 30 seconds
5) terminate INV
