Subject: RE: IP Telphony Gateway Billing

From: "Hoefelmeyer, Ralph (MCI)" <[email-masked]>
Date: Sat, 23 Jan 1999 20:28:15 -0000

Hello,

Why not do flat rate billing based solely on QoS?  The user signs up for a
certain QoS level, and all of their traffic is carried with at least that
level of QoS, with an allowable small deviation.
This would take billing out of the gateway arena.

Ralph

> -----Original Message-----
> From:	John Schnizlein [SMTP:[email-masked]]
> Sent:	Friday, January 22, 1999 5:42 PM
> To:	Sinnreich, Heinrich
> Cc:	[email-masked]
> Subject:	RE: IP Telphony Gateway Billing
> 
> Subtle change in the title because technical mechanisms for billing are
> appropriate for IETF discussion while pricing is a business function,
> which
> the IETF avoids because it could touch on anti-trust issues.
> 
> At 02:59 PM 1/22/99 -0500, Henry Sinnreich wrote:
> >
> >This is an interesting problem. 
> 
> It is interesting largely because the historical coincidence of call
> establishment, resource reservation, bandwidth consumption, and billing
> which occurs in traditional telephony does not apply to IP telephony. IP
> telephony can support calls that make no reservation (at the risk of poor
> quality), consume no bandwidth (during silence suppression), or incur no
> billing beyond that for IP-network access (when both ends are IP
> stations).
> 
> >Billing data and call admission can be done
> >in the gateway controller, be it a call agent, SIP server, or H.323
> >gatekeeper, but these devices do not control QoS in the network nor do
> they
> >guarantee QoS. 
> 
> In contrast to telephony's reservation by the call originator (and
> subsequent call-leg originating switches), resource reservation is made by
> the receiver in IP networks. This is a fundamental complication, but not
> necessarily one that demands new protocols.
> 
> >Let's use the term call agent. The call agent has first to
> >check with a policy server and also to find out if the QoS is indeed
> >provided by the transport layer, the routers and L2 elements underneath,
> >before charging for QoS. Would need actually to develop sort of a "call
> >flow" showing the interactions between the client requesting a call, the
> >call agent requesting QOS from the policy server, the reponses and
> exception
> >handling.
> >
> >Any thoughts on the message exchange regarding QoS for a call and for
> policy
> >decision (PDP and PEP - policy decision point and policy enforcement
> point)
> >and enforcement ? ...
> >Or can it be done in a simpler way, without requiring the tight coupling
> >envisaged above?
> 
> "Simpler way" is in the eye of the beholder. Is this simple enough?
> 
> The call agent must choose if the call is to have the QoS that requires
> admission control. If it does, it requires RSVP both ways between
> gateways,
> and it accounts for the call based on the QoS it required. If RSVP is
> invoked, the policy server that provides (via COPS) administrative
> admission control based on ability to pay may accumulate charges based on
> the reservation. Since reservations due to RSVP allocate the limited
> resource of the high priority bandwidth, they should incur charges even if
> used for applications other than IP telephony.
> 
> Call agents would be well-advised to use something like the Open
> Settlement
> Protocol to apportion or accumulate charges for call legs in multiple
> IP-telephony domains. The charges for calls should be sufficient to cover
> the charges for the underlying (RSVP) resource allocations (unless the
> business model has chosen a loss-leader for some business reason beyond
> what we discuss in IETF circles).
> 
> John Schnizlein
> Consulting Engineer
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 23 Jan 1999 23:12:10 -0600

Note the further slight change in subject. Billing, like pricing, is a
business issue. Metering is an engineering problem, and Lord Kelvin
would have it that measurement is a scientific one.

Ralph asked:

> Hello,
> Why not do flat rate billing based solely on QoS?
> The user signs up for a certain QoS level, and all
> of their traffic is carried with at least that

I believe the answer is "regulatory". US regulations require IXCs to pay
LECS on a per-minute basis for call termination. This fee is a MAJOR
component of the cost of a PSTN Long Distance call. Similar charges
apply for international calls. Bypassing such fees is the main goal of
near-term arbitrage players. I believe there is also a turnaround charge
where LECs are paying ISPs for local calls terminated by the ISP.

A gateway brings a call from Internet into PSTN or vice versa, which is
probably going to make it full into the same regulatory kettle.

So, we really need to meter gateway time. How it is
charged/billed/priced is really a business discussion best held in
another forum.

If there is not gateway, then really the only meterable service
delivered to a plain IP phone call is the QoS -- so we really need to be
able to meter QoS too.

---------

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 25 Jan 1999 06:03:22 -0800 (PST)

Actually, the IETF-accepted term (as far as I can tell) is "collection of
usage data", which can be used for capacity planning (of course, if you happen
to feed the data into your billing system, that's up to you :).

PatC

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jan 1999 14:28:40 -0500

> probably going to make it full into the same regulatory kettle.

I think that there is really more than one thing to bill for here, and
that different models (and metering requirements) apply to the various
components. The things you might pay for in an IP telephony environnment
are:

1. Qos in the IP network
2. gateway services
3. database queries (like name lookups)
4. execution of service logic (ala CPL)
5. proxy services (like some kind of mobility service in SIP)

Perhaps flat rate makes sense of QoS (I pay $29.95 a month for gold
service, $19.95 for regular, best effort). Dean gives good reasons why
flat rate might not make sense for gateways. For services like database
queries, things like per-minute billing don't even make sense, so flat
rate or per-transaction probably is more appropriate. Note that not all
of these components would be in every call; there are no gateways for an
IP to IP call. 

Nothing prevents your service provider from rolling up these various
services into one bill, but I think it would be nice to get these
different components from different providers if the customer wants.
Each, of course, requires monitoring and some means of reporting usage
statistics to some servers that collect the data and generate bills or
whatever. Based on this, it would make sense that (1) gateways report
usage statistics for gateway usage, (2) COPS servers or bandwidth
brokers or border elements provide QoS usage statistics, (3) and  SIP
servers/gatekeepers provide proxy, service logic, and perhaps database
query usage. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: Sujatha Balaraman <[email-masked]>
Date: Mon, 25 Jan 1999 11:55:23 -0800 (PST)

Would it be fair to meter a user's call on basis of his proximity to the
Gateway ? For instance, if a user utilises a gateway closer to him for a
destination which is pretty far from the gateway(say useing a longer
trunk) would he actually  be charged more by the gateway, in addition to
being charged more by the PSTN ? Also, considering that the longer the
distance covered on the IP in contrast to the PSTN, the quality of the
call is expected to be lower..., so would it be fair to assume that the
lesser number of hops or  distance,a call uses IP the network  , the more
expensive the call becomes.

This is just a thought, I want to know if it sounds reasonable ?

Sujatha.
------------------------------

On Mon, 25 Jan 1999,
Jonathan Rosenberg wrote:

> Date: Mon, 25 Jan 1999 14:28:40 -0500
> From: Jonathan Rosenberg <[email-masked]>
> To: Dean Willis <[email-masked]>
> Cc: "Hoefelmeyer, Ralph (MCI)" <[email-masked]>,
>     [email-masked]
> Subject: Re: IP Telphony Gateway metering
> 
> Dean Willis wrote:
> > 

******************************************************************************
Sujatha Balaraman              *  e-mail :[email-masked]
609, Anderson Road             *          [email-masked]
Apt: 287,                      *    
Davis                          *   Ph: 530-750-3897
CA  95616                      *      
*******************************************************************************

---------

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 25 Jan 1999 14:04:39 -0600

> 5. proxy services (like some kind of mobility service in SIP)

which is a nice summary. But, methinks he left one category off: Media
services.

Storage, retrieval, transcoding, splitting, recognition, ad nauseata are
all nifty things that can be metered, packaged, bartered and so on to
add value to basic call services.

There is no reason why any one call might not combine many services
across all (6) categories from many vendors, with different call
participants paying for separate subsets of the services utilized and
potentially with settlements between carriers/providers for some of the
services. Wow.

--
Dean

---------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 25 Jan 1999 16:02:23 -0500

It appears that for Internet-wide standard AA(A) and metering (instead of
the 3rd (A)), there is some work cut out for a possible BOF -> WG to agree
on

* Data excahnge with the AA(A) system,
* Data exchange with the policy server using COPS,
* Gateway metering,
* RSVP and/or DiffServ metering,
* IMHO a data format, why not XML?

Would be nice to agree on a framework and see if there is something missing
or has to be written.
Any interest in this?

Thanks, Henry

Jonathan Rosenberg wrote:
>it would make sense that (1) gateways report

and John Schnizlein has similar thoughts:
>admission control. If it does, it requires RSVP both ways between gateways,

>Call agents would be well-advised to use something like the Open Settlement

Pat Calhoun's perspective
>to feed the data into your billing system, that's up to you :).

has IMHO the outlook that for what usage you cannot bill, that usage is
still usefull for traffic statistics, and I tend to agree that such data can
be the obejct of a value added service.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Monday, January 25, 1999 2:29 PM
> To: Dean Willis
> Cc: Hoefelmeyer, Ralph (MCI); [email-masked]

---------

---

From: Ping Pan <[email-masked]>
Date: Mon, 25 Jan 1999 18:09:01 -0500

> * IMHO a data format, why not XML?

Hentry,

More importantly, we need to correlate metering information from
different applications. For example, SIP session duration is monitored
via some policy servers. However, the actual user data (with RSVP
enabled) may take a path that is completely different from what SIP
messages are going. The policy servers hence need to collect the data
information and map it to the corresponding SIP session to accounting
purposes. 

As for the data format, I have no problem with XML format if all network
components are a bunch of Unix/NT servers. For the conventional routers,
I doubt that they have spare CPU cycles to process XML messages. In the
future, I don't care if all routers run JAVA, but not for now, please.
:-) Why cannot we simply send more traditional protocol messages?

> Would be nice to agree on a framework and see if there is something missing

Isn't AAA group trying to put one together? 
 
> Thanks, Henry

Regards,

- Ping

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jan 1999 09:27:57 -0500

[email-masked] wrote:
> Henry,
> I know your feelings about XML, and perhaps you are correct, but I have a
> question. Is it really necessary for the router to spew out XML (pages?), as
> opposed to a much simpler (and easier to parse) protocol, and have the AAA
> server simply record the information in an XML format? It seems like this
> would be much simpler for the embedded devices, and it would solve your
> real-time usage viewing requirements.
> 
> Perhaps this thread really belongs in the AAA list.

Yup. iptel isn't doing billing, pricing, or metering.

-Jonathan R.

---------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 26 Jan 1999 08:36:15 -0500

Pat wrote:
>Is it really necessary for the router to spew out XML
> (pages?), as
> server simply record the information in an XML format?

I believe you have it right here, since changing the data format in routers
is simply not doable. We also don't yet understand or simply don't know the
computational load required by XML during peak traffic loads. Or the
scalability when handling 100k's of calls in the peak of the busy hour. If
however, XML is delivered by the AAA servers IMHO, we get the best of both
worlds.

>It seems like this

Next generation embedded devices could possibly use a common parser for
HTML, SIP and XML over a very thin operating system.
Would need to involve embedded device and protocol designers to explore the
best web-like approach.

Any other opinions on the list?

> Perhaps this thread really belongs in the AAA list.

Agree and have addedd <[email-masked]> in the header to see if
of interest.

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 26, 1999 8:46 AM
> To: Ping Pan
> Cc: Henry Sinnreich; Jonathan Rosenberg; Dean Willis; Hoefelmeyer, Ralph
> (MCI); [email-masked]

---------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 26 Jan 1999 15:54:59 -0500

> Perhaps this thread really belongs in the AAA list.

Agree and have addedd <[email-masked]> and <[email-masked]>
in the header to see if of interest.

Thanks, Henry

---------

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 1999 05:46:21 -0800 (PST)

Henry,

PatC

---------