How is this draft different from previously investigated approaches? http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00 Ciao Hannes >-----Original Message----- >From: sipping-bounces@xxxxxxxx >[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hadriel Kaplan >Sent: 02 March, 2009 17:12 >To: Avasarala Ranjit-A20990; sipping@xxxxxxxx >Subject: Re: New Internet Draft for Caller Identity Blocking > > >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-rea >son-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 > _______________________________________________ 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
