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