22 Jan
2009
22 Jan
'09
9:17 p.m.
Hi
Using kamailio v1.5 (trunk), I'm testing the following simple presence
scenario where one user shutdowns his application without prior un-PUBLISH
and un-REGISTER.
1) user A subscribes to user B presence. Both use X-Lite.
2) user B shutdowns his X-Lite (without doing un-REGISTER and un-PUBLISH of
his presence information),
3) user B starts again X-Lite, registers and publishes his presence,
from that point when user B updates his presence information, user A does
not see the updates !
I've configured kamailio to use
save("location", "0x04")
instead of
save("location")
for incoming REGISTER but this does not help.
Is there a way to clean presence DB tables properly when user B register
again ?
Regards,
Pascal
22 Jan
22 Jan
11:32 p.m.
El Jueves, 22 de Enero de 2009, Pascal Maugeri escribió:
Hi
Using kamailio v1.5 (trunk), I'm testing the following simple presence
scenario where one user shutdowns his application without prior un-PUBLISH
and un-REGISTER.
1) user A subscribes to user B presence. Both use X-Lite.
2) user B shutdowns his X-Lite (without doing un-REGISTER and un-PUBLISH
of his presence information), 3) user B starts again X-Lite, registers and
publishes his presence, from that point when user B updates his presence
information, user A does not see the updates !
The previous publish will expire soon, won't it?
--
Iñaki Baz Castillo
23 Jan
23 Jan
12:19 a.m.
Well not really : if we use long publish expiration such as 3600s, we may
have no presence update during 1 hour. Solution may be to reduce expires to
few minutes but this generate a lot more SIP traffic.
Regards,
Pascal
On Thu, Jan 22, 2009 at 7:32 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
El Jueves, 22 de Enero de 2009, Pascal Maugeri
escribió:
Hi
Using kamailio v1.5 (trunk), I'm testing the following simple presence
scenario where one user shutdowns his application without prior
un-PUBLISH
and un-REGISTER.
1) user A subscribes to user B presence. Both use X-Lite.
2) user B shutdowns his X-Lite (without doing un-REGISTER and un-PUBLISH
of his presence information), 3) user B starts again X-Lite, registers
and
publishes his presence, from that point when user
B updates his presence
information, user A does not see the updates !
The previous publish will expire soon, won't it?
--
Iñaki Baz Castillo
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
12:50 a.m.
El Jueves, 22 de Enero de 2009, Pascal Maugeri escribió:
Well not really : if we use long publish expiration
such as 3600s, we may
have no presence update during 1 hour. Solution may be to reduce expires to
few minutes but this generate a lot more SIP traffic.
Could you please paste the NOTIFY sent by the presence server after user B
has "crashed" and the restarted again (sending a new PUBLISH)?
I expect that NOTIFY will contain two status and it depends on the client
implementation which one to select for that AoR (not sure anyway, a NOTIFY
capture would be great).
--
Iñaki Baz Castillo
2:54 p.m.
I've much better results forcing an unregister of my user before doing the
register.
unregister("location", "$fu");
if (!save("location"))
sl_reply_error();
It looks that the unregister() cleans the presence tables.
I'm not sure if this is the proper way to proceed by at least it works for
me :-)
Any suggestion are welcome!
Pascal
On Thu, Jan 22, 2009 at 8:50 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
El Jueves, 22 de Enero de 2009, Pascal Maugeri
escribió:
Well not really : if we use long publish
expiration such as 3600s, we may
have no presence update during 1 hour. Solution may be to reduce expires
to
few minutes but this generate a lot more SIP
traffic.
Could you please paste the NOTIFY sent by the presence server after user B
has "crashed" and the restarted again (sending a new PUBLISH)?
I expect that NOTIFY will contain two status and it depends on the client
implementation which one to select for that AoR (not sure anyway, a NOTIFY
capture would be great).
--
Iñaki Baz Castillo
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
3:52 p.m.
2009/1/23 Pascal Maugeri <pascal.maugeri(a)gmail.com>om>:
I've much better results forcing an unregister of
my user before doing the
register.
unregister("location", "$fu");
if (!save("location"))
sl_reply_error();
If you do that, you are un-registering *all* the contacts for that
AoR, is it what you want?
It looks that the unregister() cleans the presence
tables.
It's not possible at all, nothing to do.
Perhaps you are using pua_usrloc module? That's important.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:09 p.m.
On Fri, Jan 23, 2009 at 11:52 AM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
Hum, good point. Thanks I'm going to check that.
-pascal
2009/1/23 Pascal Maugeri
<pascal.maugeri(a)gmail.com>om>:
yes.
I've much better results forcing an
unregister of my user before doing
the
register.
unregister("location", "$fu");
if (!save("location"))
sl_reply_error();
If you do that, you are un-registering *all* the contacts for that
AoR, is it what you want?
It looks that the unregister() cleans the
presence tables.
It's not possible at all, nothing to do.
Perhaps you are using pua_usrloc module? That's important.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
5:23 p.m.
2009/1/23 Pascal Maugeri <pascal.maugeri(a)gmail.com>om>:
If you are using pua_usrloc, then when deregistering a user it
generates a callback so pua_usrloc creates a new PUBLISH with content
"offline" and sends it to the presence server. Well, not true,
pua_usrloc creates a PUBLISH with no body but "Expires: 0" so when it
arrives to the presence server, the *matching* presentity row is
deleted.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
It's not
possible at all, nothing to do.
Perhaps you are using pua_usrloc module? That's important.
Hum, good point. Thanks I'm going to check that.
5:34 p.m.
As we're talking about it, what's purpose of active_watchers and watchers DB
tables ?
Is that so that each time I subscribe to a user presence there is a new
entry ? (it doesn't look to work that way).
-pascal
On Fri, Jan 23, 2009 at 1:23 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2009/1/23 Pascal Maugeri
<pascal.maugeri(a)gmail.com>om>:
If you are using pua_usrloc, then when deregistering a user it
generates a callback so pua_usrloc creates a new PUBLISH with content
"offline" and sends it to the presence server. Well, not true,
pua_usrloc creates a PUBLISH with no body but "Expires: 0" so when it
arrives to the presence server, the *matching* presentity row is
deleted.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
It's
not possible at all, nothing to do.
Perhaps you are using pua_usrloc module? That's important.
Hum, good point. Thanks I'm going to check that.
5:45 p.m.
2009/1/23 Pascal Maugeri <pascal.maugeri(a)gmail.com>om>:
Is that so that each time I subscribe to a user
presence there is a new
entry ? (it doesn't look to work that way).
No, I mean each time a different PUBLISH (different SIP-If-Match
header) arrives to the presence server.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5582
days inactive
5583
days old
9 comments
2 participants
participants (2)
-
Iñaki Baz Castillo -
Pascal Maugeri