Subject: RE: VOIP question ??

From: Ami Amir <[email-masked]>
Date: Thu, 28 Jan 1999 20:14:06 +0200

Ronald,

Since I was present on the H.323 scene from its early days, I beg to differ:

1.	The Gatekeeper's function from day one was ADDRESS RESOLUTION (even
the name was driven by the function of Gateway Keeper).
2.	As to the specific problem - any of the currently commercially
available gatekeepers provide support for PBX to PBX connections. There will
be problems when the connection spans very large networks that are
multi-zonal and inter-company. The original spec did not attempt to resolve
these issues, and hence additional work is required (be it intergatekeeper
work in the ITU or the iptel work in the IETF).

Regards

Ami

	-----Original Message-----
	From:	ronald h. davis [SMTP:[email-masked]]
	Sent:	Thursday, January 28, 1999 7:23 PM
	To:	Ami Amir
	Cc:	[email-masked]; [email-masked]; Sebastien
Ducarne; IP Telephony
	Subject:	Re: VOIP question ??

	Ami Amir wrote:
	> 
	> Hi All
	> 
	> Once you walk through and analyze the situation, you will find out
that a
	> Gatekeeper is really needed.
	> 

	h.323 was defined for non-qos lans, so as far as i am able to tell,
the
	gatekeeper function arose from the need to manage bandwidth on a
lan.
	this was accomplished through the use of a ras channel and
registration
	and admission procedures as defined in h.323.

	when connecting gateways/endpoints on a wide area network, this role
of
	the gatekeeper becomes a bit harder to define...

	from what i can tell, you're suggesting the role of the gatekeeper
is
	a sort of application-level router.  this is certainly a valid role
	but it can be achieved by h.225 call signalling, and h.245 control
	channels only - there is no need for a ras channel.

	at the network level there is a need for these application-level
	routers to be able to exchange information, both within an
	administrative domain, and between administrative domains.  this
	creates a role for ospf and bgp equivalent protocols that allow
	for the exchange of information.  the inter-domain problem is
currently
	being addressed by both itu study group 16, h.225 annex g, and by
	the ietf iptel wg, gateway location protocol).  there is also a
proposal
	before iptel (which has been tabled for now while they work on glp)
to
	address the intra-domain problem, peer gatekeeper routing protocol
	(which is horribly misnamed because it really isn't limited to h.323
	gatekeepers anyway).  there's also an i.now! proposal which is based
	upon a clearinghouse model.  but the objectives of these protocols
is 
	different from the objectives of the h.323 gatekeeper ras channel.  

	so while i see there is a role for an application-level router,
which
	you may call a gatekeeper is you wish, to me, the term gatekeeper
	comes with loading of ras channel functionality that must be
supported
	(at least according to h.323).  this functionality seems largely
	unnecessary in the scenarios that you described.

	-- 
	  __  ______  __  / __/ |       lucent technologies, naperville il,
usa
	_/ (_(_) / (_(_/_/_(_/  .       [email-masked]
	"if you ain't the lead dog, the scenery never changes"  -- edmund
wilson

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

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

---

From: "ronald h. davis" <[email-masked]>
Date: Thu, 28 Jan 1999 13:15:35 -0600

> the name was driven by the function of Gateway Keeper).

could you explain why bandwidth was made a mandatory element in an
admission request (arq) (along with other bandwidth management
gatekeeper procedures)?  in fact, was arq necessary at all?
address resolution could be accomplished by a location request (lrq)
and no arq.  but it was not until a later version of h.323 that i saw 
the capability added that allowed zone members to register with 
pre-approved arq.

i'm not denying the address resolution role of the gatekeeper, i'm
just questioning the need for the ras channel, which every h.323
gatekeeper must support.

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       [email-masked]
"if you ain't the lead dog, the scenery never changes"  -- edmund wilson

---------

---

From: Bjarne Munch <[email-masked]>
Date: Fri, 29 Jan 1999 09:23:42 +1100

Hi,
This is interesting, even though it's morning and I'm half asleep.

I am thinking about Ronalds remark about application level routing and the need
for protocols similar to OSPF and BGS, or even the emerging Gateway Location
Protocol.

I see a strong need for address resolution from E.164 number plans, and I can
also
see the need to structure an IP Telephony network in some hierarchy. This is
partly to provide a scalable E.164 routing, but just as much to allow an
operator
to implement certain business rules. Such business rules would be related to
a per minute cost for terminating a call towards specific destinations,
receiving
calls from other destinations, inter-operator domain operability etc.

The question that occur to me is how much control will the operator wish to
have over this IPT network ? And how much self discovery and routing
adaptability
will an operator wish to have?

Call me a 'bell-head' but as an example; implementing an automatic gateway
discovery may limit the possibility for operators to control the cost structure
for
terminating and originating calls to/from these gateways.

I dont see this as a part of H.323, but rather the routing applicating utilising
H.323.
And this routing application does not nessecarily require an 'adaptive' routing
protocol.

Cheers
Bjarne Munch

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Jan 1999 23:20:15 -0500

> terminating and originating calls to/from these gateways.

The assumption of adaptive routing and management/control being mutually
exclusive is not accurate. Existing IP routing protocols are usually
tied to policy decisions in routers. For IP telephony, the "routing"
protocol (GLP) allows a Location Server  (gatekeeper or SIP server in
most cases) to have a set of gateways from which it can make policy
decisions, resulting in a final routing table.

> And this routing application does not nessecarily require an 'adaptive' routing

GLP is neither part of H.323 or SIP, and neither does it utilize them.
Rather, a gatekeeper or SIP server would make use of GLP as a method for
constructing routing databases (and perhaps not the only means of
constructing the database).

-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

---------