Ambiguity in H.225.0 Appendix D

[Chris Purvis]

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