Hi Ming,

On Jun 27, 2012, at 10:40 AM, Min Wang wrote:

> HI Saúl:
>    Thanks a lot.
>>>     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.
>> 
>>   
>      There is a document from oracle describing the similar call flow:
> 
> http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#
> 
> in the Changing Presence Rules section:
> 
>             5. Because Alice's updated policy does not authorize Bob as a 
> watcher, the presence server sends a NOTIFY request to Bob's client, 
> notifying him that his subscription is terminated. In the NOTIFY request, the 
> Subscription-State header specifies terminated and the reason is set to 
> probation. This ends Bob's subscription with the presence server and also 
> ends the underlying SIP dialog. Bob's client responds with a 200 OK message.
> 
> 
>          It uses **probation** as the reason. Not sure if it is OMA standard 
> or not or just Oracle interpretation.
> 
>         the side-effect is: client will try to re-subscribe again and again ( 
> depending on the client?), which it is not that good from pure tech point of 
> view, since it will waste some resources un-needed.
> 

Well, if you just move a user from 'allow' to 'block' I don't see why you 
should use probation instead of rejected :-) There is something better to do 
here, in case you are going the OMA way: when you remove a contact from the 
resource-lists document, there will be no rule for him, thus the 'unlisted 
policy' will be applied, which by default is 'confirm', so the subscription 
will not be terminated, the user will get a NOTIFY without a body and a 
Subscription-State of 'pending'.

> 
>> 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.
>> 
>>   
> 
>          Yes, that would be a good solution if client people agree to do it.
> 

FWIW, I'm client people, and that's how we are doing it (also using OMA as I 
mentioned above) :-)

>           we have similar discuss on the sip-router mailing list as well
> 
> 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

Reply via email to