Surely this could be left as a configuration option for the
administrator.
If he doesn't want the assurance you describe, why shouldn't
he be allowed
to configure it out of suitably-written gatekeepers? I
would expect it to
be an unusual thing to want to do, bearing in mind your
comments, but is it
the place of the standard to deny such possibilities?
-----Original Message-----
From: Jim Toga [mailto:jim.toga@INTEL.COM]
Sent: 15 January 1999 1:47
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: Ambiguity in H.225.0 Appendix D
There is a point behind having a GK respond to all GRQ messages.
The administrator must be able to be assured that
unauthorized endpoints
(with compliant stacks) do not conference. H.323 stipulates
that _if_ GKs
are present, then endpoints must use them.... so if the GK
are present and
none of them will allow a particular endpoint to register -
then it is not
supposed to make/receives H.323 calls.
The endpoint on the other hand, must be able to reasonably
detect the
difference between the complete absence of GKs and the
absence of 'their'
GK (especially if some specific control/policy is in place).
If the GK receives a GRQ, it must respond with a (directed)
GCF or GRJ.
jimt.
Hi,
This is wrt the second problem in the attached mail.
Chris Purvis mentioned that GK needs to know whether
a GRQ or LRQ is received via multicast or unicast so that
the response could be different.
Actually, H.323 V2 specifies different multicast and unicast
responses only in case of LRQ. In case of GRQ, spec specifically
mentions that even in multicast case a response shall be
given (Section 7.2.1 para three which _only_ talks about
multicast GRQs).
I believe spec should not mandate a GK to respond to
a multicast GRQ. It should be left to the implementor whether
a response should be sent out to a multicast GRQ or not.
The GK may have some additional information like redirecting
the endpoint to a different GK with altGKInfo etc, otherwise it
is just plain waste of bandwidth to mandate GK's to respond to
multicast GRQ's. The endpoints would time out if they
haven't received a single GCF.
May be the following line in para 3 of section 7.2.1:
"If a Gatekeeper does not want the endpoint to register to it,
it shall return Gatekeeper Reject (GRJ)"
should be changed to something like:
"On receiving a multicasted GRQ, if a Gatekeeper does not want
the endpoint to register to it, it MAY return Gatekeeper
Reject (GRJ)"
Comments?
Regards,
-Kishore.
-----Original Message-----
From: Mailing list for parties associated with ITU-T
Study Group 16
[mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis
Sent: Thursday, January 07, 1999 9:33 PM
To: ITU-SG16@mailbag.cps.intel.com
Subject: Ambiguity in H.225.0 Appendix D
We have had an ambiguity show up during interoperability
testing, which
I would like clarified by means of the implementer's guide
and future
versions of the standard. Any objections, please shout in
At 10:55 AM 1/13/99 -0800, you wrote:
the usual
way!
The problem comes in 19.1.1.1 where UDP port numbers are
defined. The
standard currently (I'm looking at version 2) says:
Gatekeeper UDP Discovery Port 1718
Gatekeeper UDP Registration and Status Port 1719
There are two problems with this. The first is that it
implies that the
LRQ message (which is nothing to do with discovery) always
needs to be
sent to port 1719, which is a problem for multicast LRQs,
because only
one IP address and port number pair has been registered with
the IETF -
224.0.1.41:1718.
The second problem is, if anything, more subtle... The
standard also
seems to imply by the above that GRQ, which is a
discovery message,
should always be sent to port 1718, whether it is sent to the
multicast
discovery port or not.
The reason this is a problem is that gatekeepers need to
know whether
these messages (GRQ and LRQ) have arrived by multicast or
by unicast,
because the failure response is different in the two cases
(no response
to a multicast xRQ, but xRJ response to a unicast xRQ).
The only
indication that most IP stacks give as to how a message
has arrived is
by a port number, however, so if all GRQs appear to port
1718 (and all
LRQs to port 1719), there is no way for the gatekeeper to
tell whether
the message arrived by unicast or multicast.
Common (but not universal - at least in products under
development!)
usage, driven by these practical considerations, seems to
be that the
most common implementations send both sorts of multicast
addresses to
the registered address - 224.0.1.41:1718, and unicast
GRQ and LRQ
messages to port 1719 (unless there is some private arrangement
specifying other special usage).
My suggestion is that this common usage is standardised,
initially via
the implementer's guide, and then when appropriate in future
versions of
H.225.0.
Regards,
Chris
+1-503-264-8816(voice) Intel - Hillsboro, OR
mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int
PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41
Chris Purvis