Charles,
> 1. EP S powers up (disabled RAS/not H.323 EP/....)
>
> 2. Registering Entity R is notified that EP is up (proprietary/standard)
>
> 3. Registering Entity R Registers EP S at GK G
>
> *4. Based on the defined third-party registration procedure, GK G is AWARE
> that EP S was registered by Registering entity R. GK G can exploit this
> feature
>
> 5. EP H sends an ARQ to GK G to call EP S
>
> 6. GK G (in DRC mode) confirms with an ACF.
>
> 7. EP H sends a setup message to EP S. In the case of theIWF, the setup
> message is sent to Registering entity R but, step for is still applicable at
> GK G.
Two cases.
If EP H sends setup to registering entity R, this is handled perfectly
adequately by the standard. No alteration to the standard is required.
If EP H sends setup to EP S, this IS what I would understand by third-party
registration. If EP S and registering entity R can not arrange to appear to
the gatekeeper to be a single entity ("as if", in the sense described by Paul
Long), more additions need to be made to the standard. However I am dubious of
this. I would suggest that interactions between R and S are in some sense
internal to an endpoint, and not suitable for standardisation (in the way that
a decomposed gateway has been considered suitable for standardisation). Others
may disagree. Given that you do so, I would suggest that your best way forward
is to make a formal proposal to an ITU experts' meeting as to how this could
work, why it is valuable etc.
Regards,
Chris
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Friday, December 08, 2000 11:03 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> 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(a)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@ISDN-COMMS.CO.UK]
> > Sent: Monday, December 04, 2000 2:26 PM
> > To: ITU-SG16(a)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@isdn-comms.co.uk]
> > > Sent: Monday, December 04, 2000 11:01 AM
> > > To: Agboh, Charles
> > > Cc: ITU-SG16(a)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@ISDN-COMMS.CO.UK]
> > > > Sent: Friday, December 01, 2000 3:36 PM
> > > > To: ITU-SG16(a)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@isdn-comms.co.uk]
> > > > > Sent: Friday, December 01, 2000 10:31 AM
> > > > > To: Agboh, Charles
> > > > > Cc: ITU-SG16(a)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@ISDN-COMMS.CO.UK]
> > > > > Sent: Friday, December 01, 2000 10:46 AM
> > > > > To: ITU-SG16(a)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@ISDN-COMMS.CO.UK]
> > > > > > Sent: Thursday, November 30, 2000 7:56 AM
> > > > > > To: ITU-SG16(a)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(a)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(a)mailbag.intel.com
> > > > >
> > > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > > listserv(a)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(a)mailbag.intel.com
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv(a)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(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)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(a)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(a)mailbag.intel.com
