10 Feb
2012
10 Feb
'12
5:40 p.m.
10 feb 2012 kl. 15:16 skrev Daniel-Constantin Mierla:
Hello,
On 2/9/12 3:51 PM, Yufei Tao wrote:
Looking at SIP outbound we really need to get an overview of this and see what we
can do to minimize the time after connection being closed by client until we close it. But
do remember that it's up to the client to manage the connection and keep it up. In SIP
outbound the client has two connections to two separate proxys.
Agree with what Daniel says, the connection has no relationship to the connection (in XMPP
it has, but that's another protocol).
/O
Hi
When clients register to Kamailio over TCP/TLS, if I set
tcp_connection_lifetime to be quite small, like 30 seconds, and let
clients send refreshes every 20 seconds, for example. When client
crashes or have network problems, the TCP connection with Kamailio will
be closed by the server after 30 seconds of being idle.
My question is, is there a way of letting Kamailio tell which user the
broken TCP connection belongs to, and then remove the user from the
location table and update presence information etc?
The reason I want this is, if a user publishes its status of being
online with expiring time of 1 hour, but then crashed, then the location
table entry and presence information of this user would be wrong for the
rest of the hour. How do I get around this? I assume server can send
periodic OPTION messages but that would be a bit expensive.
for the moment, no,
there is no auto-unregistration when a stream connection is closed.
In SIP is no relation between a stream connection and user availability. The server can
connect back to the client, if no active connection can be reused. Of course, this has
problems with nat, the reason for having the cfg functions set_forward_no_connect() and
set_reply_no_connect(). Also, a presence state is not related to registration state, they
can be handled by different instances, via different connection.
The connection id is available at registration time, but not stored in location table. If
one wants to implement such feature, probably would not be complex at all.