Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking
"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Mon, 02 March 2009 15:35 UTC
Return-Path: <Hannes.Tschofenig@gmx.net>
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 658603A6AE7 for <rucus@core3.amsl.com>; Mon, 2 Mar 2009 07:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.316
X-Spam-Level:
X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599]
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 uoKES8udsqdl for <rucus@core3.amsl.com>; Mon, 2 Mar 2009 07:35:01 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0A9B13A69AC for <rucus@ietf.org>; Mon, 2 Mar 2009 07:35:00 -0800 (PST)
Received: (qmail invoked by alias); 02 Mar 2009 15:35:25 -0000
Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 02 Mar 2009 16:35:25 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+BK6xGgKWB83aaC6CXNsrktq5fIX6hl892zlZJza ctIim90WMXCgPt
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: 'Hadriel Kaplan' <HKaplan@acmepacket.com>, 'Avasarala Ranjit-A20990' <ranjit@motorola.com>, sipping@ietf.org, rucus@ietf.org
References: <750BBC72E178114F9DC4872EBFF29A5B05F6EC3F@ZMY16EXM66.ds.mot.com> <E6C2E8958BA59A4FB960963D475F7AC314C19B93BB@mail>
Date: Mon, 02 Mar 2009 17:36:26 +0200
Message-ID: <024b01c99b4c$a70c9810$0201a8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC314C19B93BB@mail>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-index: AcmbExpd18YeURo2QKG8Gi9nzIAIBAALuTWQAAKgy7A=
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.47
Subject: Re: [Rucus] [Sipping] New Internet Draft for Caller Identity Blocking
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: Mon, 02 Mar 2009 15:35:05 -0000
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: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of Hadriel Kaplan >Sent: 02 March, 2009 17:12 >To: Avasarala Ranjit-A20990; sipping@ietf.org >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: sipping-bounces@ietf.org >[mailto:sipping-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 >Sent: Monday, March 02, 2009 3:45 AM >To: sipping@ietf.org >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 >sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP >
- Re: [Rucus] [Sipping] New Internet Draft for Call… Hannes Tschofenig
- Re: [Rucus] [Sipping] New Internet Draft for Call… Hadriel Kaplan
- Re: [Rucus] [Sipping] New Internet Draft for Call… Hannes Tschofenig
- Re: [Rucus] [Sipping] New Internet Draft for Call… Hannes Tschofenig