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.
> 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.
we have similar discuss on the sip-router mailing list as well
http://lists.sip-router.org/pipermail/sr-users/2012-June/073759.html
Kind regards.
min
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
