Hi, many times a softphone or PC crashes without sending the un-REGISTER, so the user remains in location table.
OpenSer allows sending SIP ping to users, is not possible to delete the location entry for a user who has left responding to those SIP pings?
Iñaki Baz Castillo writes:
OpenSer allows sending SIP ping to users, is not possible to delete the location entry for a user who has left responding to those SIP pings?
usrloc does provide mi command for deleting a contact. you can write an external application that pings users and deletes unresponding contacts.
-- juha
El Thursday 20 September 2007 11:07:45 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
OpenSer allows sending SIP ping to users, is not possible to delete the location entry for a user who has left responding to those SIP pings?
usrloc does provide mi command for deleting a contact. you can write an external application that pings users and deletes unresponding contacts.
Ok. Anyway, wouldn't it be a useful feature for OpenSer core?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes, it would be very useful!
Iñaki Baz Castillo a écrit :
El Thursday 20 September 2007 11:07:45 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
OpenSer allows sending SIP ping to users, is not possible to delete the location entry for a user who has left responding to those SIP pings?
usrloc does provide mi command for deleting a contact. you can write an external application that pings users and deletes unresponding contacts.
Ok. Anyway, wouldn't it be a useful feature for OpenSer core?
Thanks.
i don't think that pinging contacts in order to remove unresponding ones is in general a good idea. sip register request has been designed to expire if not refreshed in time. that together with limiting expires time to something reasonable should suffice.
i personally would not be happy my operator would remove my registration when my train goes into a tunnel at the as operator's proxy is trying to ping me.
-- juha
El Thursday 20 September 2007 12:01:12 Juha Heinanen escribió:
i don't think that pinging contacts in order to remove unresponding ones is in general a good idea. sip register request has been designed to expire if not refreshed in time. that together with limiting expires time to something reasonable should suffice.
Humm, but what about pua_usrloc?
Imagine you set your presence "offline". Using short register periods when you generate a new REGISTER pua_usrloc will generate a PUBLISH "online" and your watchers will see you again as online.
Yes, a solution would be to decrease the PUBLISH period in client to be shorter that REGISTER period, but short periods of PUBLISH are not really neccesary in "normal" cases.
Finally all this solutions would generate innecesary traffic, while a simple unregister from OpenSer if the user doesnt' respond to ping would be more "cheap".
i personally would not be happy my operator would remove my registration when my train goes into a tunnel at the as operator's proxy is trying to ping me.
But in that case your SIP client would register again, wouldn't it? If you are in a escenary with easy connection lost then is user task to set the REGISTER period shorter.
Regards.
Iñaki Baz Castillo writes:
But in that case your SIP client would register again, wouldn't it?
sip phone has not noticed that underlying ip connectivity over some wireless media is lost for the period the train is in tunnel unless it tries to register at the same time.
If you are in a escenary with easy connection lost then is user task to set the REGISTER period shorter.
no sip specification today mandates or even recommends setting register period short if there is possibility for temporary loss of connectivity. dropping of registration if contact does not respond would thus cause problems.
-- juha
El Thursday 20 September 2007 12:45:53 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
But in that case your SIP client would register again, wouldn't it?
sip phone has not noticed that underlying ip connectivity over some wireless media is lost for the period the train is in tunnel unless it tries to register at the same time.
Yes, I meant the "human" person could do it. Anyway common softphones don't allow a REGISTER option (except Twinkle as I know), so just forget my suggestion. :)
If you are in a escenary with easy connection lost then is user task to set the REGISTER period shorter.
no sip specification today mandates or even recommends setting register period short if there is possibility for temporary loss of connectivity. dropping of registration if contact does not respond would thus cause problems.
Yes, but there are problems too if a registered user has killed him softphone or PC without letting it sending the un-REGISTER. In that cases other user calling to him receive an infinite "Trying", while with my suggestion of un-register, callers would see "not found".
I don't know which issue is worse, but I'm sure that too many times a SIP device "dissapears" without sending a un-REGISTER.
There could be two options:
modparam("nathelper", "unregister_not_ping", 1) - 1: Enabled - 0: Dissabled.
modparam("nathelper", "unregister_not_ping_time", 60) - Time after a not ping responding user should be un-registered.
PD: Do you think I could report this as a wish in the tracker? or are you sure is really a bad idea?
Thanks.
Hi,
i do not see any problem here: What we do on our systems, is to catch a local "408 Request timeout" in Failure-Route in case the user did not properly unregister. We've set the timeout for request with no provisional to some acceptable value (e.g. like 5 seconds) and that's totally ok for us. I don't know, why a CPE should be unregistered, just because it did not reply to a NAT-Ping. I've seen multiple phone not properly replying to NAT-Pings, so for my point of view this would cause many problems.
Carsten
Am Donnerstag, den 20.09.2007, 13:35 +0200 schrieb Iñaki Baz Castillo:
El Thursday 20 September 2007 12:45:53 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
But in that case your SIP client would register again, wouldn't it?
sip phone has not noticed that underlying ip connectivity over some wireless media is lost for the period the train is in tunnel unless it tries to register at the same time.
Yes, I meant the "human" person could do it. Anyway common softphones don't allow a REGISTER option (except Twinkle as I know), so just forget my suggestion. :)
If you are in a escenary with easy connection lost then is user task to set the REGISTER period shorter.
no sip specification today mandates or even recommends setting register period short if there is possibility for temporary loss of connectivity. dropping of registration if contact does not respond would thus cause problems.
Yes, but there are problems too if a registered user has killed him softphone or PC without letting it sending the un-REGISTER. In that cases other user calling to him receive an infinite "Trying", while with my suggestion of un-register, callers would see "not found".
I don't know which issue is worse, but I'm sure that too many times a SIP device "dissapears" without sending a un-REGISTER.
There could be two options:
modparam("nathelper", "unregister_not_ping", 1)
- 1: Enabled
- 0: Dissabled.
modparam("nathelper", "unregister_not_ping_time", 60)
- Time after a not ping responding user should be un-registered.
PD: Do you think I could report this as a wish in the tracker? or are you sure is really a bad idea?
Thanks.
Iñaki Baz Castillo writes:
Yes, but there are problems too if a registered user has killed him softphone or PC without letting it sending the un-REGISTER. In that cases other user calling to him receive an infinite "Trying", while with my suggestion of un-register, callers would see "not found".
then you need to improve your script. set invite timer for no (provisional) response to a short value. then in failure route do whatever the user wants, for example, return "480 temporarily unavailable" or redirect the caller somewhere else.
-- juha
El Thursday 20 September 2007 13:57:18 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Yes, but there are problems too if a registered user has killed him softphone or PC without letting it sending the un-REGISTER. In that cases other user calling to him receive an infinite "Trying", while with my suggestion of un-register, callers would see "not found".
then you need to improve your script. set invite timer for no (provisional) response to a short value. then in failure route do whatever the user wants, for example, return "480 temporarily unavailable" or redirect the caller somewhere else.
Yes, thanks.
But I can see a user as "online", but it can be not reachable since him softphone crashed. Using "pua_usrloc" a un-REGISTER would publish "offline" state, but for that it's required a nu-REGISTER.
-
Carsten Bock -
Iñaki Baz Castillo -
jh＠tutpro.com -
Marc LEURENT