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

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Oct 2004 12:53:57 -0700

Good points - inline ...

On 7/15/04 3:01 AM, "Elwell, John" <[email-masked]> 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.

> Trying later would help in some circumstances, but the draft suggests a window
> of only 30s between payment and accepting the request. Also the caller may not
> be interested later.
> 
> 2. It talks about a proxy in the same domain as the UAS performing UAS
> behaviour, but what about a proxy in the same domain as the UAC performing UAC
> behaviour? For example, a proxy in an enterprise may wish to  make payments on
> behalf of its users.
> 

Yes - I would like to make this work. I think is the next rev, perhaps, I
will move the transfer of the receipt to a header to make this possible.
Originally I was concerned about the consent aspects of this but as I looked
at how the OSP Token worked and a few other things, I suspect we can make
this work fine such that the outbound proxy for the UAC can make the payment
on the UAC's behalf.

> John Elwell ([email-masked])
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 25 Oct 2004 17:40:52 +0200

>> 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.

> 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

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 26 Oct 2004 13:21:50 +0200

hi wolfgang, 

thanks for pointing to saml-sip. in fact i have added a few lines to the
updated draft on the compensation issue (section 6.4 of
http://www.tschofenig.priv.at/drafts/draft-tschofenig-sip-saml-01.txt) . 
i agree with you that there is some potential for new services beyond just
spam prevention. 

ciao
hannes

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]
> Sent: Montag, 25. Oktober 2004 17:41
> To: [email-masked]
> Cc: [email-masked]
> Subject: AW: [Sipping] Re: Questions on draft-jennings-sipping-pay-00
> 
> 
> >> 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
> 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 

ciao
hannes

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>