Third party registration/group registration

[Chris Wayman Purvis]

Charles,

In your definition of "third-party" registration, consider a scenario involving
four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a
gateway/IWF/registering-entity (C) and an entity of some sort on whose behalf C
is registering (which we'll call D).  Assuming that B is not routing
call-signalling, to which entity would A send its "Setup" message in order to
contact D?

If the answer to this question is "C", this is well-covered in the standard -
it is simply that the term "third-party registration" is not used for it.  It
is simply viewed as C registering (potentially) lots of aliases.  This
parallels Tom's second case.
If the answer is "D" (parallelling Tom's first case), then D is a very odd
device (it can't be a full H.323 implementation or it would register for
itself).  Why have a device implementing all of H.323 except gatekeeper
registration?  After all, D would have to handle all the rest of RAS for itself
- what would it be gaining by not registering on its own behalf?

In the same scenario, to what entities are you referring, respectively, as the
"third-party" in your latest contribution?

PLEASE clarify your definitions of "first-party" and "third-party" in cases
where you use these terms.  I am certain that the ends you are trying to
achieve are perfectly possible - and not even that hard.  Either will result, I
believe, in a brief discussion with early consensus emerging.  I believe the
problems, and the large amount of mail this is generating on this list, come
about entirely from the use of these terms without anyone understanding exactly
what is meant by them.

I agree with Tom that once we can agree on terminology we can move on quite
easily, and thank him for his usual high-quality clear-sighted input.

Regards,
Chris

------------------------------------


The registration feature allows endpoints to bind their identities to transport
address(es) at the GK.  This is well described in H.323.   When an endpoint
delegates another endpoint to perform this fearture on its behalf the
definition in H.323 is not there.   The signaling that follows the registration
whether, its
first or third-party may interrogate this binding.  The third-party
registration feature can enhance the user experience much more than a normal
first-party
registration.   I don't believe that the third-party has to be in the signaling
flow that may follow the third-registration.   I agree with Tom-PTs view.

Best regards,

charles

    -----Original Message-----
    From: Tom-PT Taylor [mailto:taylor at NORTELNETWORKS.COM]
    Sent: Wednesday, November 29, 2000 7:39 PM
    To: ITU-SG16 at MAILBAG.INTEL.COM
    Subject: Re: Third party registration/group registration

    Accurate terminology is obviously useful, but in this case, at least, it
looks like something people can agree on and then move on.  The more
    important point seems to be the underlying distinction in requirements:

     -- register on behalf of H.323 endpoints
     -- register on behalf of other endpoints
    where I use "other" in the sense that the contact address is associated
with a non-H.323 signalling protocol.  Purity is beside the point here --
    it's the intention of the contact address that matters.  Stating the
requirement in this way makes it obvious that the second requirement includes
    the need to state which protocol the endpoints expects to receive.

    There is another possibility, of course: use the same mechanism to satisfy
all requirements, and allow for the possibility that the endpoint
    supports multiple protocols.  I think the design would be cleaner if we
took the approach: one contact point, one protocol -- even if it meant
    repeating the contact information for each protocol a multiprotocol
endpoint supports.

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