[sr-dev] kamailio 3.1.3 Presence + XCAP problem, is it a bug?

[laura testi]

Hello Klaus,
thanks a lot for your answer.
Please, see my comment (BOB:>) below .



Message: 8
Date: Mon, 23 May 2011 09:47:23 +0200
From: Klaus Darilion <klaus.mailinglists at pernau.at>
Subject: Re: [sr-dev] kamailio 3.1.3 Presence + XCAP problem, is it a
       bug?
To: sr-dev at lists.sip-router.org
Message-ID: <4DDA110B.2020907 at pernau.at>
Content-Type: text/plain; charset=windows-1252



Am 20.05.2011 17:00, schrieb laura testi:
> Hello,
>
>
>
> I?m wring you again about the Presence = xcap Problem on Kamailio
> related with the deleting of a contact.
>
> Here a detailed description we have observed:
> User Case:
> ------------------
>   - user A is a contact of B and viceversa.
>   - then user A removes B from PC client
>
>
> 1) A sends SUBSCRIBE B to Kamail Presence Server (PS) with even type:
> presence and Expire:0 without body
>     a) PS removes A as wacther of B from the active_watchers table
>     b) PS sends NOTIFY to B (from B to B) with event type:
> presence.winfo and Subscription State:active,expire=570
>     c) PS sends NOTIFY to A (from B to A) with event type: Presence and
> Subscription State: terminated,reason=timeout
>
> 2) A sends XCAP PUT to PS with updated pres-rules without B in
> presence_allow rule
>     a) PS update xcap table the pres-rules record of A (without B)
>
>
> 3) A sends XCAP PUT to PS with updated resource-lists without B
>     a) PS update xcap table the resource-lists record of A(without B)
>
> 4)  the script kamailio.cfg calls pres_update_watchers
>     a) PS updates watcher table by setting the status = 2(pending) for
> the record of B is watcher of A (presentity), while the status remains
> active (1) for the record of A is watcher of B
>     b) PS sends NOTIFY to B(from A to B) with event type: presence and
> subscription state: pending
>
> 5) the script kamailio.cfg calls pres_refresh_watchers
>      a) PS sends NOTIFY to B(from A to B) with event type: presence and
> content type:application:pdif+xml (open, online, pdif entity:A,...)
>      b) the PC client of B shows a popup by saying 5has authorized the B
> adds A as contact request
>
>
> Test environments:
> --------------------------
> - server: kamailio 3.1.3 with presence, xcap and mysql in Redhat5.6_x64
> - transport: tcp
> - db: mysql
> - client: jitsi (ex SIP communicator)
> - kamailio.cfg: please see the attached file kamailio.zip
>
> Questions:
> -----------------
> 1) is it correct the first SUBSCRIBE from the PC client of A?

Strictly said: subscribing someones presence and allowing someone to
subscribe its own presence are 2 different things. But, usually they
come together.

Thus, by removing someone from the buddy list Jitsi does:
- unsubscribe the presentity
- remove the presentity from the allowed watchers

IMO this is fine.

> 2) are the over all call flows correct (see the attached wireshark trace)
> 3) are the steps 2 and 3 correct?

IMO yes.

> 4) the steps 4 and 5 are very strange, is it the bug of xcap module
> or/and presence module?

I think 4 is OK. But step 5 seems buggy as.

BOB:>

I think the step 4a) may be a bug:

the subscription STATUS of  B (watcher of A) to A should remain ACTIVE (1)
instead of PENDING(2). this state is very strange and that causes the
strange step 4b) after A having removed B. Because B does still subscribe
A’s presentity! And probably do this causes the incorrect behavior of step
5)?

Should the presence server also remove the record of the subscription from
A(watcher) to B(presentity)  from both active_watchers and watchers tables
instead of only from active_wtachers table? Because if A remove B
(unsubscribe B), that mean A don’t want to see the presentity of B. Or maybe
it’s correct put A’s subscription status of B in TERMINATED(3) instead of
removing the record (actually remains in ACTIVE(1)).

When the presence server is doing pres_refresh_watchers in step 5), I think
it checks the xcap table and see A is watcher of B  (A is in B’s
presence_allow rule) and is in B’s resource-list, and B is also
active_watcher of A in the active_watchers table, A’s subscription status of
B is ACTIVE(1) in watchers table, B’s subscription status of A is in
Pending(2), it send a NOTIFY to B. That’s really strange! Probabely the step
4) also causes this strange behavior.



What do you think would be the correct behavior?

BOB:>

I think in step 1, in addition to remove the record of A’s subscription of B
from active_watchers table, the PS should also remove the record of A’s
subscription of B from the watchers table or put the STATUS=TERMINATED.
That’s because A is not interested the B’s presentity anymore.

In step 4, the PS should not change watchers table, because B’s subscription
of A is still active (should not becomes pending), and should not send the
Pending notify too.

Same for step 5.

 thanks,

laura

 regards
klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110524/627cc04d/attachment.htm>