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!
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:
- receive INVITE answer
- check if recipient is registered but has no TCP/TLS connection now
- suspend answer for 30 seconds (for example)
- resume answer if REGISTER comes from lost client in these 30 seconds
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 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.
Cheers, Daniel
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 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.
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
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 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.
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 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 cannot add anything since i don't have any knowledge of what someone who added the variable has actually implemented.
-- juha
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 were not clear as the commit comments.
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