Uploads

[Chris Purvis]

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.

>> 1. 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 at madge.com