<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi <br>
<br>
(1) I tested more. It is due to the difference between bria 3 and jitsi
while handling the adding/removing contact:<br>
<br>
if contact is added/removed:<br>
<br>
for jitsi, it send out:<br>
<br>
PUT /xcap-root/resource-lists/users/<a class="moz-txt-link-freetext" href="sip:101@192.168.122.32/index">sip:101@192.168.122.32/index</a><br>
PUT /xcap-root/pres-rules/users/<a class="moz-txt-link-freetext" href="sip:101@192.168.122.32/presrules">sip:101@192.168.122.32/presrules</a><br>
<br>
<br>
for bria 3, it only send out<br>
<br>
PUT
/xcap-root/resource-lists/users/101@192.168.122.32/contacts-resource-list.xml
HTTP/1.0.<br>
PUT
/xcap-root/resource-lists/users/101@192.168.122.32/contacts-resource-list.xml
<br>
<br>
it does NOT send out the pres-rules.<br>
<br>
Is it the good behavior ( from RFC point of view) ?<br>
should I call the pres_update_watchers even though its is for
resource-lists?<br>
<br>
(2) BTW, what is the exact purpose of watcher table?<br>
<br>
e.g: on 101, if delete 103, watcher table become:<br>
<br>
id presentity_uri watcher_username
watcher_domain event status reason inserted_time<br>
1 <a class="moz-txt-link-freetext" href="sip:103@192.168.122.32">sip:103@192.168.122.32</a> 101 192.168.122.32
presence 1 1340096051<br>
2 <a class="moz-txt-link-freetext" href="sip:101@192.168.122.32">sip:101@192.168.122.32</a> 103 192.168.122.32
presence 3 terminated 1340096181<br>
<br>
it is item 2 become terminated instead of item 1. If watcher table
is for subscription, then seems item 1 should be terminated?<br>
Look at the code, it seems somehow serve as mixed role of
subscription/auth/xcap purpose, not for subscription state?<br>
<br>
and is the active_watcher mainly for the state machine of
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc3857#section-4.7.1">http://tools.ietf.org/html/rfc3857#section-4.7.1</a>?<br>
<br>
thanks.<br>
<br>
<br>
min<br>
<br>
<br>
<br>
<br>
<h1> <br>
</h1>
<br>
<br>
<br>
On 06/19/2012 10:41 AM, Daniel-Constantin Mierla wrote:
<blockquote cite="mid:4FE03B54.3090302@gmail.com" type="cite">Hello,
<br>
<br>
On 6/18/12 2:11 PM, Andreas Granig wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
On 06/15/2012 05:25 PM, Min Wang wrote:
<br>
<blockquote type="cite">| 1 | <a class="moz-txt-link-freetext" href="sip:103@192.168.122.32">sip:103@192.168.122.32</a> |
101 | 192.168.122.32 |
<br>
presence | 2 | | 1339772803 |
<br>
<br>
then I deleted the 103 from the contact list, the watcher table
still
<br>
shows the same.
<br>
</blockquote>
For local storage, I'd expect an unsubscribe (subscribe with Expires=0)
<br>
from 101 to 103. The obvious work-flow would be to set it to
<br>
"terminated" in watchers table, and in case of a subsequent
re-subscribe
<br>
it should be changed back to "pending" state, although the
state-machine
<br>
doesn't indicate a transition from "terminated" back to "pending".
Isn't
<br>
this the case?
<br>
<br>
For xcap storage, there are other ways to block/remove a contact
on/from
<br>
the list. As Iñaki pointed out in
<br>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/pipermail/devel/2009-August/003868.html">http://lists.opensips.org/pipermail/devel/2009-August/003868.html</a>, the
<br>
xcap server needs to notify the sip server about the change, which in
<br>
turn will notify the other party (103) that it's no longer allowed to
<br>
see 101's state. If the xcap_server module of kamailio is used, there
is
<br>
the following code snippet in some examples floating around on the
internet:
<br>
<br>
<br>
switch($rm) {
<br>
case "PUT":
<br>
xcaps_put("$var(uri)", "$hu", "$rb");
<br>
if($xcapuri(u=>auid)=~"pres-rules") {
<br>
pres_update_watchers("$var(uri)", "presence");
<br>
pres_refresh_watchers("$var(uri)", "presence", 1);
<br>
}
<br>
<br>
So, shouldn't this update the watchers accordingly? Anyways, also in
<br>
this case the watcher state should change to "terminated", and in case
<br>
of a re-subscribe it should go back to pending if xcap rules are
<br>
allowing this.
<br>
<br>
Maybe someone with good xcap_server/presence insights could elaborate
on
<br>
that?
<br>
</blockquote>
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(...)?
<br>
<br>
Cheers,
<br>
Daniel
<br>
<br>
</blockquote>
<br>
</body>
</html>