[pjsip] NOTIFY with status terminated AND reason 'deactivated'.

Benny Prijono 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
>      "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
>




More information about the pjsip mailing list