Re: [Sipping] New Internet Draft for Caller Identity Blocking

["Hannes Tschofenig" <[e-mail]>]

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: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Hadriel Kaplan
>Sent: 02 March, 2009 17:12
>To: Avasarala Ranjit-A20990; [e-mail]
>Subject: Re: [Sipping] 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: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Avasarala Ranjit-A20990
>Sent: Monday, March 02, 2009 3:45 AM
>To: [e-mail]
>Subject: [Sipping] 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 
>[e-mail] for questions on current sip 
>Use [e-mail] for new developments of core SIP
>