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

[Min Wang]

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120627/1d0e2861/attachment-0001.htm>