As far
as H.323 is concerned, all endpoints are H.323 endpoints. They are further
sub-qualified as either "terminals" or "gateways".
The
line becomes a little blurr when the physical device we are thinking of is a
telephone set behind some sort of IP PBX or Gateway. That telephone can even be
an H.248-controlled device. You could view the "proxy" as either a Gateway, an
MCU or a terminal, or even a combination of 2 or 3 of them depending on your
personnal preferences. Then there are glitches in the actual H.245 capabilities
to negotiate what these entities can support (I think we sorted that out for
v4).
In any
case, in H.323 terminology, the "endpoint" is the entity that will register
aliases with the gatekeeper. This alias can be completely abstract (in which
case the numbering plan and mapping to phone numbers themselves would be
provisionned in the gatekeeper), or it can be actual phone numbers. H.323v4
even allows for registering large ranges of numbers without explicitly
enumerating them (this is useful when you prefer to have the numbering plan
managed in each gateways as opposed to a cental gatekeeper).
In the
H.323 world, this is not really "third-party" registration since the H.323 proxy
is viewed as the first party (the fact that the media will be on different
devices is irrelevant). That being said, I would imagine that the same mechanism
could be used to register 3rd parties (real H.323
endpoints).
In my
opinion, I think all possible angles are covered in H.323v4... I wouldn't like
to have even more ways to do registration. If anything, we should probably look
into describing a little better how this is supposed to work to facilitate
interworking with gatekeepers. We did a little bit in v4 (for example on the use
of so-called prefixes, E.164 numbers, and private ISO/IEC 11571
addresses).
My 2
cents...
----
François AUDET, Nortel Networks
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.