HI Saúl:
thanks a lot.
> Well, if you just move a user from 'allow' to 'block' I don't see why you
> should use probation instead of rejected :-) 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'.
>
>
Could you please point out the corresponding OMA documents? I am not
familar with OMA documents. there are 1.0, 1.1, and 2.0 version etc.
Regarding the "unlisted policy", does the default policy "confirm" mean
" allow"? or there is some special meaning in the OMA context?
For the pure IETF RFCs, is there any unlisted policy? if so, what is it?
I seems can not find it.
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?
the downside of this approach is:
the client 101 ( depending on the client?) will pop-up
another authorization windows ( asking to allow 102 again) even though
101 removed 102 from contact list just 2 seconds ago? right?
>>
>>> You could use watcherinfo (RFC3857) here: 102 will subscribe to the
>>> presence.winfo event for himself and he will get notified when 101
>>> subscribes to him. Then, (this is not on any spec IIRC, but I'm applying
>>> Common Sense (TM) here) 102 would subscribe to 101 again, because she sees
>>> that 101 just subscribed to him, he is her buddy, and she has no
>>> subscription towards him.
>>>
>>>
>>>
>> Yes, that would be a good solution if client people agree to do it.
>>
>>
> FWIW, I'm client people, and that's how we are doing it (also using OMA as I
> mentioned above) :-)
>
>
Oh yah. that is great. Jitsi seems did not do this way (
according to my tests).
if client doing this way, then no need to for the proxy server to
send the pending state, the server just need to send terminated with
reason=-rejected reason, right?
kind regards
min
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
