<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi <br>
<br>
Here is another similar case which does not work. maybe it is related
the above issue as well.<br>
<br>
Jitsi 1.1 client: 101/103 , with xcap as storage<br>
proxy: kamailio 3.3<br>
ip network is: 192.168.122.0<br>
<br>
the setup is like the following:<br>
<br>
101(.224) --- proxy (.32) --- 103 (.1)<br>
<br>
After all presence related db are truncated, kamailio was restart. then
bring 101,103 online.<br>
<br>
On 101 add 103, 103 prompt up authorization window, click ok.<br>
now on 103, I can see 101 online status<br>
<br>
but on 101, I can not see 103 status <----the first trace
file: the jitsi-101-add-103-confirm-2.pcap<br>
<br>
(it is grey, even manually change 103 status from online to away etc,
on 101, the 103 always showed grey. <--- second trace file:
jitsi-101-103-change.pcap) <br>
<br>
Please see the attached pcap files.<br>
<br>
<br>
the watcher table shows:<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 2 1340114579<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 1 1340114582<br>
<br>
the active wacher table show:<br>
<br>
id presentity_uri watcher_username watcher_domain
to_user to_domain event event_id to_tag from_tag
callid local_cseq remote_cseq contact record_route
expires status reason version socket_info
local_contact from_user from_domain updated updated_winfo<br>
1 <a class="moz-txt-link-freetext" href="sip:101@192.168.122.32">sip:101@192.168.122.32</a> 101 192.168.122.32
101 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-7e2e 8b6ca8e7
<a class="moz-txt-link-abbreviated" href="mailto:9e8288d04d0dab18fda28f5fb24b40d8@0.0.0.0">9e8288d04d0dab18fda28f5fb24b40d8@0.0.0.0</a> 1 2
<a class="moz-txt-link-freetext" href="sip:101@192.168.122.224:5060;transport=udp;registe">sip:101@192.168.122.224:5060;transport=udp;registe</a>...
1340117922 1 1 udp:192.168.122.32:5060
<a class="moz-txt-link-freetext" href="sip:192.168.122.32:5060;transport=udp">sip:192.168.122.32:5060;transport=udp</a> 101 192.168.122.32 -1
-1<br>
2 <a class="moz-txt-link-freetext" href="sip:101@192.168.122.32">sip:101@192.168.122.32</a> 101 192.168.122.32
101 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-8a99 9975004d
<a class="moz-txt-link-abbreviated" href="mailto:9b8cb0735bc559232639aa28c16a6f4b@0.0.0.0">9b8cb0735bc559232639aa28c16a6f4b@0.0.0.0</a> 2 2
<a class="moz-txt-link-freetext" href="sip:101@192.168.122.224:5060;transport=udp;registe">sip:101@192.168.122.224:5060;transport=udp;registe</a>...
1340117921 1 2 udp:192.168.122.32:5060
<a class="moz-txt-link-freetext" href="sip:192.168.122.32:5060;transport=udp">sip:192.168.122.32:5060;transport=udp</a> 101 192.168.122.32 -1
-1<br>
3 <a class="moz-txt-link-freetext" href="sip:103@192.168.122.32">sip:103@192.168.122.32</a> 103 192.168.122.32
103 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-0117 9d873afb
30fa1ce8cca7a7c50fea11e688ec3d5e@0:0:0:0:0:0:0:0 1 2
<a class="moz-txt-link-freetext" href="sip:103@192.168.122.1:5060;transport=udp;registeri">sip:103@192.168.122.1:5060;transport=udp;registeri</a>...
1340117959 1 1 udp:192.168.122.32:5060
<a class="moz-txt-link-freetext" href="sip:192.168.122.32:5060;transport=udp">sip:192.168.122.32:5060;transport=udp</a> 103 192.168.122.32 -1
-1<br>
4 <a class="moz-txt-link-freetext" href="sip:103@192.168.122.32">sip:103@192.168.122.32</a> 103 192.168.122.32
103 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-9a71 101d721c
148be0ec1a4acc087c0083324398cf14@0:0:0:0:0:0:0:0 2 2
<a class="moz-txt-link-freetext" href="sip:103@192.168.122.1:5060;transport=udp;registeri">sip:103@192.168.122.1:5060;transport=udp;registeri</a>...
1340117959 1 2 udp:192.168.122.32:5060
<a class="moz-txt-link-freetext" href="sip:192.168.122.32:5060;transport=udp">sip:192.168.122.32:5060;transport=udp</a> 103 192.168.122.32 -1
-1<br>
5 <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
103 192.168.122.32 presence
a6a1c5f60faecf035a1ae5b6e96e979a-5ab7 e9099546
<a class="moz-txt-link-abbreviated" href="mailto:6ed81a0fa2042996295974b671a8074f@0.0.0.0">6ed81a0fa2042996295974b671a8074f@0.0.0.0</a> 1 2
<a class="moz-txt-link-freetext" href="sip:101@192.168.122.224:5060;transport=udp;registe">sip:101@192.168.122.224:5060;transport=udp;registe</a>...
1340118179 2 1 udp:192.168.122.32:5060
<a class="moz-txt-link-freetext" href="sip:192.168.122.32:5060;transport=udp">sip:192.168.122.32:5060;transport=udp</a> 101 192.168.122.32 -1
-1<br>
6 <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
101 192.168.122.32 presence
a6a1c5f60faecf035a1ae5b6e96e979a-98a8<br>
<br>
<br>
<br>
<br>
thanks<br>
<br>
min<br>
<br>
On 06/19/2012 01:00 PM, Daniel-Constantin Mierla wrote:
<blockquote cite="mid:4FE05BBD.3030202@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello,<br>
<br>
you have to share the content of the messages sent, providing just the
url is not enough to see what happens.<br>
<br>
watchers table is for the list of contacts and their global status in
regard to presentity, active_watchers is for keeping the presence
dialogs.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 6/19/12 12:47 PM, Min Wang wrote:<br>
</div>
<blockquote cite="mid:4FE058C3.2060300@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true" 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
moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true" 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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://asipto.com/u/katu">http://asipto.com/u/katu</a>
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://asipto.com/u/kpw">http://asipto.com/u/kpw</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
</body>
</html>