Third party registration/group registration

van Schelven, Richard Richard.VanSchelven at MARCONI.COM
Thu Nov 30 08:37:33 EST 2000


Charles,

Only if a there is no Gateway!

Ries

> -----Original Message-----
> From: Agboh, Charles [mailto:Charles.Agboh at GTS.COM]
> Sent: Thursday, November 30, 2000 1:10 PM
> To: ITU-SG16 at 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 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
>

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