19 May
2015
19 May
'15
8:40 p.m.
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 INVITE session if 30 seconds are expired
What I do not understand - is it possible to find if client is
connected now to kamailio?
I talk about TCP/TLS connection only - not about registration record.
Thank you!
21 May
21 May
8 a.m.
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 active tcp
connections. Then you can check in the list if connection id from the
usrloc record is still there.
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.
Cheers,
Daniel
On 19/05/15 20:40, Dmytro Bogovych wrote:
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 INVITE session if 30 seconds are expired
What I do not understand - is it possible to find if client is
connected now to kamailio?
I talk about TCP/TLS connection only - not about registration record.
Thank you!
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
22 May
22 May
2:40 p.m.
On 21/05/15 20:27, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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 detect expired records. So I
don't think it was extended for db only as I have not noticed any update
on it. With current approach will required loading all records in memory
to check. A different approach to act when connection has been closed
and the query the database for its id might be better.
A recent addition was to close the tcp connection if the associated
usrloc record has expired.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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?
2:53 p.m.
Daniel-Constantin Mierla writes:
current readme text lets the reader to understand that handle_lost_tcp
applies to all modes:
If set to 1, Kamailio will remove location records made via
TCP/TLS/WS/WSS transports when it looses corresponding tcp
connections.
in order to avoid confusion, perhaps it should list in which modes the
variable has effect.
-- juha
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 detect expired records. So I
don't think it was extended for db only as I have not noticed any update
on it. With current approach will required loading all records in memory
to check. A different approach to act when connection has been closed
and the query the database for its id might be better.
A recent addition was to close the tcp connection if the associated
usrloc record has expired.
3:03 p.m.
On 22/05/15 14:53, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
current readme text lets the reader to understand that
handle_lost_tcp
applies to all modes:
If set to 1, Kamailio will remove location records made via
TCP/TLS/WS/WSS transports when it looses corresponding tcp
connections.
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.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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 detect expired records. So I
don't think it was extended for db only as I have not noticed any update
on it. With current approach will required loading all records in memory
to check. A different approach to act when connection has been closed
and the query the database for its id might be better.
A recent addition was to close the tcp connection if the associated
usrloc record has expired.
3:31 p.m.
Daniel-Constantin Mierla writes:
i cannot add anything since i don't have any knowledge of what someone
who added the variable has actually implemented.
-- juha
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.
3:53 p.m.
On 22/05/15 15:31, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
i
cannot add anything since i don't have any knowledge of what someone
who added the variable has actually implemented.
You can add what was concluded on this discussion, that is not working
on DB ONLY module.
Some devs are gone, other patches come via pull requests from non-devs
-- we can't wait always for the original author, the source code helps
to figure out when needed to add to docs anything makes it more clear
and better to use.
Otherwise, open an issue and some other dev will take care when time
will allow it.
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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.
3481
days inactive
3484
days old
7 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Dmytro Bogovych -
Juha Heinanen