hi Saúl
>> If the<sub-handling> permission changes value to "confirm", the
>> processing depends on the states of the affected subscriptions.
>> Unfortunately, the state machine in
>> RFC 3857
>> 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
>> ] 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.
>>
>>
> Indeed, you are right, my memories were a bit rusty ;-) That's actually how
> OpenSIPS behaves IIRC and what makes more sense to me, since you avoid
> subscribing again.
>
>
>
Yah, sounds great.
But jitsi 1.1 behavior a liitle weird if state=pending is sent
to it, while it behaviors better if state = terminated is sent to it.
I know you have a great client, hope you guys can release
IM-client on windows/linux platform.
Again I appreciate you very much for taking time to answer my
questions.:)
kind regards.
min
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
