Hi, Charles:
Pl. see the statement carefully. The use of RAS is Optional, but RAS needs
to be supported.
Thanks,
Radhika
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@gts.com]
Sent: Thursday, November 30, 2000 12:49 PM
To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM
Subject: RE: Third party registration/group registration
Hi Roy, Chris;
RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the
sigalals are incoming or outgoing. Please, just indicate where in H.323
RAS is mandated.
Regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Thursday, November 30, 2000 6:33 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Hi, Chris:
Yes, I do.
Regards,
Radhika
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk]
Sent: Thursday, November 30, 2000 12:01 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Cc: Roy, Radhika R, ALCOO
Subject: Re: Third party registration/group registration
All,
A clarification:
I am sure Radhika will agree that when he refers to call setup this includes
the case of incoming call setup as well as that of outgoing call setup!
Regards,
Chris
"Roy, Radhika R, ALCOO" wrote:
>
> Hi, All:
>
> Let me add a little.
>
> An H.323 entity needs to have the capability to support RAS messages.
> However, whether the RAS messages will be used or not before the call
setup
> is up to that entity.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Thursday, November 30, 2000 8:56 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> Charles,
>
> This comes up on this list every now and again, and the answer doesn't
> change.
> The gatekeeper is an optional entity: TRUE.
> RAS is optional: FALSE.
> Endpoints (including gateways, IWFs, whatever you want to call them) have
a
> responsibility of trying to find one, registering with one if it can and
> SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but
fails
> to
> register. Only if all reasonable attempts to find a gatekeeper fail
should
> an
> H.323 endpoint operate without an active registration.
>
> Let me give you the first couple of quotations from H.323 (I'm looking at
v4
> determined, but I don't believe this has ever changed) I find on the
> subject.
> They're in section 7.2.2:
> "As part of their configuration process, all endpoints shall register..."
> "Registration shall occur before any calls are attempted and may occur
> periodically as necessary (for example, at endpoint power-up)."
>
> Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS
> messages" as well.
>
> How else could things work? Consider the case where an endpoint (A) is
> trying
> to make a call to another endpoint (B). A issues an ARQ to its
gatekeeper,
> asking permission to try a call; the gatekeeper rejects the call (ARJ) on
> some
> reasonable grounds (possibly a conceptual "do not disturb" notice B has
set
> up
> with its gatekeeper). A thinks "stuff this", unregisters from its
> gatekeeper
> ("we don't want to worry about all that boring RAS stuff if it's going to
be
> inconvenient to us") and sends the Setup message to B anyway - resulting
(at
> best) in an disgruntled B.
> In other words, as soon as you allow endpoints to operate in the presence
of
> a
> gatekeeper without registering with it and abiding by its decisions, you
> might
> as well write all xRJ messages out of the protocol entirely!
>
> If an endpoint is going to ignore RAS (and hence the standard) then why
> should
> it bother having anyone else register on its behalf? I refer you to
> "Besides,..." in my last mail (which point you still haven't addressed).
>
> Regards,
> Chris
>
> "Agboh, Charles" wrote:
> >
> > 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(a)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(a)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(a)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(a)mailbag.intel.com
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv(a)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(a)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(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)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(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
