Re: [stir] FYI only: Two new VoIP spam drafts

[Henning Schulzrinne <[e-mail]>]

Catching up on comments. Please see inline.

________________________________
From: stir <[e-mail]> on behalf of Alex Bobotek <[e-mail]>
Sent: Sunday, October 2, 2016 2:01:50 AM
To: Henning Schulzrinne; [e-mail]
Subject: Re: [stir] FYI only: Two new VoIP spam drafts


It’s good to see the docs.  I’m very pleased to see the facilitation of end-user feedback, information crucial to abuse mitigation.



Comments on draft-schulzrinne-dispatch-status-unwanted:



1.       The status code could, conceivably, be returned by automata or by human-triggered action (e.g., user click on the ‘report spam’ button).  Consider whether the status code could reflect action by someone or something other than the typically-human called party and at points before the terminating device.  IMHO, it should permit such indications from automata as well as human-initiated actions.


>> Definitely both.


2.       The recommendation that the response code not be used in creating call filters unless the call has been authenticated via 4474bis is too strong.  There are many cases where I want such non-authenticated information to be used to filter my calls.  Just about everybody using the more popular call blocking solutions available today benefit from blacklisting based on feedback of unauthenticated caller IDs, and this practice should not be terminated capriciously.  Additionally, 4474bis is only one of many methods of auth and may instead be more of  a statement of service provider origination than of calling address authority or authentication.  I suggest toning this down to a statement that the possibility of spoofing or unauthorized use should be taken into consideration in constructing call filters.


>> Good point.


3.       The draft should include normative text that specifies when a SIP entity MAY/SHOULD/SHALL return the status code.  It only specifies what a recipient of the code MAY do.  For example, add to section 4:

“A SIP entity MAY reply to a SIP request with the ‘Unwanted’ response code if there is a user-initiated or other indication that the request is unwanted. “


>> I'm not sure how to write this. I don't see a SHOULD/MUST here since the UAS would never have to return this at all, even if it is spam.


4.       Consider allowing SIP entities handling the response to substitute a different code in any forwarded responses.  A called party may not wish to convey rejection as unwanted all the way back to the calling party.  I don’t know the right answer, and I hope others’ opinions will be expressed.  There are times when a message instructing a caller to ‘place me on your organization’s DNC’ is desired, and times when a more silent approach is preferred.


>> With SBCs, this is common, so I see no harm.



5.       The introductory paragraph discusses the need to express that a call is unwanted.  Section 3 discusses the need to indicate that a caller’s calls are unwanted.   These are different assertions.  The most basic assertion is ‘this call is unwanted’.  Perhaps an additional ‘no calls from that address are wanted’ assertion should also be supported.


>> I'm not sure how expressing displeasure only about the call itself is helpful. The typical call spam button also doesn't just drop the message into the spam folder (unless it's a stand-alone client); it flags the message sender, typically, for enhanced scrutiny.





Regards,



Alex

From: stir [mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: Friday, September 30, 2016 6:08 PM
To: [e-mail]
Subject: [stir] FYI only: Two new VoIP spam drafts



[Please address comments to the DISPATCH list; this copy is FYI only since I forgot to bcc the list.]



In collaboration with members of the Robocall Strike Force (https://www.fcc.gov/news-events/events/2016/08/first-meeting-industry-led-robocall-strike-force), I have submitted two I-D's:



https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted/

https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/



that fill in operational needs for dealing with SIP spam. The first defines a new status code (666) that users can use to mark unwanted calls, either as a response code to an INVITE or in a Reason header in a BYE response. (This will likely be supplemented in practice by API-based mechanisms for post-call spam reports.)



The second defines a set of Call-Info parameters that allow the carrier or other UE-trusted SIP entity in the path to indicate the spam probability, type of call and other related information that will allow the UE and user to make better call handling decisions.



This complements the 'verstat' work being submitted to 3GPP (by others), for indicating the level of trust in the From/PAI tel URI.



Henning