HI Saúl:
Thanks a lot.
>
> Have a look at OMA-WP-PRS implementation guidelines document.
>
>
I am search this OMA-WP-PRS on:
http://www.openmobilealliance.org/Technical/release_program/Presence_simple_archive.aspx
could not find it. maybe mispelled?
I guess you mean: Presence XDM Specification
OMA-TS-Presence_SIMPLE_XDM-V2_0-20090917-C.pdf
<http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=PresenceSIMPLE&file=V2_0-20090917-C/OMA-TS-Presence_SIMPLE_XDM-V2_0-20090917-C.pdf>
?
>> As for the pending, do you mean
>>
>> (1) the proxy server just send out pending without clients' re-subscribe?
>>
>> (2) or are you referring to:
>>
>> http://lists.opensips.org/pipermail/devel/2009-August/003868.html
>>
>> which set: reason=deactived
>>
>> thus causes the client to re-subscribe, and result in the pening state?
>>
>>
> Yes, this should be it. I was thinking about 1) before but that link
> refreshed my mind :-)
>
http://tools.ietf.org/html/rfc5025#section-3.2
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.
So it seems if the default policy is confirm, then this RFC 5025
do allow the active-> pending even though RFC 3857's digram does not
show it, right?
I mean (1) is legimate.
kind regards
min
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
