Third party registration/group registration
Agboh, Charles
Charles.Agboh at GTS.COM
Thu Nov 30 08:09:43 EST 2000
Chris,
RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity.
charles
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
Sent: Thursday, November 30, 2000 12:49 PM
To: ITU-SG16 at 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 at ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 10:43 AM
> To: ITU-SG16 at 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 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
More information about the sg16-avd
mailing list