Ambiguity in H.225.0 Appendix D

Chris Purvis CPurvis at MADGE.COM
Mon Jan 18 12:59:30 EST 1999


Jim,

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?

Chris

> -----Original Message-----
> From: Jim Toga [mailto:jim.toga at INTEL.COM]
> Sent: 15 January 1999 1:47
> To: ITU-SG16 at 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.
>
>
> At 10:55 AM 1/13/99 -0800, you wrote:
> >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 at mailbag.cps.intel.com]On Behalf Of Chris Purvis
> >> Sent: Thursday, January 07, 1999 9:33 PM
> >> To: ITU-SG16 at 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
> 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 at intel.com         mailto:james.toga at ties.itu.int
>  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41
>



More information about the sg16-avd mailing list