20 Sep
2007
20 Sep
'07
12:02 p.m.
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
ibc(a)in.ilimit.es
20 Sep
20 Sep
12:07 p.m.
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
12:33 p.m.
El Thursday 20 September 2007 11:07:45 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Ok. Anyway, wouldn't it be a useful feature for OpenSer core?
Thanks.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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. 
12:37 p.m.
-----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ó:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8j9oqjpLE0HiOBYRAp0KAKCJnrbPajVyaQBjmsVbg/ln39zh8ACfQ9rX
Er1PkTmw5B4/vcPM5rOccIE=
=R/rW
-----END PGP SIGNATURE-----
Iñaki Baz Castillo writes:
Ok. Anyway, wouldn't it be a useful feature for OpenSer core?
Thanks.
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.
1:01 p.m.
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
1:25 p.m.
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
ibc(a)in.ilimit.es
1:45 p.m.
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
2:35 p.m.
El Thursday 20 September 2007 12:45:53 Juha Heinanen escribió:
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
ibc(a)in.ilimit.es
Iñaki Baz Castillo writes:
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. :)
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. 
2:48 p.m.
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ó:
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, 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. :)
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.
2:57 p.m.
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
4:20 p.m.
El Thursday 20 September 2007 13:57:18 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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.
6277
days inactive
6277
days old
10 comments
4 participants
participants (4)
-
Carsten Bock -
Iñaki Baz Castillo -
jh＠tutpro.com -
Marc LEURENT