Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator)

"Avasarala Ranjit-A20990" <ranjit@motorola.com> Thu, 09 July 2009 12:00 UTC

Return-Path: <ranjit@motorola.com>
X-Original-To: rucus@core3.amsl.com
Delivered-To: rucus@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6714E28C187 for <rucus@core3.amsl.com>; Thu, 9 Jul 2009 05:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNH7ZOhV7FBr for <rucus@core3.amsl.com>; Thu, 9 Jul 2009 05:00:54 -0700 (PDT)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id BBCA028C173 for <rucus@ietf.org>; Thu, 9 Jul 2009 05:00:53 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-15.tower-55.messagelabs.com!1247140879!91013849!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [136.182.1.12]
Received: (qmail 27468 invoked from network); 9 Jul 2009 12:01:20 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-15.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 12:01:20 -0000
Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n69C1JM8006632 for <rucus@ietf.org>; Thu, 9 Jul 2009 05:01:19 -0700 (MST)
Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n69C1J4i026405 for <rucus@ietf.org>; Thu, 9 Jul 2009 07:01:19 -0500 (CDT)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n69C1HKe026386 for <rucus@ietf.org>; Thu, 9 Jul 2009 07:01:18 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Jul 2009 20:00:55 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B07DACF61@ZMY16EXM66.ds.mot.com>
In-Reply-To: <18a603a60907090449i50853e2ane40291095aaf83f7@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Operator-assisted SPIT filtering (was Re: [Rucus] SPIT from operator)
Thread-Index: AcoAjIXaet1xsen7Sb2lpSDtSIP+lgAAA7Kg
References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> <18a603a60907090449i50853e2ane40291095aaf83f7@mail.gmail.com>
From: Avasarala Ranjit-A20990 <ranjit@motorola.com>
To: Pars Mutaf <pars.mutaf@gmail.com>
X-CFilter-Loop: Reflected
Cc: Rucus BoF <rucus@ietf.org>
Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator)
X-BeenThere: rucus@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" <rucus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rucus>
List-Post: <mailto:rucus@ietf.org>
List-Help: <mailto:rucus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 12:00:55 -0000

Hi

Comments inline <Ranjit> 


Regards
Ranjit

-----Original Message-----
From: Pars Mutaf [mailto:pars.mutaf@gmail.com] 
Sent: Thursday, July 09, 2009 5:20 PM
To: Avasarala Ranjit-A20990
Cc: David Schwartz; Charzinski, Joachim (NSN - DE/Munich); Rucus BoF; Victor Pascual Avila
Subject: Operator-assisted SPIT filtering (was Re: [Rucus] SPIT from operator)

Hello,

On Thu, Jul 9, 2009 at 2:00 PM, Avasarala Ranjit-A20990<ranjit@motorola.com> wrote:
> Hi
>
> Actually operator can come up with a service of helping the teminating users (called users) to identify the unwanted callers and help them register the unwanted caller identity with the network. Once registered, the calls from the particular caller who was registered as "unwanted" would be prevented from calling. This could be one way of reducing SPIT.
>
> The draft: http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00 proposes a solution of appending a SIP Reason header with new protocol value "block" to indicate to network to block the calling user from future calling.
>
> We are in the process of updating this document and hence comments are welcome.

I am not sure to understand why the target cell phone doesn't drop the unwanted call itself.
<Ranjit> The target call phone understands that the caller is unwanted (E.g. telemarketer) only after speaking. So after speaking the target call phone decides to block the caller from further calling.  The target call phone can also block the caller even without speaking (i.e. dropping the call) and blocking the caller.

Thanks,

pars


>
> Thanks
>
> Regards
> Ranjit
>
> -----Original Message-----
> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf 
> Of David Schwartz
> Sent: Thursday, July 09, 2009 4:22 PM
> To: Pars Mutaf; Charzinski, Joachim (NSN - DE/Munich)
> Cc: Rucus BoF
> Subject: Re: [Rucus] SPIT from operator
>
> It's a shame Dan Wings proposal (http://tools.ietf.org/html/draft-wing-sipping-spam-score-02) never went anywhere. Basically, it argues that the operator simply "marks" or "scores" a call and passes it on to the recipient for him/her to make the actual accept/reject decision.
>
> D.
>
> -----Original Message-----
> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf 
> Of Pars Mutaf
> Sent: Thursday, July 09, 2009 1:47 PM
> To: Charzinski, Joachim (NSN - DE/Munich)
> Cc: Rucus BoF
> Subject: Re: [Rucus] SPIT from operator
>
> Hi Joachim,
>
> To clarify, I don't receive calls but messages from the operator about new services, new songs available as ring tone, and various non-sense stuff. I would like to filter these messages on my cell phone. As far as I know, there this no easy way to inform the operator that I'm not interested in these messages.
>
> We seem to agree that the cell phone should be able to filter operator's SPIT.
>
> Please see below for more...
>
> On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - DE/Munich)<joachim.charzinski@nsn.com> wrote:
>> Hi Pars,
>>
>>> This makes me think that SPIT solutions must be operator independent.
>>
>> I think this is generalizing too much. Solutions against the type of 
>> SPIT you mention will have to be operator independent (possibly also 
>> involving some regulatory power that forces operators to respect 
>> entries on "don't call" lists). The same will be true for the kind of 
>> Spam distribution services we find with the postal service 
>> ("distribute this to every household with a street address") - 
>> wherever the operator actually makes money from Spam or SPIT, it will 
>> be necessary to have an operator independent solution for fighting Spam and SPIT.
>>
>> On the other hand, it is probably the operators that are currently 
>> preventing large scale SPIT by performing ingress address filtering 
>> and enforcing rate caps on SIP signalling. Also, in a traditional 
>> telephony environment, it would be the operator that strips off the 
>> origin address for anonymous calls, so the operator has more power in 
>> filtering SPIT than the end user / end device would have.
>
> I am not sure that the operator is willing to filter SPIT. This is open to discussion.
>
> By the way, I note here that in your operator-based filtering approach, the operator should forward the messages marked as SPIT to the target cell phone anyways. This is because the false positive probability is never zero.
> The target user should make the decision whether or not a message is SPIT before deleting a message from inbox.
>
> As a consequence, this makes be believe that operator-based filtering is not really necessary. Just forward all messages to the target cell phone, the target cell phone can filter them and store the ones marked as SPIT for eventual user inspection.
>
> I missed something?
>
> Thanks
>
> pars
>
>
>
>
>>
>> Therefore I think we need two solutions that help both parties - the 
>> operator and the end user - to fight SPIT independently. They may 
>> even cooperate, but they cannot completely substitute one another.
>>
>>> What is the situation in other countries?
>>
>> I am living in germany, and I used to get a lot of cold calls, most 
>> of them machine assisted but actually connecting to a personal agent.
>> Only a few calls were completely automated. My cold calls frequency 
>> has dropped drastically since I started asking the callers for 
>> permission to record the calls for usage in court. They seem to have 
>> deleted my number from their address lists.
>> If operators didn't interfer (see the above mentioned rate caps and 
>> address filters), we would probably get a lot more calls, as there 
>> are a lot of VoIP contracts around where you can reach most of the 
>> fixed phone network within a flat rate.
>>
>> Best regards
>>
>>        Joachim.
>>
>>
>> -----Original Message-----
>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On 
>> Behalf Of ext Pars Mutaf
>> Sent: Wednesday, July 08, 2009 5:34 PM
>> To: Rucus BoF
>> Subject: [Rucus] SPIT from operator
>>
>> Hello,
>>
>> I my country, subscribers receive a lot of SPIT from their operators.
>> In my cell phone experience, the operator itself is the most serious 
>> SPIT problem.
>>
>> This makes me think that SPIT solutions must be operator independent.
>>
>> Would you have any comments on that? What is the situation in other 
>> countries? Which solutions can be applied?
>>
>> Thanks
>>
>> pars
>> _______________________________________________
>> Rucus mailing list
>> Rucus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rucus
>>
>> ----------------------------------------------------------
>> Joachim Charzinski
>>
>> Nokia Siemens Networks
>> Research, Technology and Platforms
>> Research & Technology / Network Evolution
>>
>> St.-Martin-Str. 53
>> Post box: D-80240 Muenchen
>> D-81541 Muenchen
>> Germany
>> Tel: +49 89 636 79902
>>
>> Joachim.Charzinski@nsn.com
>> http://www.nokiasiemensnetworks.com/global/
>>
>> Think before you print
>>
>> Nokia Siemens Networks GmbH & Co. KG
>> Sitz der Gesellschaft: München / Registered office: Munich
>> Registergericht: München / Commercial registry: Munich, HRA 88537
>> WEEE-Reg.-Nr.: DE 52984304
>>
>> Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens 
>> Networks Management GmbH Geschäftsleitung / Board of Directors: Lydia 
>> Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of 
>> supervisory board: Lauri Kivinen Sitz der Gesellschaft: München / 
>> Registered office: Munich
>> Registergericht: München / Commercial registry: Munich, HRB 163416
>>
> _______________________________________________
> Rucus mailing list
> Rucus@ietf.org
> https://www.ietf.org/mailman/listinfo/rucus
> _______________________________________________
> Rucus mailing list
> Rucus@ietf.org
> https://www.ietf.org/mailman/listinfo/rucus
>