Third party registration/group registration

[Chris Wayman Purvis]

Charles,

I have no further comment on the subject unless and until you clarify the
following question, which I have asked repeatedly:
Endpoint S, registers using third party registering entity R at gatekeeper G
which uses the direct call model.  To which entity does H, an H.323 entity
wishing to call the user at S, send its setup message (the options as I
understand them being R and S)?

Incidentally I regard both applications given in your most recent email simply
as gatekeeper configuration.

Regards,
Chris

"Agboh, Charles" wrote:
>
> Chris
> Some applicaitons of third-party registration
>
> -secretary mode, where the secretary registers the current location
> (e.g., tel:) for his boss;
>
> - voicemail, where the voicemail system registers itself as a branch
> location
>
> regards,
>
> charles
> -----Original Message-----
> From: Agboh, Charles
> Sent: Thursday, December 07, 2000 3:57 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Chris,
>
> Some ideas about why I think this could be a useful feature.....
>
> It is the concept of third-party registration that I believe is not clearly
> (if at all) specified in H.323.  "In third-party registration, the entity
> issuing the request is different from the entity being registered."  This is
> not equivalent to hunting down the list of alternateEnpoints for an Endpoint
> I am trying to reach.    The key to this is who is requesting the binding
> between an alias address and a transport address.
>
> The entity making the request is using resources of the GK.  The GK may view
> the entity that is  being registered as a client of the entiry that made the
> request and may send CDRs  correlating the three parties entities.  The
> 3rd-party (as paul called it: the entity making the request) may be charged
> for using the GKs resources.
>
> Even though my friend bob has an H.323 complaint EP that is capable of
> registering itself, I (3rd-party: as paul called it) can register bobs alias
> at my GK and my GK will send CDRs to me at the end of *our* conference.
> Bob may inheret some of my priveleges as a result of my action.
>
> I don't have all the possible applications of this feature on my radar.
>
> Best regards,
>
> charles
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> Sent: Monday, December 04, 2000 2:26 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Charles,
>
> > I said that the "....H.323 EP must support RAS...".  We are down to the
> case
> > where the H.323 EP user has disabled RAS.
> I would argue that this means that the endpoint is not supporting RAS, and
> has
> become uncompliant...
>
> > Is it useful to have this feature (third-party registration) for this
> > specific case?  Its not defined in the standard and I think it should be
> > (i.e. From Pauls view, it could be useful for administrative reasons );
> > although there are ways to provide this feature in H.323v2 and H.323v4.
> Please expand on why you think it's a useful feature, and what you think is
> required for it.  I don't understand what you feel you need beyond what's
> already there.  If you are acting as a gateway/IWF then you are handling all
> call signalling, and the registration is not third-party.  If you are doing
> Paul's "as if" case then it isn't "as if" if it requires any modifications
> to
> the standard.  If you wish to do anything else, you need to tell us WHAT as
> I
> for one don't understand what you're trying to achieve (and calling
> "third-party registration") that doesn't come under the above headings.
>
> Regards,
> Chris
> > -----Original Message-----
> > From: Chris Wayman Purvis [mailto:cwp at isdn-comms.co.uk]
> > Sent: Monday, December 04, 2000 11:01 AM
> > To: Agboh, Charles
> > Cc: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Third party registration/group registration
> >
> > Charles,
> >
> > > By H.323 EP, I mean an H.323 EP that must support  RAS (by your
> > > interpretation of the standard), but the RAS function can be disabled by
> > the
> > > user (Pauls views ).  The GK is an optional H.323 entity.
> > I repeat that "The GK is an optional H.323 entity" does NOT imply "RAS is
> > optional in an endpoint".
> >
> > >>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.
> > > A4b Yes, the H.323 EP user may have disabled RAS or the H.323 EP is
> turned
> > > off (i.e.  SIP EP).
> > These are two complete separate cases.  We were discussing only the
> > (disputed)
> > case that the H.323 EP user has disabled RAS.  If the H.323 endpoint is
> > turned
> > off and a SIP endpoint is being used, the gateway is handling ALL H.323
> call
> > signalling on behalf of the SIP endpoint.  In other words the gateway is
> > terminating H.323 call signalling and, as far as H.323 is concerned, IS
> the
> > endpoint.  Or, to put it yet another way, the same device is handling RAS
> as
> > is
> > handling all other call signalling.
> >
> > Regards,
> > Chris
> >
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> > > Sent: Friday, December 01, 2000 3:36 PM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: Third party registration/group registration
> > >
> > > Charles,
> > >
> > > > I am not a native English speaker (1/3), sorry for the mistake.   I
> > > > understand things better now.
> > > I think we're getting closer now.  Don't worry about not being a native
> > > English
> > > speaker - please persevere.  I apologise if I've sometimes sounded harsh
> > in
> > > my
> > > responses - it's normally because I'm trying to make points quickly!  I
> > know
> > > communicating in a foreign language is hard - which is precisely why
> it's
> > > important to make sure that nomenclature is clear and unambiguous!
> > >
> > > > 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).
> > >
> > > Ah!  This is a COMPLETELY different scenario from that I was describing!
> > > This
> > > is simple.  All you are doing here is registering an alias somewhere
> > > different
> > > from what you may consider its "usual home".  The key to thinking about
> > this
> > > is
> > > that aliases are just that - they may only bind to particular devices
> for
> > > defined periods of time (the same user may use different endpoints on
> > > different
> > > days, but retain the same phone number).  The practicalities between IWF
> > and
> > > the "transport address this endpoint uses when it is turned on" may get
> > > somewhat hairy and certainly outside the remit of H.323, when it comes
> to
> > > ensuring that you don't have multiple devices trying to use the same
> alias
> > > in
> > > the same zone simultaneously (sadly not permitted).
> > >
> > > > A5:  If I have a GK in my network, I may not allow "dubious" EPs to
> have
> > > > direct access to my GK. <misprint corrected>
> > > True, but not addressing the question.  The question is whether it is
> > > permitted
> > > to separate EP and GK with a proxy.  I don't know the answer to this
> one!
> > >
> > > Regards,
> > > Chris
> > >
> > > > -----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
> > >
> > > --
> > > 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
> >
> > --
> > 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
>
> --
> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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