<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
HI Anca<br>
<br>
I tested. it (Kamailio) works as expected, great job!<br>
<br>
(1) The issue is jitsi does not honor retry-after=300. It should be
the jitsi issue. I will post on their mailing list.<br>
(2) OMA way:<br>
<br>
According to Saśl:<br>
<br>
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'.<br>
<br>
see :
<a class="moz-txt-link-freetext" href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028592.html">https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028592.html</a><br>
<br>
<br>
from: <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5025">http://tools.ietf.org/html/rfc5025</a><br>
<pre class="newpage"> If the <sub-handling> permission changes value to "confirm", the
processing depends on the states of the affected subscriptions.
Unfortunately, the state machine in <a
href="http://tools.ietf.org/html/rfc3857">RFC 3857</a> 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 [<a
href="http://tools.ietf.org/html/rfc5025#ref-7"
title=""Session Initiation Protocol (SIP)-Specific Event Notification"">7</a>] 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.
</pre>
<br>
it seems even pure RFCs allow active=>pending.<br>
<br>
So Is it possible to add another mod paramater, to allow this OMA
way, does it make sense? <br>
<br>
<br>
<br>
thanks.<br>
<br>
<br>
min<br>
<br>
<br>
<blockquote cite="mid:4FEB294D.7080203@1and1.ro" type="cite">Hi Min,
Klaus,
<br>
<br>
<br>
Example 1.10. Set xcapauth_userdel_reason parameter
<br>
...
<br>
modparam("presence_xml", "xcapauth_userdel_reason",
"probation;retry-after=30")
<br>
modparam("presence_xml", "xcapauth_userdel_reason", "rejected")
<br>
<br>
Min, I would appreciate if you could test this and let me know.
<br>
<br>
Regards,
<br>
Anca
<br>
<br>
<br>
<br>
<br>
On 06/26/2012 08:03 PM, Min Wang wrote:
<br>
<blockquote type="cite">HI Klaus , Anca:
<br>
<blockquote type="cite">
<blockquote type="cite"><a class="moz-txt-link-freetext" href="http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#">http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#</a>
<br>
<br>
in the Changing Presence Rules section:
<br>
<br>
5. Because Alice's updated policy does not authorize Bob
<br>
as a watcher, the presence server sends a NOTIFY request to Bob's
<br>
client, notifying him that his subscription is terminated. In the
NOTIFY
<br>
request, the Subscription-State header specifies terminated and the
<br>
reason is set to probation. This ends Bob's subscription with the
<br>
presence server and also ends the underlying SIP dialog. Bob's client
<br>
responds with a 200 OK message.
<br>
<br>
<br>
It uses **probation** as the reason for updated xcap
policy.
<br>
Not sure if it is OMA standard or not or just Oracle interpretation.
<br>
</blockquote>
<br>
What about adding a module parameter (string) with "probation" as
<br>
default?
<br>
</blockquote>
I guess it is a good solution from practical point of view.
<br>
<br>
Also how about adding another parameter as well: retry_after ,
<br>
something default 10 or 30 minutes?
<br>
<br>
<br>
<br>
<br>
<br>
thanks
<br>
<br>
min
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>