Charles,
Only if a there is no Gateway!
Ries
-----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM] Sent: Thursday, November 30, 2000 1:10 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Third party registration/group registration
Chris,
RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 12:49 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
Charles,
The answer to your first question depends on the capabilities of D. RAS is OPTIONAL so I could have a D device that does not
implement RAS.
In my last email, the "third-party" would be a C device and
"first-party"
would be a D device (second-party is the A device) .
RUBBISH! RAS is NOT optional. See Table 18/H.225.0. Besides, how would your crippled H.323 endpoint tell its RAS handler to send the various RAS messages (like for instance ARQ to ask permission to make a call...)?
Regards, Chris
Regards,
charles
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 10:43 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration
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@NORTELNETWORKS.COM] Sent: Wednesday, November 29, 2000 7:39 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Accurate terminology is obviously useful, but in thiscase, 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 isassociated
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 samemechanism 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 amultiprotocol
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@mailbag.intel.com > >For help on this mail list, send "HELP ITU-SG16" in a message to listserv@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@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com