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.h… 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