New subject: Third party registration/group registration

30 Nov 2000

      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@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@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
...
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
order
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 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@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.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.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

Re: Third party registration/group registration

Roy, Radhika R, ALCOO

Chris Wayman Purvis

tags

participants (2)