On Thu, Aug 27, 2009 at 11:14 AM, I?aki Baz Castillo<ibc at aliax.net> wrote: > > Good point Sa?l. > > I would also add a similar behavior for other "reason" strings when > Subscription-Status is "terminated". > > According to RFC 3265 section "3.2.4. Subscriber NOTIFY Behavior": > > > --------------------------------- > ? deactivated: The subscription has been terminated, but the subscriber > ? ? ?SHOULD retry immediately with a new subscription. ?One primary use > ? ? ?of such a status code is to allow migration of subscriptions > ? ? ?between nodes. ?The "retry-after" parameter has no semantics for > ? ? ?"deactivated". > > ? probation: The subscription has been terminated, but the client > ? ? ?SHOULD retry at some later time. ?If a "retry-after" parameter is > ? ? ?also present, the client SHOULD wait at least the number of > ? ? ?seconds specified by that parameter before attempting to re- > ? ? ?subscribe. > > ? 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". > > ? timeout: The subscription has been terminated because it was not > ? ? ?refreshed before it expired. ?Clients MAY re-subscribe > ? ? ?immediately. ?The "retry-after" parameter has no semantics for > ? ? ?"timeout". > > ? giveup: The subscription has been terminated because the notifier > ? ? ?could not obtain authorization in a timely fashion. ?If a "retry- > ? ? ?after" parameter is also present, the client SHOULD wait at least > ? ? ?the number of seconds specified by that parameter before > ? ? ?attempting to re-subscribe; otherwise, the client MAY retry > ? ? ?immediately, but will likely get put back into pending state. > > ? noresource: The subscription has been terminated because the resource > ? ? ?state which was being monitored no longer exists. ?Clients SHOULD > ? ? ?NOT attempt to re-subscribe. ?The "retry-after" parameter has no > ? ? ?semantics for "noresource". > -------------------------------- > > > So in case of: > - deactivated > - probation > - timeout > - giveup > then the client should re-subscribe again (immediately or after the > time in "Retry-After" header). > It's "retry-after" *parameter" actually (I know, I'm nitpicking) > In case of: > - rejected > - noresource > then the client should not re-subscribe again. > > "giveup" is important as it means that the presentity didn't authorize > us to see its status in the maximum time allowed by the presence > server, so we must resubscribe again to get a new "pending" status. If > not, the presentity will not receive the presence.winfo notification > and couldn't authorize us (as it doesn't know we are subscribing to > its presence status). > > Good points. I added these in http://trac.pjsip.org/repos/ticket/937#comment:5 Thanks! Anything else? ;-) Cheers Benny > Regards. > > > -- > I?aki Baz Castillo > <ibc at aliax.net> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
