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

[Min Wang]

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
>

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