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

[Min Wang]

HI

This is another test case :

101/102 are jitsi client, but configured to use local storage mode, of 
course they all use SIMPLE mode instead of peer-to-peer.

script is like:

         if( is_method("SUBSCRIBE"))
         {
                 $var(ret_code)= rls_handle_subscribe();
                 if($var(ret_code)== 10)
                                 handle_subscribe();
                 t_release();
         }
         ....
        event_route[xhttp:request] {
...
                        xcap put/delete:
                                           
pres_update_watchers("$var(uri)", "presence");
                                         
pres_refresh_watchers("$var(uri)", "presence", 1);
  ...
}


when 101 add 102, auth window pop up, after click ok, but no presence on 
both sides, all are grey.

Checked the the kamailio wathcer table, there are two items: 101<->102, 
but both are in status=2 ( pending mode)

potential reason:

         the current implemention of handle_subscribe() function does 
not update the watcher table.
         The only possible functions to update watcher table are: 
pres_refresh_watchers/es_update_watcher.


         since we do not have any xcap operation, so 
pres_refresh_watchers/es_update_watcher never get called.


should we add pres_refresh_watchers/es_update_watcher after 
handle_subscribe()?
or should handle_subscribe() should update the watcher table as well?



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
>