Hi Min, On Jun 27, 2012, at 2:00 PM, Min Wang wrote:
> 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. > Have a look at OMA-WP-PRS implementation guidelines document. > Regarding the "unlisted policy", does the default policy "confirm" mean " > allow"? or there is some special meaning in the OMA context? > No, 'confirm' is the sub-handling action assigned to that particular policy. The concept of 'unlisted' was defined by OMA, but the action itself is defined in RFC5025: http://tools.ietf.org/html/rfc5025#section-3.2 > For the pure IETF RFCs, is there any unlisted policy? if so, what is it? I > seems can not find it. > No, there isn't, but IIRC if no rule can be applied the action is 'confirm', so that's kind-of the unlisted policy. > > 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 :-) > 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? > Well, if you remove someone from the rule list there is no policy for him so yes, another popup will be shown. If you don't want that to happen, the client should create a new policy for that URI, with sub-handling 'polite-block' perhaps. > Oh yah. that is great. Jitsi seems did not do this way ( according to > my tests). > I don't particularly like everything the OMA spec adds, but the external references really help. Once you setup the basic documents and lists you only need to make changes to one document: resource-lists. If you are not using OMA, you may need to modify 3 documents just for adding a contact: pres-rules, resource-lists and rls-services, and there is no way to do that operation atomically. > 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? > Depends. If you block the user yes, if you remove it from any list what I mentioned above applies. Kind regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
