Hi Hadriel,thanks a lot for your comments. Some comments inline. On Mon, Mar 2, 2009 at 4:12 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:> I like the purpose of your draft a lot, to let receiving users block future calls from the same source. But I'm not sure the implementation of it is quite right. It seems to me that if I want to block a user from calling me indefinitely, I'd want it to be known by more than the proxy chain sending it to me. In particular, I'd probably want it to be known to the Registrar or at least some database multiple proxies of my provider can query. That way if there are multiple proxies which can reach me, or the proxy is rebooted/replaced/whatever, or I move/roam and end up using another proxy, the block-list is not lost. When the proxy gets the blocking information, it should update the"shared database" with this information. >> Obviously in a 3GPP-specific model you could have the S-CSCF or some other node perform such an update to the HSS or whatever, but then how would I unblock the user at some later time, if I changed my mind? And how do I detect if my operation succeeded, in case the proxy couldn't process my block/unblock request? This is something we have mentioned in the Open issues section(Appendix B). Here I see two alternatives:1) "Offline" mechanism for unblocking user identities (e.g. webinterface where one could remove blacklisted destinations)2) "Online" mechanism for unblocking user identities. For this, Ibelieve the UA should retrieve the "blacklisted destinations", selectone or several destinations and send a F00B4r message with: Reason: block; cause=1 or 2; text="unblock";uri="sip:user@xxxxxxxxxx"; Expires=0orReason: block; cause=3; text="unblock"; uri="sip:user@xxxxxxxxxx"; Expires=XYZ >> This seems more like a use-case for an event-package, where one can send a PUBLISH to block/unblock users, or even a Subscribe to view the current list. The tricky part with that is that for some incoming calls there is no caller-id/source-AoR for me to ask to be blocked or unblocked. But since for that to be the case requires the proxy to essentially be a B2BUA (to provide privacy anonymization, or in 3GPP's case to remove and store the PAI), then one could argue the PUBLISH can be sent to that same upstream B2BUA which can insert that info if it still has it. (ugly, but possible) Hmmm... I'll have to think about that issue more.> The event-package seems to be a reasonable alternative. And yes, whenthe called UA cannot resolve the calling identity, the server needs tofetch the actual identity of the caller (See section 3.2). In otherwords, the UA would ask the server to "blacklist the identity thatinitiated dialog X". > Some other comments on your draft:> 1) You show the Reason header being removed by the Proxy. While that may make sense for some cases, for being out on vacation it does not - I *want* the UAC to see it. I believe the header can reveal sensitive information for an attacker:permanent blocking vs temporal blocking (and the expires). Cheers,-- Victor Pascual Ávila_______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
