Third party registration/group registration

[Paul Long]

Chris,

(You and I inadvertently replied to each other privately. I thought I'd
clean my email up a bit :-) and post it to the reflector.)

As you point out, gatekeepers are optional, but an endpoint may not be
registered with a gatekeeper (hence, an "unregistered endpoint"). I also
agree with you that an endpoint must implement and be able to use RAS. The
tricky part, though, is under what circumstances _shall_ an endpoint use
RAS, i.e., at least attempt to register with a gatekeeper. It may come down
to a rather philosophical question. If an endpoint is required to use RAS in
any way and ultimately discover and register with a gatekeeper only if there
is a gatekeeper in the "system," how does it know whether there is a
gatekeeper within the system without using RAS? Look like a Catch-22, but my
take on it is that whether a gatekeeper is in the system must be known out
of band. That's the only way I know of to resolve these otherwise
contradictory issues.

Smith Micro builds endpoints that can be used in systems with and without
gatekeepers. Because this vendor does not know whether the system within
which the user will be deploying the endpoint contains a gatekeeper, the
user presumably knows and has the discretion as whether to use RAS via a
Preferences dialog in the user interface. I think that's reasonable and
compliant. Some vendors may build endpoints that are designed to always be
used within systems that contain gatekeepers, and that's fine, too, and
compliant. However, IMO, besides probably being a bad marketing decision
:-), an endpoint that does not support RAS at all is not compliant.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
Sent: Thursday, November 30, 2000 7:56 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration


Charles,

This comes up on this list every now and again, and the answer doesn't
change.
The gatekeeper is an optional entity: TRUE.
RAS is optional: FALSE.
Endpoints (including gateways, IWFs, whatever you want to call them) have a
responsibility of trying to find one, registering with one if it can and
SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails
to
register.  Only if all reasonable attempts to find a gatekeeper fail should
an
H.323 endpoint operate without an active registration.

Let me give you the first couple of quotations from H.323 (I'm looking at v4
determined, but I don't believe this has ever changed) I find on the
subject.
They're in section 7.2.2:
"As part of their configuration process, all endpoints shall register..."
"Registration shall occur before any calls are attempted and may occur
periodically as necessary (for example, at endpoint power-up)."

Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS
messages" as well.

How else could things work?  Consider the case where an endpoint (A) is
trying
to make a call to another endpoint (B).  A issues an ARQ to its gatekeeper,
asking permission to try a call; the gatekeeper rejects the call (ARJ) on
some
reasonable grounds (possibly a conceptual "do not disturb" notice B has set
up
with its gatekeeper).  A thinks "stuff this", unregisters from its
gatekeeper
("we don't want to worry about all that boring RAS stuff if it's going to be
inconvenient to us") and sends the Setup message to B anyway - resulting (at
best) in an disgruntled B.
In other words, as soon as you allow endpoints to operate in the presence of
a
gatekeeper without registering with it and abiding by its decisions, you
might
as well write all xRJ messages out of the protocol entirely!

If an endpoint is going to ignore RAS (and hence the standard) then why
should
it bother having anyone else register on its behalf?  I refer you to
"Besides,..." in my last mail (which point you still haven't addressed).

Regards,
Chris

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com