[pjsip] NOTIFY with status terminated AND reason 'deactivated'.
bennylp at teluu.com
Thu Aug 27 07:01:20 EDT 2009
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
> 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-
> 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
> 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? ;-)
> Iñaki Baz Castillo
> <ibc at aliax.net>
> Visit our blog: http://blog.pjsip.org
> pjsip mailing list
> pjsip at lists.pjsip.org
More information about the pjsip