Subject: RE: Handling of Setup message by Gatekeeper.

From: [email-masked]
Date: Thu, 11 Mar 1999 17:15:37 -0800

How can Gatekeepers know that there are some endpoints in its zone not
registered? If GKs don't know their existence, then how can those endpoints be
managed?
Thanks for any information

Regards!

Hanlin

Deepak Kumar <[email-masked]> on 03/09/99 10:26:38 PM

To:   "'rtgupta @hss.hns.com'" <[email-masked]>, "ronald h. davis"
      <[email-masked]>
cc:   [email-masked], [email-masked] (Hanlin
      Fang/HQ/3Com)
Subject:  RE: Handling of Setup message by Gatekeeper.

Q.931 could originate at a rogue (ie. in the physical zone, but
unregistered, and doesn't send ARQ) end-point or an end-point/GK outside the
zone. Why is a distinction between these two scenarios meaningful?

An end-point that chooses (illegally) not to register with its Gatekeeper
could be treated exactly like an end-point outside the zone, and be denied
the benefits of Gatekeeper support - such as the ability to recv incoming
calls, QoS reservations, and the ability to place and recv calls using
network resources such as Gateways and proxies.

Deepak Kumar,

Program Manager, IP Telephony,
Windows Networking and Communications,
Microsoft Corp.

> -----Original Message-----
> From:   [email-masked] [SMTP:[email-masked]]
> Sent:   Tuesday, March 09, 1999 9:19 PM
> To:     ronald h. davis
> Cc:     [email-masked]; [email-masked]
> Subject:     Re: Handling of Setup message by Gatekeeper.
>
> Hi Davis,
>     Thanks for your inputs.
>
> I agree that GK is responsible only for the endpoints whixh exist in its
> zone. And also that it can not administer endpoints in other zones. But
> the
> scenarios mentioned in the query are all valid scenarios. GK CAN receive
> Setup message without any RAS signalling taking place before that. So it
> can not terminate h225 signalling channel because of absence of RAS
> channel.
>
> In contrast to what you said, I think RAS signalling is must for all the
> endpoints in any GK's zone. RAS signaling is not required for endpoints,
> outside the zone. Now when GK receives a Setup message, it doesn't know
> whether it is from its own zone or from outside. Before doing any further
> checks, it needs to check that. And as I mentioned in my previous mails,
> to
> do that, it needs to maintain a static databse of its zone. But there is
> no
> mandatory field in Setup message,giving source info. So basic question is
> how to perform this check.
>
> regards,
> Ritu.
>
> _____________________________________________________________________
> Ritu Gupta                                   |       email:
> [email-masked]
> Senior Software Engineer,       |                   [email-masked]
> Hughes Software Systems,     |       phone: 91-80-2286390/91/92(W)
> Banglore, Karnataka                  |                    91-80-3374075(H)
> INDIA.                                            |       Fax    :
> 91-80-2286393
> _____________________________________________________________________
> Restlessness and discontent are the first necessities of progress.
>
>
>
>
>
> "ronald h. davis" <[email-masked]> on 03/09/99 11:32:19 PM
>
> To:   [email-masked]
> cc:   [email-masked], [email-masked]
> Subject:  Re: Handling of Setup message by Gatekeeper.
>
>
>
>
> [email-masked] wrote:
> >
>                [scenarios deleted]
> > In all these cases, gatekeeper will receive Setup message without
> receiving
> > ARQ message. So how can gatekeeper check whether ARQ is expected from
> the
> > endpoint, which sent the Setup or not? No field in the Setup message
> seem
> > to give this information. If gatekeeper doesn't check for this, that
> means
> > even the endpoints in its own zone can bypass gatekeeper for RAS
> > signalling?
> >
> > Any help/information on this issue will be appreciated.
> >
> the gatekeeper is only responsible for arq/acf/arj with endpoints within
> its zone.  all endpoints within the zone establish a ras channel (over
> which these messages are sent) with their gatekeeper.
> endpoints in other zones don't establish a ras channel with this
> gatekeeper.  thus, when calls are received from outside of the zone
> the recipient (be through the direct or gatekeeper routed call model)
> has no idea how the calling endpoint came upon sending the setup
> message.
> this statement may be controversial but it is my opinion that h.323
> is lan-oriented, so if you think of gatekeepers as administering
> bandwidth allocation, &c for endpoints on different lans it would
> be difficult for a gatekeeper to perform this administration for
> a different lan.  and it would be even harder for a gatekeeper to
> perform such administration over a wide area network consisting of
> a number of zones.
> this fact leads me to believe that the ras channel should be *optional*
> for h.323 gatekeepers.  to abstract your scenarios further it is
> possible that gatekeepers could act as application layer routers, in
> which case they are terminating h.225 signalling and h.245 media control
> channels for endpoints with which they have no ras channel.
> --
>   __  ______  __  / __/ |       lucent technologies, naperville il, usa
> _/ (_(_) / (_(_/_/_(_/  .       [email-masked]
> "if you ain't the lead dog, the scenery never changes"  -- edmund wilson
>
>
>
>
> -------------------------------------------------------------------------
> for list subscription instructions,
> send email to [email-masked] with text "info"

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

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

---

From: Craig Strickland <[email-masked]>
Date: Fri, 12 Mar 1999 22:34:12 -0500

At 17:15 03/11/99 -0800, [email-masked] wrote:
>How can Gatekeepers know that there are some endpoints in its zone
>not registered? If GKs don't know their existence, then how can those
>endpoints be managed?

Actually, this question is "self-disproving", based on the definition of a
"zone" and the relationship of endpoints to the zone.

A couple of references from H.323 v2:

3.49	zone: A Zone (see Figure 3) is the collection of all terminals (Tx),
Gateways (GW), and Multipoint Control Units (MCU) managed by a single
Gatekeeper (GK).  ...  A Zone has one and only one Gatekeeper.

7.2.2	Endpoint registration
Registration is the process by which an endpoint joins a Zone  ...  As part
of their configuration process, all endpoints shall register with the
Gatekeeper...  Registration shall occur before any calls are attempted ...

Essentially, by the very definition of "zone", it's not possible to have an
unregistered endpoint "within" the zone.  A "zone" is comprised of a
[single] Gatekeeper and the [registered] endpoints it manages.

All other endpoints are, by definition, "out of zone".  Thus, there is no
semantic meaning for the phrase "unregistered enpoint within the zone".

Although I see where you're trying to go, the following phrase touches on
the goal of attempting to equate an H.323 "zone" with an administrative
"zone of control" (such as a LAN or LAN segment):

3.49	zone:  ...  A Zone has one and only one Gatekeeper. A Zone may be
independent of network topology ...

The latter statement makes it clear that the meaning of a "zone" differs
from the network layout.  There's nothing you can rely on in the contents
of an H.323 message that will reliably inform you if a non-compliant
("rogue") endpoint is being truthful about where it's located.  Many source
identification fields are optional, and if the endpoint is refusing to
RRQ/ARQ, then it's likely to lie about its identity as well.

The best you could hope for if you desired to treat a "rogue" endpoint
differently from an "outsider" would be to examine the transport layers'
information made available about the network connection -- the IP address
and TCP port number.  Assuming the endpoint is not performing "IP spoofing"
(a more difficult technique), the Gatekeeper could be provided with a table
of IP addresses or address ranges which are to be considered "insiders", as
contrasted to "outsiders".  That's probably just about your only option.
--
Craig Strickland
NetSpeak Corporation (home of WebPhone)
http://www.netspeak.com/

---------