Ambiguity in H.225.0 Appendix D

Chris Purvis CPurvis at MADGE.COM
Thu Jan 14 04:10:19 EST 1999


Kishore,

Looks a pretty good summary of our discussions - let's see what fallout it
generates!!!

Chris

> -----Original Message-----
> From: Kishore Babu Ramisetty [mailto:kish at TRILLIUM.COM]
> Sent: 13 January 1999 6:56
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Ambiguity in H.225.0 Appendix D
>
>
> 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
> >
>



More information about the sg16-avd mailing list