HI Since my previous email has attachment , it is still waiting for the approval.
So here is again the text part ( please see the email below)
According to the trace, here is the call flow for this case:
101(.224) --- proxy (.32) --- 103 (.1)
101/103 are jitsi 1.1 nightly build client, the configure is to use SIMPLE/xcap on clients.
the call flow for 101 adding 103 as contact
101 proxy 103 | | | user-add-103 | | | | | | xcap put pres/rls | | |--------------------------> | | | | | | SUBSCRIBE (presence/103) | | |---------------------------> | | | 202 ok | | |<----------------------------| | | NOTIFY( presenc/pending) | | |<----------------------------| | | | NOTIFY ( winfo/101 pending) | | |---------------------------------->| | 200 ok | | |--------------------------> | | | | 200 OK | | |<----------------------------------| | | auth window pop | | user accept | | SUBSRIBE(presence/101) | | |<----------------------------------| | | 202 OK | | |---------------------------------->| | NOTIFY (winfo,103 active) | | |<-------------------------- | | | 200 ok | | |--------------------------> | | | | NOTIFY (presence/101) | | |---------------------------------> | | | 200 OK | | |<----------------------------------| | NOTIFY (presence/103 open) | | |<-------------------------- | | ****** ( missing part) | 200 ok | | |--------------------------> | |
As on the 103, auth windows pop up, then click ok to accept (thus it will added 101 as contact), in this case it does not do any xcap operation? Is it the correct call flow?
Thanks
min
On 06/19/2012 04:49 PM, Min Wang wrote:
Hi
Here is another similar case which does not work. maybe it is related the above issue as well.
Jitsi 1.1 client: 101/103 , with xcap as storage proxy: kamailio 3.3 ip network is: 192.168.122.0
the setup is like the following:
101(.224) --- proxy (.32) --- 103 (.1)
After all presence related db are truncated, kamailio was restart. then bring 101,103 online.
On 101 add 103, 103 prompt up authorization window, click ok. now on 103, I can see 101 online status
but on 101, I can not see 103 status <----the first trace file: the jitsi-101-add-103-confirm-2.pcap
(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)
Please see the attached pcap files.
the watcher table shows:
id presentity_uri watcher_username watcher_domainevent status reason inserted_time 1 sip:103@192.168.122.32 101 192.168.122.32 presence 2 1340114579 2 sip:101@192.168.122.32 103 192.168.122.32 presence 1 1340114582
the active wacher table show:
id presentity_uri watcher_username watcher_domainto_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 1 sip:101@192.168.122.32 101 192.168.122.32 101 192.168.122.32 message-summary a6a1c5f60faecf035a1ae5b6e96e979a-7e2e 8b6ca8e7 9e8288d04d0dab18fda28f5fb24b40d8@0.0.0.0 1 2 sip:101@192.168.122.224:5060;transport=udp;registe... 1340117922 1 1 udp:192.168.122.32:5060 sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1 2 sip:101@192.168.122.32 101 192.168.122.32 101 192.168.122.32 presence.winfo a6a1c5f60faecf035a1ae5b6e96e979a-8a99 9975004d 9b8cb0735bc559232639aa28c16a6f4b@0.0.0.0 2 2 sip:101@192.168.122.224:5060;transport=udp;registe... 1340117921 1 2 udp:192.168.122.32:5060 sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1 3 sip:103@192.168.122.32 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 sip:103@192.168.122.1:5060;transport=udp;registeri... 1340117959 1 1 udp:192.168.122.32:5060 sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1 4 sip:103@192.168.122.32 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 sip:103@192.168.122.1:5060;transport=udp;registeri... 1340117959 1 2 udp:192.168.122.32:5060 sip:192.168.122.32:5060;transport=udp 103 192.168.122.32 -1 -1 5 sip:103@192.168.122.32 101 192.168.122.32 103 192.168.122.32 presence a6a1c5f60faecf035a1ae5b6e96e979a-5ab7 e9099546 6ed81a0fa2042996295974b671a8074f@0.0.0.0 1 2 sip:101@192.168.122.224:5060;transport=udp;registe... 1340118179 2 1 udp:192.168.122.32:5060 sip:192.168.122.32:5060;transport=udp 101 192.168.122.32 -1 -1 6 sip:101@192.168.122.32 103 192.168.122.32 101 192.168.122.32 presence a6a1c5f60faecf035a1ae5b6e96e979a-98a8
thanks
min
On 06/19/2012 01:00 PM, Daniel-Constantin Mierla wrote:
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 forresource-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_usernamewatcher_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 watchertable 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 ofhttp://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 watchertable 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
-
Min Wang