If the <sub-handling> permission changes value to "confirm", the
   processing depends on the states of the affected subscriptions.
   Unfortunately, the state machine in RFC 3857 does not define an event
   corresponding to an authorization decision of "pending".  If the
   subscription is in the "active" state, it moves back into the
   "pending" state.  This causes a NOTIFY to be sent, updating the
   Subscription-State [7] to "pending".  No reason is included in the
   Subscription-State header field (none are defined to handle this
   case).  No further documents are sent to this watcher.  There is no
   change in state if the subscription is in the "pending", "waiting",
   or "terminated" states.  If a new subscription arrives later on, and
   the value of <sub-handling> that applies to that subscription is
   "confirm", the subscription processing follows the "subscribe, no
   policy" branch from the "init" state, and a 202 response to the
   SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State
   of "pending".  No presence document is included in that NOTIFY.

Hi Min, Klaus,


Example 1.10. Set xcapauth_userdel_reason parameter
...
modparam("presence_xml", "xcapauth_userdel_reason", "probation;retry-after=30")
modparam("presence_xml", "xcapauth_userdel_reason", "rejected")

Min, I would appreciate if you could test this and let me know.

Regards,
Anca




On 06/26/2012 08:03 PM, Min Wang wrote:

HI Klaus , Anca:

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 for updated xcap policy.
Not sure if it is OMA standard or not or just Oracle interpretation.

What about adding a module parameter (string) with "probation" as
default?

        I guess it is a good  solution from practical point of view.

        Also how about adding another parameter as well: retry_after ,
something default 10 or 30 minutes?





thanks

min