Subject: RE: IP Telphony Gateway metering

From: "Rollender, Douglas Harold (Douglas)" <[email-masked]>
Date: Mon, 25 Jan 1999 15:20:39 -0500

And if the call is wireless and the user is moving......

	----------
	From:  Sujatha Balaraman [SMTP:[email-masked]]
	Sent:  Monday, January 25, 1999 2:55 PM
	To:  Jonathan Rosenberg
	Cc:  [email-masked]
	Subject:  Re: IP Telphony Gateway metering

	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:
	> > 
	> > 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
	> > > level of QoS, with an allowable small deviation.
	> > > This would take billing out of the gateway arena.
	> > 
	> > 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.
	> 
	> 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
	> 
	> ---------
	> This message came from the IETF IPTEL Working Group Mailing List.
	> 

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

	---------
	This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Guocai Deng <[email-masked]>
Date: Tue, 26 Jan 1999 17:21:05 +0800

Ping Pan wrote:

	>Guocai Deng wrote:
	>> 
	>>         I think you perference to Access Router. If the Acess
Router
> >>   integrited some components like gatekeeper, they do need to precess
> XML
> >>  messages because they usually have enough resource to do this. if the
> Access
> >>  Router does not integrite any components like gatekeeper, they need
> not to
> >>  process XML message, it can leave the job to gatekeeper or others. It
> just
> >>  need to act as an proxy authentication server and need simple info to
> get
> >>  the QoS parameters. it is the response to gatekeeper to translate the
> info
> >>  from XML format to some other simple message format.
> 
	> But the AAA protocol work for many applications outside access
networks.
	> We can envision the protocol is used to exchange information
between
	> carrier routers. Many peer-to-peer applications may take place
between
	> border routers. In that sense, I hope we are not restricting
ourselves
	> with some sophisticated format like XML.

	I think that AAA for Network Infra Providers and AAA for ITSPs
Services to end customer are different. They are  in different
	node in a  business link. ITSPs should pay to Network Infra
Providers, and VoIP users should pay to ITSPs. If ITSP and Network Infra
Provider are the same carrier, It can process the AAA for end customer and
AAA Between Network Infro Provider (Such as
	DS Domains) in different sectors. AAA Between Network Infra Provider
may be more aggr. than AAA between ITSP and end users, and when VoIP users
care of voice quality and price, they don't care of how to obtain the QoS,
how to offer the QoS leave
	to ITSP to care. 

---------

---

From: "Stephen Thomas" <[email-masked]>
Date: Wed, 27 Jan 1999 08:42:24 -0500

A couple of observations below.

-----Original Message-----
From: Henry Sinnreich <[email-masked]>
To: [email-masked] <[email-masked]>; Ping Pan
<[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Cc: Jonathan Rosenberg <[email-masked]>; Dean Willis
<[email-masked]>; Hoefelmeyer, Ralph (MCI) <[email-masked]>;
[email-masked] <[email-masked]>
Date: Tuesday, 26 January 1999 7:18 PM
Subject: RE: IP Telphony Gateway metering

|Pat wrote:
|>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 "simpler" protocols tend to work best when the
information to be parsed has a fairly simple structure. That is
certainly true today for dialup Internet access where the accounting
information is essentially just duration. I'm not certain that new
applications (such as multimedia over IP, to generalize the starting
point of this thread) will meet that same criteria. Considering the
multitude of variables that may be a part of accounting information
(e.g. layered media streams, various QoS attributes, network paths,
measured performance, ...) a way to encode a structure as part the
information might be essential. I suppose I'm suggesting that, in the
future, accounting information might be much more multi-dimensional
than it is today. XML is certainly one way to encode structure, others
exists as well (e.g. ASN.1). I have no credible opinion on whether
the dimensionality is handled by a "router" or an "AAA server,"
partly because I'm not sure the distinction between the two is
necessarily that clear.

[...]

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

There is a fair body of work already on embedded device and protocol
support for both ASN.1 and XML (to cite the two examples mentioned
above). Although not necessarily in the IETF (other than SNMP). ISO
and ITU-T have certainly spent a lot of time with ASN.1, and the
Wireless Application Forum (www.wapforum.org) has developed a
considerable body of work on embedded XML support.

Stephen

____________________________________________________________________

Stephen Thomas                                       +1 404 872 4745
TransNexus, Chief Technical Officer    [email-masked]
____________________________________________________________________

---------