Hi Min, On Jun 26, 2012, at 11:33 AM, Min Wang wrote:
> Hi > > I have the following case: > > 101 --- kamailio proxy/xcap server -- 102 > > 101/102 : jitsi night build, xcap/SIMPLE mode > kamailio is 3.3 > 101 has 102 on its contacts list, and 102 has 101 on its contacts > list as well. ( no RLS involved) > > > (1) 101 add 102 to its contact list, what does it mean? > > It seems that some(most?) sip clients' implemenatation ( at least for > jitsi or bria) assume: > > 101 will add 102 to its xcap resource-list, then 101 will subscribe > to 102's status > 101 allow 102 to see its status by adding 102 to its allow list in > xcap pres-rules If you are using the IETF SIMPLE model, that's correct. If you are using OMA pres-rules, then the fact that 101 adds 102 as a buddy automagically authorizes him, because the pres-rules document will have a rule (wp_prs_grantedcontacts) which points to a list in resource-lists (oma_grantedcontacts), and the sub-handling value for this rule is 'allow' (as per the OMA specs). > > (2) if 101 remove 102 from its contacts, what does it mean? > > as in (1) that some(most?) sip clients' implemenatation ( at least > for jitsi or bria) assume: > > 101 remove 102 its from its xcap resource-list, 101 will un-subscribe > 102's status > 101 will not allow 102 to see its status by removing 102 from its > allow list in xcap pres-rules > > > (1)(2) so far seems reasonable. > > > (3) based on (1) and (2), let 101 remove 102 from its contacts list, > > 101 first remove 102 from its xcap pres-rules/resource-list, puts > those rules to the xcap server/proxy, > then send un-SUBSCRIBE ( expires=0 ). > > proxy in this case will send out NOTIFY to 102 to indicate its > subscription of 101 has been terminated, > > Subscription-State: terminated, reason=? > > what should be the correct reason code? > > according to the RFC 3265: > > rejected: The subscription has been terminated due to change in > authorization policy. Clients SHOULD NOT attempt to re-subscribe. > The "retry-after" parameter has no semantics for "rejected". > > It seems the rejected is the good choice. Yes. > > Once client (102) received the rejected reason, the subscription > has been terminated, so it will NOT try to re-subscribe ( to 101) > again ( even though 101 is still in 102's contact list). > > (4) But there is an issue, when 101 add 102 to its contact list again > > In this case, 101 first puts pres-rules (allow 102 to see its > status), and resources-list( adding 102) to the xcap server , > send subscribe to 102 to proxy, > > The proxy( in our case kamailio) will try as following: > > (4.a). If that subscription expired, or deleted by the kamailio > timer ( If understand kamailio code correctly) > > of course kamailio will NOT send any NOTIFY (to 102) since > there is no such subscription.. > > (4.b). if that subscription do still exist in cache or db > (active_watcher in kamailio's case), that > subscriptions will be marked as active > > kamailio/proxy will send the NOTIFY to 102 indicating > 101's status > > > But from 102 point of view: since that subscription has been > terminated , this notify will be rejected as 481 non-exist. Is it right? > > In neither case there is any way to indicate to 102 that 101 is > allowing 102 again, > thus 102 can NOT see 101's status. > > is it correct? > You could use watcherinfo (RFC3857) here: 102 will subscribe to the presence.winfo event for himself and he will get notified when 101 subscribes to him. Then, (this is not on any spec IIRC, but I'm applying Common Sense (TM) here) 102 would subscribe to 101 again, because she sees that 101 just subscribed to him, he is her buddy, and she has no subscription towards him. > > (5) But from pure end-user point of view, that is not the expected > behavior. > > User expect that 102 can see 101's status since 101 now allow > 102 again > and 102 did not remove 101 from his contact list. > > > (6) are (1)-(5) above correct behavior based on the sip SIMPLE RFCs? > > If so, how to solve the issue? > > Is there any standard/RFC way to notify to 102 that 101 allow 102 > again thus cause 102 to re-subscribe 101 again? > > > Just FYI, there was a discussion on it on the sip-router mailing list > http://lists.sip-router.org/pipermail/sr-users/2012-June/073759.html > > Regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
