Hello,
you have to share the content of the messages sent, providing just the
url is not enough to see what happens.
watchers table is for the list of contacts and their global status in
regard to presentity, active_watchers is for keeping the presence
dialogs.
Cheers,
Daniel
On 6/19/12 12:47 PM, Min Wang wrote:
Hi
(1) I tested more. It is due to the difference between bria 3 and jitsi
while handling the adding/removing contact:
if contact is added/removed:
for jitsi, it send out:
PUT /xcap-root/resource-lists/users/sip:101@192.168.122.32/index
PUT /xcap-root/pres-rules/users/sip:101@192.168.122.32/presrules
for bria 3, it only send out
PUT
/xcap-root/resource-lists/users/101@192.168.122.32/contacts-resource-list.xml
HTTP/1.0.
PUT
/xcap-root/resource-lists/users/101@192.168.122.32/contacts-resource-list.xml
it does NOT send out the pres-rules.
Is it the good behavior ( from RFC point of view) ?
should I call the pres_update_watchers even though its is for
resource-lists?
(2) BTW, what is the exact purpose of watcher table?
e.g: on 101, if delete 103, watcher table become:
id presentity_uri watcher_username
watcher_domain event status reason inserted_time
1 sip:103@192.168.122.32 101
192.168.122.32 presence 1 1340096051
2 sip:101@192.168.122.32 103
192.168.122.32 presence 3 terminated 1340096181
it is item 2 become terminated instead of item 1. If watcher table
is for subscription, then seems item 1 should be terminated?
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?
and is the active_watcher mainly for the state machine of http://tools.ietf.org/html/rfc3857#section-4.7.1?
thanks.
min
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
Hello,
On 6/18/12 2:11 PM, Andreas Granig wrote:
Hi,
On 06/15/2012 05:25 PM, Min Wang wrote:
| 1 | sip:103@192.168.122.32
| 101 | 192.168.122.32 |
presence | 2 | | 1339772803 |
then I deleted the 103 from the contact list, the watcher table
still
shows the same.
For local storage, I'd expect an unsubscribe (subscribe with Expires=0)
from 101 to 103. The obvious work-flow would be to set it to
"terminated" in watchers table, and in case of a subsequent
re-subscribe
it should be changed back to "pending" state, although the
state-machine
doesn't indicate a transition from "terminated" back to "pending".
Isn't
this the case?
For xcap storage, there are other ways to block/remove a contact
on/from
the list. As Iñaki pointed out in
http://lists.opensips.org/pipermail/devel/2009-August/003868.html,
the
xcap server needs to notify the sip server about the change, which in
turn will notify the other party (103) that it's no longer allowed to
see 101's state. If the xcap_server module of kamailio is used, there
is
the following code snippet in some examples floating around on the
internet:
switch($rm) {
case "PUT":
xcaps_put("$var(uri)", "$hu", "$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
}
So, shouldn't this update the watchers accordingly? Anyways, also in
this case the watcher state should change to "terminated", and in case
of a re-subscribe it should go back to pending if xcap rules are
allowing this.
Maybe someone with good xcap_server/presence insights could elaborate
on
that?
to summarize, you say that when the contact is removed from the buddy
list, the watcher table is not updated to state terminated by
pres_update_watchers(...)?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
_______________________________________________
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