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

Richard Shockey <richard@shockey.us> Thu, 20 July 2017 21:09 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 4C75B12714F for <sipcore@ietfa.amsl.com>; Thu, 20 Jul 2017 14:09:01 -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 mLz53NZ8BxVc for <sipcore@ietfa.amsl.com>; Thu, 20 Jul 2017 14:08:59 -0700 (PDT)
Received: from qproxy3.mail.unifiedlayer.com (qproxy3-pub.mail.unifiedlayer.com [67.222.38.20]) (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 87E2E1201F2 for <sipcore@ietf.org>; Thu, 20 Jul 2017 14:08:59 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by qproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 0207AD60CD for <sipcore@ietf.org>; Thu, 20 Jul 2017 15:08:59 -0600 (MDT)
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id n93v1v01X1MNPNq0193yBc; Thu, 20 Jul 2017 15:03:59 -0600
X-Authority-Analysis: v=2.2 cv=IqBuSP3g 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=48vgC7mUAAAA:8 a=HXqRbPrG5ElX3qFbnnMA:9 a=u2gVz7fNhMuur0Mb:21 a=_42CMPBoz19_EvoC:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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=B+Mm3WWpDD5UJHEBdynuosJK/3hFY7tER6vrS1kHy5k=; b=kbr5B1KCG+1iSTBAUKgNbi+US/ Z3JIo9JfryHH9WcQGtquN8FngIwD0nIq8AQfTSCfJMX5FS7YXMZNj4Df7Q3zcMAxkL24U+LUROgUH 6w2X5vi9Es+ehnpL/vBkfLRVj;
Received: from pool-100-36-29-226.washdc.fios.verizon.net ([100.36.29.226]:53739 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from <richard@shockey.us>) id 1dYIbz-001SVQ-NV; Thu, 20 Jul 2017 15:03:55 -0600
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Thu, 20 Jul 2017 17:03:54 -0400
From: Richard Shockey <richard@shockey.us>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, sipcore@ietf.org
Message-ID: <5D4E83A0-7B5E-4DC9-B8CD-A89B0C7F22B0@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> <8542D641-AE8F-4134-B357-017DC6F73E5F@shockey.us> <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu>
In-Reply-To: <15895f11-85c0-70ab-9cc1-e7b5943e2549@alum.mit.edu>
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: 1dYIbz-001SVQ-NV
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]:53739
X-Source-Auth: richard+shockey.us
X-Email-Count: 1
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/kQIv_V_O1GumR1FIHzNp9zHSVvI>
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 21:09:01 -0000



On 7/20/17, 4:12 PM, "sipcore on behalf of Paul Kyzivat" <sipcore-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

    On 7/20/17 3:33 PM, Richard Shockey 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.
    
    Ring tones could be used to indicate more than a binary choice while 
    remaining easy and quick to understand.

RS>  Humm that’s a good point.  It is something to consider especially for those with visual impairments.  “Warning Will Robinson” Seriously its an important consideration.   
    
    > 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.  
    
    Speak for yourself. Admittedly perhaps everyone reading this will fall 
    within the 2%. But lots of people are already familiar with configuring 
    their ring tones and dialer. It is not at all hard to imagine quite a 
    lot of people (at least those < 30 years old) wanting to tweak this stuff.

RS> Fair enough.  Choice is fine until someone screws up and you cant find the “reset to default” button.  
    
    	Thanks,
    	Paul
    
    _______________________________________________
    sipcore mailing list
    sipcore@ietf.org
    https://www.ietf.org/mailman/listinfo/sipcore