Third party registration/group registration

Agboh, Charles Charles.Agboh at GTS.COM
Fri Dec 1 06:26:36 EST 2000


Chris,

I am not a native English speaker (1/3), sorry for the mistake.   I
understand things better now.
Consider the following scenario;

A4:

An enpoint A (first-party) is switch off or does not "speak" H.323 (it
supports RAS).   I (third-party.  i.e.  IWF ) may want to be able to
register this endpoint which we will call EP A.    I register this endpoint
with its "well-known" alias address which is binded to a transport addresses
(not the one this EP usually uses when it is turned on. i.e.  transport
address of an H.323 complaint device like an answering machine called AM).
The GK will now be able to route the call for EP A to the AM.  For the EP
that does not "speak" H.323 the signaling will go to some entity that
will be able to "speak" H.323 and bind the RAS context created by the IWF
(this may be the IWF itself).


A5:  If I have a GK in my network, I may not allow "dubious" EPs to have
direct access to my EP.


Regards,

charles


-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at isdn-comms.co.uk]
Sent: Friday, December 01, 2000 10:31 AM
To: Agboh, Charles
Cc: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Third party registration/group registration


Charles,

I'll take these two mails together, as the point is the same.

H.225.0 section 7.7 states which RAS messages are mandatory, optional etc.
for
different H.323 devices.  By mandating the support of these messages, it
mandates the support of RAS, since  there is no proviso there for "when the
EP/entity is supporting RAS".

An aside, from a famous UK 80s sitcom on the subject of "clarification":
"You don't issue clarifications to MAKE things clear: you issue them to put
you
IN the clear."

Regards,
Chris

-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
Sent: Friday, December 01, 2000 10:46 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration


Paul,

I think we're starting to converge.  Let's separate this out now, into
separate
questions:

Q1. Are endpoint devices (in which term I include gateways etc throughout
this
mail) required to implement RAS?
A1. Yes (agreed between you and me, disagreed by Charles).

Q2. How does an endpoint device know whether or not a gatekeeper is present
in
the system, and hence whether or not to use RAS?
A2a (Your position as I understand it.)  Configuration, discovery on
startup,
give up if you don't find anything then.
A2b (My suggestion) Configuration, discovery on startup, retry at some
reasonable frequency (hourly?), take the three seconds to attempt gatekeeper
discovery when someone makes a call to or from the endpoint in question.
A2c (What we'll probably end up agreeing!)  Implementation decision.

Q3. What should an endpoint do if it attempts to register with all
discovered
gatekeepers, where there is at least one gatekeeper in the system, and fails
(RRJ)?
A3a (My position) Shut itself down.
A3b (Anybody elses) ???

Q4. Is Charles's actual application, where one entity is registering and
hence
presumably (although he's consistently failed to clarify) handling RAS on
behalf of another compliant H.323 endpoint a possibility?
A4a (My position, with which I THINK you agree) No, on the grounds that if
the
gateway/IWF can find a gatekeeper and use it, so can the endpoint.
A4b (Charles) Yes.

This actually gives rise to a further question, which is (I believe) open,
and
probably shouldn't be:
Q5. Can an endpoint be separated from its gatekeeper by a proxy?

Regards,
Chris

Paul Long wrote:
>
> 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

--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

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

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



More information about the sg16-avd mailing list