Subject: [Sipping] Call diversion and charging, part 2

From: "Dale R. Worley" <[email-masked]>
Date: Sat, 03 Jun 2006 17:07:44 -0400

My rant of yesterday merely summarized what people have pointed out in
earlier messages, that identity-based charging, that is, tagging an
INVITE with the identity of the user that is responsible for the INVITEs
routing over this leg of its route, is fundamentally unworkable in the
general SIP environment, because no SIP agent has absolute control of
the downstream path of the INVITE.

(Such systems work in the PSTN because each agent that can affect
routing (either caller or diverter) knows that the call will go to the
destination it specifies, unless some downstream diverter takes
responsibility for charges on further legs.)

As far as I can see, the only effective solution is to tag messages with
authorizations-to-bill that are (or can be) established on a dialog-by-
dialog basis.  (A user agent could append a general authorization-to-
bill for charges that its user considers routine.  But authorization for
special charges needs to be dialog-by-dialog.)  But that leaves a lot of
interesting technical questions, especially how does one bind the
authorization-to-bill so that it can only be used to charge for the
services the billed-user intends?

The AtB needs to be bound to the dialog, so that it cannot be separated
from that dialog and applied to an attacker's INVITE.  At the least, it
needs to be bound to the media ports in the SDP, so that the SDP can't
be corrupted to allow the call connect users not intended.  And each AtB
needs to be limited in the charges it covers (time, media-bytes, or
monetary units), so a legitimate call cannot be extended afterward by an
attacker.

Ideas?

Dale

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Sun, 4 Jun 2006 09:03:43 +0300

> the downstream path of the INVITE.

in pure SIP environment where call does not end up in PSTN, there is no
need to charge for the CALL itself and thus no need for any AtB header.
if the SERVICE where the call terminates to, wants to charge the caller,
then the service would ask the caller for AtB and would tell how much
the bill would be.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 5 Jun 2006 15:44:08 +0300

Paul Kyzivat writes:

 > I think this is an important issue to work through, because ignoring it 
 > has caused so much trouble. I am less certain than Juha that there is no 
 > reason to charge for the call. 

how many providers charge per sent or received email message?  i don't
know any.  they may charge flat for the service itself, which is fine.

 > IMO it would be good to develop some sort of charging framework that 
 > makes sense. It is less clear to me what is the right forum for 
 > developing such a framework. IETF may well *not* be the right place.

there must already be work done somewhere on a general transaction
charging mechanism, where seller of service tells to the client how much
the service will cost and then the client will get a payment
authorization token from his bank or something and then passes it back
to the seller.  this kind of thing has nothing to do with sip.  it
applies to any web transaction too.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Jun 2006 08:13:22 -0400

I think this is an important issue to work through, because ignoring it 
has caused so much trouble. I am less certain than Juha that there is no 
reason to charge for the call. I believe that there must be provision 
for charging for services - giving everything away for free and making 
it up with volume, or funding everything with advertising has its 
limits.  OTOH it pisses me off when providers want to charge for 
services not provided.

	Paul

---

From: David R Oran <[email-masked]>
Date: Mon, 5 Jun 2006 10:31:50 -0400

On Jun 5, 2006, at 8:13 AM, Paul Kyzivat wrote:

> I think this is an important issue to work through, because  
> ignoring it has caused so much trouble. I am less certain than Juha  
> that there is no reason to charge for the call. I believe that  
> there must be provision for charging for services - giving  
> everything away for free and making it up with volume, or funding  
> everything with advertising has its limits.  OTOH it pisses me off  
> when providers want to charge for services not provided.
>
A good start would be to distinguish the cases which need the  
"Monica" property and those which do not.

("Monica" property is a now anachronistic reference to Hillary not  
being able to tell that Bill has forwarded his calls to Monica's place).

Right now the PSTN provides a "zero knowledge" solution to most/all  
cases of call forwarding.

> IMO it would be good to develop some sort of charging framework  
> that makes sense. It is less clear to me what is the right forum  
> for developing such a framework. IETF may well *not* be the right  
> place.
>
> 	Paul
>
> Juha Heinanen wrote:
>> Dale R. Worley writes:

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Jun 2006 10:18:46 -0500

I am taking no sides in this discussion, except to share the amazement that
so much effort goes into standardizing what is basically a function of the
receptionist workstation or SIP phone and can be dealt in the endpoint quite
reasonably well and needs no standards over the wire.

Now come the flames: All these specials that can be done only in the
network... Timber!

Thanks, Henry

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 05 Jun 2006 13:43:49 -0400

> need to charge for the CALL itself and thus no need for any AtB header.

That holds in a situation where the infrastructure isn't expensive, or
the service request can be fulfilled in an elastic way.  E.g., for e-
mail, it's quite acceptable to the user to have the message delayed a
few minutes.  Thus, e-mail is never the application that drives demand
for additional network capacity, and so its proper incremental cost is
zero.

But voice telephony has harder QoS requirements.  If the connection is
landline, that generally still doesn't make a difference.  But the
cellular system has real capacity limitations, so charging for carriage
on that last radio link is economically sensible.

> then the service would ask the caller for AtB and would tell how much

Yes, that's what AtB would be all about.  But how do we carry that
through the SIP dialog "pipe" like SDP?

More importantly, given the case you started the conversation with, how
does a "call divertor" substitute his AtB in replacement of the caller's
AtB?

> developing such a framework. IETF may well *not* be the right place.

It may be that the charging system is out of our domain, but we probably
have to consider how the AtB will be attached to the request/response.

> cases of call forwarding.

Without some sort of B2BUA, the Contact and SDP will reflect the real
"other end" of the call.

Dale