Jim (and all interested parties),
My comments below... (I'm cc' this sg16 list so that others will understand the 'tweaks' from what had been posted previously)
Fine.
- Your reworking of the UDP Port usage question appears to be
self-inconsistent and talks round the fundamental problem rather than fixing it (it both sanctions and forbids the use of port 1718 for unicast LRQ). The essential problem is that the usage of port 1718 is NOT directly related to the discovery issue. I believe my solution is clearer as well as requiring less in the way of changes in H.225.0.
I thought the fundamental problem was that a receiving GK had no reliable way to detect whether a message had arrived via multicast or unicast. Mythinking was that the multicastaddress:1718 VS the localaddress:1718, would be enough of a differentiator. In any case port 1719 was always relegated to unicast.
The point that came up at interop was that many IP stacks do not communicate to the app above them the difference between receiving on multicastaddress:1718 and localaddress:1718 - they map to sockets entirely based on port number. Hence to gatekeepers running on these IP stacks, messages received on localaddress:1718 will look like multicast messages.
I see your point, but I believe we cannot arbitrarily make unicast on port 1718 'illegal.' It is tighter ( and therefor not backward compatible) with current v1 and v2 specs. I also do not know the impact would be on existing products. I guess I would be more comfortable with a (strong) _should_ with respect to multi-cast only on port 1718. This by the way is why there is _should_ statement in the new existing text that I sent out. I will make these changes and see if they are acceptable by others.
How about a "shall" on transmitting on port 1718 for multicast, 1719 for unicast - but also require that gatekeepers will listen on both for unicast packets. The point is that with many IP stacks the gatekeeper can do no better than guess, but we might as well require future endpoints to give gatekeepers the best possible chance to guess right!
I would also suggest that continuing to call port 1718 the "UDP Discovery Port" and then giving example of LRQs (which are NOT discovery messages as I understand the term) being sent there will be rather confusing to someone reading the standard for the first time!
How about adding some text to my proposed solution, leaving it something like this (I quote the whole lot because not everyone's seen what I sent you before...): ---start soln--- Bring the standard into line with the most common usage by replacing the table from H.225.0 section 19.1.1.1 with the following: UDP Address for multicast communication with gatekeepers: 224.0.1.41 UDP port for multicast communication with gatekeepers: 1718 UDP port for unicast RAS communication where no other agreement exists: 1719 Note that "other agreement" may include registration of an endpoint with a gatekeeper.
A gatekeeper should treat GRQ or LRQ messages unicast to port 1718 as if they had been received by multicast. ---end soln---
This asks gatekeeper to behave in the "best" way that is possible with many IP stacks.
[Multiple aliases]
I am in favor of resloving this during the meeting.
I take it from this that you'd like me to present this as part of my submission.
Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com