[SR-Users] simple test case: add user/delete user on kamailio 3.3 presence server

[Daniel-Constantin Mierla]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/a10b5b42/attachment.htm>