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@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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
