Hi Ranjit, 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. 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 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. 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. 2) You describe the Reason header being inserted in BYE/CANCEL, but in the example it's in a 4xx. Sending it in a 4xx failure response should be explicitly included, imho, even though I think the Reason-header RFC didn't allow it (for some whacky reason). 3) You add an Expires parameter (which should be lower-case, by the way), and say if it's value is "99999" then it's permanent, but meanwhile in one example a value of "604800" is used for being on vacation. So clearly 99999 is not max. Seems to me "99999" is a very small number, just slightly longer than a day. :) Maybe just make it 4294967295 (an unsigned long, 2^32-1, 136 years). 4) In the security section, it mentions integrity protection to prevent snooping of messages when using this header. AFAIK, integrity protection provides no eavesdropping protection (that would be encryption); not that I can see why it matters if someone snoops on this header anyway. You also later cite TLS and S/MIME - I think you might as well remove S/MIME since it's a waste of 6 characters in toner/ink if anyone prints this draft out. ;) -hadriel ________________________________________ From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, March 02, 2009 3:45 AM To: sipping@xxxxxxxx Subject: New Internet Draft for Caller Identity Blocking Hi All I have just submitted an I-D on blocking caller identities during ringing and call termination phases by extending SIP Reason header to be included in SIP BYE and CANCEL methods. Please review and comment The URL of the draft is: http://www.ietf.org/internet-drafts/draft-avasarala-sipping-reason-header-dynamic-icb-00.txt Thanks Regards Ranjit _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
