Third party registration/group registration

Chris Wayman Purvis cwp at ISDN-COMMS.CO.UK
Fri Dec 1 09:24:26 EST 2000


Francois,

GCF from a gatekeeper certainly does NOT guarantee that the following
registration will be permitted.  A gatekeeper may allow an endpoint to attempt
to register and then refuse the registration for any reason.

However, from the point of view of my position on Q3, GRQ-GRJ should be treated
the same as GRQ-GCF-RRQ-RRJ in my view.

Regards,
Chris

BOUGANT François FTRD/DAC/ISS wrote:
>
> Chris,
>
> I don't understand your position on Q3. An endpoint shall attempt to
> register with all discovered GKs (at least one) only if this endpoint has
> received at least one GCF message from any GK. My understanding is that a GK
> returning a GCF message to an endpoint (after having previously received a
> GRQ message from this endpoint) is active and implicitly ready to register
> the endpoint; if not the GK shall return a GRJ message. The RRJ message is
> used by the GK to indicate that the registration has failed and indicates
> the reason. I think that the endpoint shall re-send a RRQ message with
> corrections (when possible). If the rejection occurs several times, the
> endpoint may shut down to re-initialize and re-start the GK discovery
> procedure.
>
> Regards,
>
> François BOUGANT
> & France Télécom R&D
> FTR&D/DAC/ACE
> e-mail : francois.bougant at francetelecom.fr
> 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex
> 9
> Phone : (33) 1 45 29 51 84
> Fax   : (33) 1 46 29 31 42
>
>
> -----Message d'origine-----
> De : Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> Envoyé : vendredi 1 décembre 2000 10:46
> À : ITU-SG16 at MAILBAG.INTEL.COM
> Objet : 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

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



More information about the sg16-avd mailing list