Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Richard Shockey <richard@shockey.us> Thu, 20 July 2017 19:38 UTC

Return-Path: <richard@shockey.us>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D0112F299 for <sipcore@ietfa.amsl.com>; Thu, 20 Jul 2017 12:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMRnZIJoWWXZ for <sipcore@ietfa.amsl.com>; Thu, 20 Jul 2017 12:38:26 -0700 (PDT)
Received: from qproxy1.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19B31293E1 for <sipcore@ietf.org>; Thu, 20 Jul 2017 12:38:25 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by qproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 015CE120B45 for <sipcore@ietf.org>; Thu, 20 Jul 2017 13:38:21 -0600 (MDT)
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n7ZH1v00t1MNPNq017ZL4F; Thu, 20 Jul 2017 13:33:21 -0600
X-Authority-Analysis: v=2.2 cv=UvYTD64B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=G3gG6ho9WtcA:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=kUVcWBOSAAAA:8 a=48vgC7mUAAAA:8 a=RpNjiQI2AAAA:8 a=kNH0ug7cwpVFfZga6P0A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=hpEB6L2-uw6rD9M2:21 a=YaV9uFvTcuK7wi6V:21 a=QEXdDO2ut3YA:10 a=2fN0Ut44FUSjvWHL4tab:22 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CpFVKoJzldF1UEtbH8xgL6woM3dBGbElzVb7jfpJJaY=; b=j0abCmcPxFyYBMqGLNrYU/Elml U+p5ewUOaxKDIdciL4Gu/2b9notIgG/w5wTrVfvZoDyjn0NiWJlY9lQv9bxqz3e7R1AAGVAz4RswH OqlECu4gpvUv2htT2vlquDaC6;
Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:51383 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from <richard@shockey.us>) id 1dYHCH-000mZQ-J9; Thu, 20 Jul 2017 13:33:17 -0600
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Thu, 20 Jul 2017 15:33:15 -0400
From: Richard Shockey <richard@shockey.us>
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>, "sipcore@ietf.org" <sipcore@ietf.org>
Message-ID: <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us>
Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
References: <CY1PR09MB07602078727954F586DCBDD3EAA10@CY1PR09MB0760.namprd09.prod.outlook.com> <SN2PR03MB235023C01D8658B9B25A3577B2A60@SN2PR03MB2350.namprd03.prod.outlook.com> <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <SN2PR03MB23509530AE70988D06A97191B2A60@SN2PR03MB2350.namprd03.prod.outlook.com> <CY1PR09MB07606A3F6AD98F8CB7235FD5EAA60@CY1PR09MB0760.namprd09.prod.outlook.com> <SN2PR03MB2350B8FDFC86CC4DDA03F013B2A60@SN2PR03MB2350.namprd03.prod.outlook.com> <C9588D9A-B3ED-4088-9128-4E4D54FCA06C@shockey.us> <CY1PR09MB0760C398A942BEBB0EAD07D0EAA70@CY1PR09MB0760.namprd09.prod.outlook.com>
In-Reply-To: <CY1PR09MB0760C398A942BEBB0EAD07D0EAA70@CY1PR09MB0760.namprd09.prod.outlook.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box462.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 100.36.29.226
X-Exim-ID: 1dYHCH-000mZQ-J9
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-29-226.washdc.fios.verizon.net ([192.168.1.152]) [100.36.29.226]:51383
X-Source-Auth: richard+shockey.us
X-Email-Count: 1
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/8Yf1xoHhJL7ccI3xH-WXUcfc8-U>
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 19:38:29 -0000

In line..



On 7/20/17, 1:17 PM, "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov> wrote:

    There are four likely models:
    
    * the call type (and spam-quotient) information may be shown to users, but most likely when reviewing voice mail, not a ringing call (where a simple binary indicator is probably more suitable, derived from information in the draft, possibly)

RS>  That’s what I’ve been thinking.  The binary indicator is most useful during ringing and that is the 2-3 seconds you have when you look at the UA.  Some Data Analytics vendors have indicated there is zero difference in consumer behavior on binary display (good vs bad red vs green) vs granular scoring (0-100) display for instance.  This is really the VERISAT 3GPP parameter for inband SIP usage vs some other out of band transmittal (HTTP) to the UA. 


    * various end system call handling algorithms, e.g., the semi-automated 'do not disturb' features in Android and iOS, so that, for example, non-personal calls would be directed to voice mail after 10 pm or during meetings.

RS> Agreed but I’m not sure how much UA programming people can actually handle. Of course, we can program pretty much anything we want into the UA at this point.  But some of this may be network or proxy (PBX) based as well. 

    * PBX and similar corporate systems that filter and manage calls, whether by corporate policy (e.g., to prevent Microsoft "support" calls) or by user preference.
    * as a call-out to a third-party system - the call information is proxied to a third party system, which then add the call-info labeling to the call

RS> These may be closely bound.  Its clear at least from some discussions I’ve had with enterprises that they may want to manage this process themselves for various legal and regulatory concerns.  There are clearly early adopter industries. Financial Services, Health Care and Utilities where these techniques come under the general heading of “reputation management” and fraud protection.  There is another use case involving public safety that has been barely touched. 
    
    In all cases, the information in the header would seem to be, at most, be indirectly reflected in the appropriate user interface.  But, in my view, you need to provide the end system and UI with a bit more data so that they can do the filtering and UI tailoring. It's easy to turn a spam score into red and green, but you can't set red and green thresholds appropriate to the circumstances if the carrier has already made that decision.

RS> Sure but this is ultimately a consumer / enterprise decision on who does what to analyze the call.  My guess is most consumers (98%) would want the carrier to deal with it.  That’s what we pay them for and life is too complicated as it is.  Enterprises, especially those that rely on various forms of voice communications for mission critical applications may take a different view.  I suspect many of them do not want to rely on carrier data analytics if they are to be held liable for the consequences.  If we can properly define a limited set of tools then the market will sort out the gory details.  The good news here is that there is a ready market for these solutions if we can define to tool kit correctly.  
    
    The CNAM information seems complementary to this, although it might use some of the same type labeling. CNAM also seems to require far more originator cooperation (and a caller is unlikely to label itself as "spam"...).

RS> Agreed.  “Empower Consumers” as you colleague’s on 12th street would call it.  ( 
    
    Henning
    
    -----Original Message-----
    From: Richard Shockey [mailto:richard@shockey.us] 
    Sent: Thursday, July 20, 2017 12:22 PM
    To: Asveren, Tolga <tasveren@sonusnet.com>; Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
    Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
    
    
    
    The other issue is who is the intended recipient of the data?  Among those of us that are actively evaulating Call Validation Display options we see some differences.  What a consumer may need to see is vastly different from what a inbound call center agent or enterprise user should see and should call validation data be combined with other forms of calling party identity in a expanded  CNAM (calling party name) like service offering.  In the EU for example they have no experience at all with CNAM.  That has typically been a North Americian service. 
    
    I understand the argument for a binary data display such as green check vs red octonganal stop like visual indicator and there are serious nuances in what type of text should be displayed. We are not there yet.   We are delving into the black arts of UI design here and we are simply going to have to do some experimentation to come up with answers and even then its clear that one size may not fit all.
    
    In any event there is already a thoughtful discussion between the service provider community and some national regulators on what the options are.
    
    ..
    
    On 7/19/17, 2:46 PM, "sipcore on behalf of Asveren, Tolga" <sipcore-bounces@ietf.org on behalf of tasveren@sonusnet.com> wrote:
    
        Agreed that this is somewhat about "philosophical aspects of priority". Having said that, I really feel not content with a fine-granularity indicator considering how in practice it would/could be generated especially considering all the operator/equipment/call scenario/deployment model combinations. It would be like, actually worse, than how sausages are prepared.
        
        I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something useful at the end; just my 2 cents.
        
        Thanks,
        Tolga
        
        -----Original Message-----
        From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] 
        Sent: Wednesday, July 19, 2017 2:33 PM
        To: Asveren, Tolga <tasveren@sonusnet.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
        Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
        
        This type of labeling is very common for email spam filters. It's essentially the same as "There's a 47% chance of rain today." Except that meteorologists are smart enough not to say 47%, but rather 50%.
        
        It is better than the "According to the polls, candidate H has an 89% chance of winning the election." (Any semblance of initials to real persons has a 1-in-26 chance of being made up.)
        
        Theoretically, unlike for elections and somewhat similar to the weather case, this is testable: You could take all the 50% spam or rain predictions, check with some reliable metric (human or rain gauge) whether the spam or rain happened and compare your results, i.e., roughly one in two such predictions should indeed turn out to be spam or rain. (It's more complicated than that, but we're getting pretty close to the philosophical debate of what probabilities mean when making predictions, which is apparently a rather unsettled scientific question.)
        
        To actually answer your question: I don't think this is useful except as a rough way for users to trade false-positive/false-negative penalties. For example, they may discard all 80%+ probability calls, route 30-80% calls to voicemail and ring the below-30% calls. The thresholds are arbitrary, but users may tune them based on experience ("all the calls in voicemail were spam, so I can go lower").
        
        Some people pack an umbrella when there's a 20% chance of rain, others are more willing to risk getting wet. By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked.
        
        Henning
        
        -----Original Message-----
        From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga
        Sent: Wednesday, July 19, 2017 2:11 PM
        To: Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
        Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
        
        Let me ask this question then:
        What would "spam with a likelihood of 47%" mean? Will the specification detail how this percentage need to be calculated? Otherwise how can the end-device take some action based on this value? One could argue that all these are "implementation dependent" but honestly I think this would just create confusion/chaos in practice and likely to be not useful.
        
        Thanks,
        Tolga
         
        
        _______________________________________________
        sipcore mailing list
        sipcore@ietf.org
        https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=B4eJ1PKmueNhKHee7Uns8SvL4EwRgp-A98tQOLWwL2g&s=06LUWYaIYuqYCl5NSo8ONPBkR7yWFyc-8lxUlVTOyWI&e=