Chris,
My comments below... (I'm cc' this sg16 list so that others will understand
the
'tweaks' from what had been posted previously)
Best Regards,
jimt.
At 12:18 PM 2/8/99 -0000, you wrote:
Jim,
I've drawn up a list of proposals for the implementer's guide, which I was
planning to put in as my own contribution. It can remain as a separate
contribution for the meeting, or some or all of it can be subsumed into
yours, as you see fit. I've attached it to this mail. Specific comments:
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. My
thinking 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.
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 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.
2. I've drawn something up on the multiple aliases question. I think
something ought to be agreed and put into the guide asap - and I think this
will only happen by being presented to a meeting and argued over. I'm happy
for this, as something a bit controversial, to be kept as my separate
contribution, but I'd like to think there was some chance of getting it into
the guide at this cut in some form or other.
I am in favor of resloving this during the meeting.
I'll put in my contribution, containing whatever you leave me, first thing
in MY morning tomorrow (ie the middle of tonight your time).
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
+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