Re: [SR-Users] Subscription-State: terminated;reason=terminated?

HI Anca

I tested. it (Kamailio) works as expected, great job!

(1) The issue is jitsi does not honor retry-after=300. It should be the jitsi issue. I will post on their mailing list. (2) OMA way:

According to Saúl:

There is something better to do here, in case you are going the OMA way: when you remove a contact from the resource-lists document, there will be no rule for him, thus the 'unlisted policy' will be applied, which by default is 'confirm', so the subscription will not be terminated, the user will get a NOTIFY without a body and a Subscription-State of 'pending'.

see : https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028592.ht...

from: http://tools.ietf.org/html/rfc5025

If the<sub-handling> permission changes value to "confirm", the processing depends on the states of the affected subscriptions. Unfortunately, the state machine inRFC 3857 http://tools.ietf.org/html/rfc3857 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 http://tools.ietf.org/html/rfc5025#ref-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.

it seems even pure RFCs allow active=>pending.

So Is it possible to add another mod paramater, to allow this OMA way, does it make sense?

thanks.

min

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