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

Iñaki Baz Castillo ibc at aliax.net
Thu Aug 27 06:14:02 EDT 2009


2009/8/26 Benny Prijono <bennylp at teluu.com>:
>> ----------------
>> 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".
>> ----------------
>>
>> Hope I made myself clear now :) Any chances this can be fixed?
>>
>>
>
> You're right. I added that to ticket #937


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).

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).


Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>




More information about the pjsip mailing list