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

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Mar 2009 17:36:26 +0200

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 12:12:25 -0500

Ignoring the syntax differences, even semantically they're different.  One is about indicating spam, the other is about asking for call blocking.  Indicating spam might lead to call blocking, but not the other way around.  For example just because I'm on vacation or don't want to get calls from you in particular, does not mean your call is spam.  It should not affect your reputation, for example.  And semantically the spam one is an indication, whereas the blocking one is a command, fwiw.

Obviously the solution mechanism could be the same for both uses, I suppose. (which is probably more to your point :)

-hadriel

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, March 02, 2009 10:36 AM
> To: Hadriel Kaplan; 'Avasarala Ranjit-A20990'; [email-masked];
> [email-masked]
> Subject: RE: [Sipping] New Internet Draft for Caller Identity Blocking
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Mar 2009 19:41:44 +0200

-- dropping sipping 

>Ignoring the syntax differences, even semantically they're 
>different.  One is about indicating spam, the other is about 
>asking for call blocking.

The reason for asking calls to be blocked is important here.

>  Indicating spam might lead to call 
>blocking, but not the other way around.

Yes, it would be good if something happens when you receive unwanted
communication attempts. 

>  For example just 
>because I'm on vacation or don't want to get calls from you in 
>particular, does not mean your call is spam.   It should not 
>affect your reputation, for example.  And semantically the 
>spam one is an indication, whereas the blocking one is a command, fwiw.

When it is purely about configuring authorization policies then the
following mechanism might be more appropriate:
http://tools.ietf.org/html/draft-tschofenig-sipping-spit-policy-01

It re-uses mechanisms we have specified already elsewhere and can be outside
a specific call establishment procedure (which is reasonable also in the
on-vaction example you mentioned). 

A more sensible approach of handling my calls to you when you are on vaction
is to forward my calls to your mailbox rather than blocking them and
dropping them on the floor. Sure, it is your policy what todo with my calls
but ... 

One of the mentioned examples, namely telemarketing, lead me to believe that
this is not about configuring my buddy lists. 

>Obviously the solution mechanism could be the same for both 
>uses, I suppose. (which is probably more to your point :)
>
>-hadriel
>
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Mar 2009 19:51:11 +0200

>And one more general comment very similar to Hadriels:
>while I think the general idea of managing my 
>white-/grey-/black-lists instantenously is nice. But you are 
>basically only proposing a way to add something to a list and 
>push the responsibility for removal to a timer. I believe that 
>managing such an important list needs a lot more complex 
>management capabilities (querying, removal, modification,...). 
>If we have a solution for that, we could look for an easy way 
>how to combine that technique with direct feedback on an 
>incoming or terminated call.

Nils, you are certainly right and these mechanisms have been developed
already.
See, for example, http://www.ietf.org/rfc/rfc5025.txt which builds on
http://tools.ietf.org/html/rfc4745. 
Many of the clients have some form of buddy list management (+some
possibility to block users). 

A protocol that allows these XML documents to be managed is available as
well, namely XCAP. 

Similar mechanisms are available (and implemented) in XMPP. 

Ciao
Hannes