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

Min Wang mwang at sipwise.com
Tue Jun 19 13:46:20 CEST 2012


HI Daniel

     please see the attached trace files.

    notes:

     192.168.122.32 is the kamailio proxy
     192.168.122.224 is the 101 client ( bria or jitsi)
     192.168.122.1 is 103 client ( always jitsi)

      the client is configedto use xcap server at 
http://192.168.122.224:1080 which is proxied to kamailio proxy port 5060.

     and the kamailio.cfg is something:

...
                 switch($rm) {
                         case "PUT":
                                 xcaps_put("$var(uri)", "$hu", "$rb");
                                 if($xcapuri(u=>auid)=~"pres-rules")
                                 {
                                         xlog("===== xhttp put: 
refreshing watchers for $var(uri)\n");
                                         
pres_update_watchers("$var(uri)", "presence");
                                         
pres_refresh_watchers("$var(uri)", "presence", 1);
                                 }
                                 else if 
($xcapuri(u=>auid)=~"resource-lists"
                                          || 
$xcapuri(u=>auid)=~"rls-services") {
                                        rls_update_subs("$var(uri)", 
"presence");
                                 }
                                 exit;
                         break;
                         case "GET":
                                 xlog("===== xhttp: get $var(uri) => 
$hu\n");
                                 xcaps_get("$var(uri)", "$hu");
                                 exit;
                         break;
                         case "DELETE":
                                 xcaps_del("$var(uri)", "$hu");
                                 if($xcapuri(u=>auid)=~"pres-rules")
                                 {
                                         xlog("===== xhttp del: 
refreshing watchers for $var(uri)\n");
                                         
pres_update_watchers("$var(uri)", "presence");
                                         
pres_refresh_watchers("$var(uri)", "presence", 1);
                                 }
                                 else if 
($xcapuri(u=>auid)=~"resource-lists"
                                          || 
$xcapuri(u=>auid)=~"rls-services") {
                                        rls_update_subs("$var(uri)", 
"presence");
                                 }

                                 exit;
                         break;

...


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/faead282/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bria-add-contact.pcap.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/faead282/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jitsi-add-contact.pcap.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120619/faead282/attachment-0003.txt>


More information about the sr-users mailing list