Chris...
I don't think we gauge final 'agreement' over the list, in any case I
believe the exact text for the implementers guide has to be
covered/approved at a Raportours' meeting and then ratified at a SG meeting.
I would propose that text be brought into the Montery meeting (along with
the collection of changes requested since the last SG meeting) and we
collectively go over it...
(BTW, I _think_ we do have agreement)
jimt.
At 07:31 PM 1/28/99 -0000, Chris Purvis wrote:
>Jim,
>
>Following discussion, I take the point.
>Do we take it that we have agreement over the original point, though? This
>was my proposal to change the documentation of what ports are used for what
>(1718 for multicast RAS messages, 1719 for unicast), especially with
>reference to the LRQ case? Do we have sufficient agreement for it to make
>it into the implementer's guide?
>
>Chris
>
>> -----Original Message-----
>> From: Jim Toga [mailto:jim.toga@intel.com]
>> Sent: 18 January 1999 6:33
>> To: Mailing list for parties associated with ITU-T Study Group 16
>> Cc: CPurvis(a)MADGE.COM
>> Subject: Re: Ambiguity in H.225.0 Appendix D
>>
>>
>> Chris,
>>
>> The problem is that it is a _client_ issue as much as a GK issue. The
>> (enterprise) site administrator, wants to be assured that no
>> rougue client
>> will get on the network and simple start conferencing... If he has
>> 'compliant' stacks than he can be assured that GK policy will
>> be followed....
>>
>> Regards,
>> jimt.
>>
>> At 05:59 PM 1/18/99 -0000, you wrote:
>> >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@INTEL.COM]
>> >> Sent: 15 January 1999 1:47
>> >> To: ITU-SG16(a)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@mailbag.cps.intel.com]On Behalf Of Chris Purvis
>> >> >> Sent: Thursday, January 07, 1999 9:33 PM
>> >> >> To: ITU-SG16(a)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@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
>> >>
>> >
>> +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
>>
>
+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
