[SR-Users] simple test case: add user/delete user on kamailio 3.3 presence server
Min Wang
mwang at sipwise.com
Tue Jun 19 19:15:08 CEST 2012
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_domain
event status reason inserted_time
1 sip:103 at 192.168.122.32 101 192.168.122.32
presence 2 1340114579
2 sip:101 at 192.168.122.32 103 192.168.122.32
presence 1 1340114582
the active wacher table show:
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
1 sip:101 at 192.168.122.32 101 192.168.122.32
101 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-7e2e 8b6ca8e7
9e8288d04d0dab18fda28f5fb24b40d8 at 0.0.0.0 1 2
sip:101 at 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 at 192.168.122.32 101 192.168.122.32
101 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-8a99 9975004d
9b8cb0735bc559232639aa28c16a6f4b at 0.0.0.0 2 2
sip:101 at 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 at 192.168.122.32 103 192.168.122.32
103 192.168.122.32 message-summary
a6a1c5f60faecf035a1ae5b6e96e979a-0117 9d873afb
30fa1ce8cca7a7c50fea11e688ec3d5e at 0:0:0:0:0:0:0:0 1 2
sip:103 at 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 at 192.168.122.32 103 192.168.122.32
103 192.168.122.32 presence.winfo
a6a1c5f60faecf035a1ae5b6e96e979a-9a71 101d721c
148be0ec1a4acc087c0083324398cf14 at 0:0:0:0:0:0:0:0 2 2
sip:103 at 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 at 192.168.122.32 101 192.168.122.32
103 192.168.122.32 presence
a6a1c5f60faecf035a1ae5b6e96e979a-5ab7 e9099546
6ed81a0fa2042996295974b671a8074f at 0.0.0.0 1 2
sip:101 at 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 at 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 at 192.168.122.32/index
>> PUT /xcap-root/pres-rules/users/sip:101 at 192.168.122.32/presrules
>>
>>
>> for bria 3, it only send out
>>
>> PUT
>> /xcap-root/resource-lists/users/101 at 192.168.122.32/contacts-resource-list.xml
>> HTTP/1.0.
>> PUT
>> /xcap-root/resource-lists/users/101 at 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 at 192.168.122.32 101 192.168.122.32
>> presence 1 1340096051
>> 2 sip:101 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/b3e2db42/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jitsi-101-add-103-confirm-2.pcap
Type: application/cap
Size: 20753 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/b3e2db42/attachment-0002.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jitsi-101-103-change.pcap
Type: application/cap
Size: 15773 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/b3e2db42/attachment-0003.pcap>
More information about the sr-users
mailing list