AW: [Sipping] Re: Questions on draft-jennings-sipping-pay-00

"Beck01, Wolfgang" <BeckW@t-systems.com> Mon, 25 October 2004 16:05 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09296 for <sipping-web-archive@ietf.org>; Mon, 25 Oct 2004 12:05:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7ZT-0001fj-Jz for sipping-web-archive@ietf.org; Mon, 25 Oct 2004 12:19:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM78u-00068i-EW; Mon, 25 Oct 2004 11:52:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6yZ-0004RR-Vt for sipping@megatron.ietf.org; Mon, 25 Oct 2004 11:41:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05539 for <sipping@ietf.org>; Mon, 25 Oct 2004 11:41:36 -0400 (EDT)
Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7C2-0000cB-B2 for sipping@ietf.org; Mon, 25 Oct 2004 11:55:34 -0400
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 25 Oct 2004 17:40:53 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <VS2HTF5G>; Mon, 25 Oct 2004 17:40:53 +0200
Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FDD3@E9JDF.mgb01.telekom.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: sipping@ietf.org
Subject: AW: [Sipping] Re: Questions on draft-jennings-sipping-pay-00
Date: Mon, 25 Oct 2004 17:40:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: fluffy@cisco.com
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

>On 7/15/04 3:01 AM, "Elwell, John" <john.elwell@siemens.com> wrote:

>> Cullen, 
>> 
>> 1. I see nothing to indicate what happens if the called user is busy, 
>> switched
>> off, etc. at the time the request with receipt arrives. This might be a
>> particular problem for the case where the UAS is a PSTN gateway, since it
>> probably won't check on the availability of the destination user before
>> sending the 402, so if the party is not available or busy it will 
>> probably still be not available or busy when the request with receipt 
>> arrives.

> yes - this is a somewhat fundamental limitation of the whole system. It
> somewhat assumes that if you pay, you will at least go to voicemail. Even 
> if the proxy found out if the UA was online, there is no  way to know if 
> the user will answer, or if they do answer, will they instantly hangup.

By the end of the month, the merchant presents his receipts to the Payment 
Service Provider and gets the money. The merchant (= the PSTN gateway 
provider) could choose to discard receipts for calls to unavailable 
destinations. 

When I wrote
http://www.potaroo.net/ietf/idref/draft-beck-sipping-svc-charging-req/
(http://www.ietf.org/proceedings/03mar/slides/sipping-8.pdf)
two years ago, I had such a scheme in mind. Re-INVITEs carrying receipts of
small sums could limit the damage for the caller if the called party cheats. 
 
As there is a financial incentive for malicious users, security is even more
critical than for other protocols. Installing malicious programs on a 
victim's PC that call expensive numbers is worse than just installing
DDoS bots (but perhaps clueless users will finally secure their system if they have to pay). On the other hand, will users accept a system where they
have to type in a password every time they make a call? Can 
http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-00.txt
help?

Besides Spam prevention, draft-jennings-sipping-pay allows new useful
services. 


Wolfgang

--
T-Systems
IP Platform Services
Am Kavalleriesand 3
64295 Darmstadt
Germany




_______________________________________________
Sipping mailing list  https://www1.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