Subject: RE: IP Telphony Gateway Pricing

From: Guocai Deng <[email-masked]>
Date: Fri, 22 Jan 1999 11:01:30 +0800

Dear Sujatha,

     I think that pricing is Gatekeeper-Centered instead of
Gateway-Centered. Whenever IP User or PSTN user to use IP telephone,  they
must pay for some QoS calling. 

     Current vendors mainly offer a solution with one-tier pricing model, i.
e. one Operation Center Offer traffic table about all Gateway or Gatekeeper.
There is a serious scabability problem. 

     I think that pricing need leaf-gatekeepers to negotiate during
Capability-Exchanging. Pricing procedure should result some info about
Fee/QoS, the settlement Point( Accouting Server). These info can be arranged
in Tree-Table format.

     But I am not sure how those affect the performance and traffic.

	-----Original Message-----
	From:	Sujatha Balaraman [SMTP:[email-masked]]
	Sent:	Friday, January 22, 1999 3:51 AM
	To:	Jonathan Rosenberg
	Cc:	xmzhao; [email-masked]
	Subject: 	IP Telphony Gateway Pricing

	Hi,
		I"m trying to formulate a pricing model for the Telephony
Gateway
	based on QOS offered. I am pretty confused on the type of topology
to use
	to simulate the same. Does anyone out there have any idea on the
type of
	topology/traffic to simulate to test the same. Can you also suggest
any
	papers which study Gateway Location and pricing using simulation
results
	with description of simulation model.

	Thanks
	Sujatha. 

****************************************************************************
**
	Sujatha Balaraman              *  Networks Lab
				       *  UC Davis.
				       *  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: "Henry Sinnreich" <[email-masked]>
Date: Fri, 22 Jan 1999 14:59:32 -0500

> must pay for some QoS calling.

This is an interesting problem. 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. 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 ?
See http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt
Or can it be done in a simpler way, without requiring the tight coupling
envisaged above?

Thanks, Henry

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Guocai
> Deng
> Sent: Thursday, January 21, 1999 10:02 PM
> To: Sujatha Balaraman; Jonathan Rosenberg
> Subject: RE: IP Telphony Gateway Pricing
>
>
> Dear Sujatha,
>

---------

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 22 Jan 1999 14:49:11 -0800 (PST)

> call agent requesting QOS from the policy server, the reponses and exception

Presumably, when the policy engine is asked to authenticate and authorize the
user, it can determine whether QOS is required for the user. The Policy Server
can then "push" the QOS information to the network.

This is one of the reasons why an AAA protocol must be able to allow the
server to send unsolicited messages down to the clients.

PatC

---------

---

From: Jim Toga <[email-masked]>
Date: Fri, 22 Jan 1999 16:35:33 -0800

This is one of the reasons that the admission request in H.323 has a
generic QOS flag to indicate client or GK control. (Subsequent to that some
form of RSVP or its ilk occurs along with SBM or some other policy engine....)

jimt.

>server to send unsolicited messages down to the clients.

[SNIP]

+1-503-264-8816(voice)              Intel - Hillsboro, OR
 mailto:[email-masked]         mailto:[email-masked] 
 PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 

---------

---

From: John Schnizlein <[email-masked]>
Date: Fri, 22 Jan 1999 19:42:23 -0500

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
>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
>and enforcement ? ...

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