As far as I'm concerned, a lightweight RRQ from an unregistered endpoint is about as valid as any other unexpected message from unregistered endpoints, i.e. invalid, and I have a strong urge to ignore them.
OTOH, if the Gatekeeper is interested in responding to lightweight RRQs subsequent to expiration of a registration, it's free to maintain the registered RAS address and endpoint id for as long as it wants. In addition, the politeness of such a Gatekeeper probably means that it should send a URQ to the endpoint prior to deletion of the registration information, so the situation should never arise.
Re-use of an endpoint id following deletion of a registration could cause problems where a Gatekeeper is indexing lightweight RRQ based on endpoint id. If a lightweight RRQ arrives from an expired endpoint after its endpoint id has been assigned to another endpoint, as currently defined the RCF (or RRJ) would end up being sent to the currently registered endpoint. This is a legitmate problem, although it's unlikely to arise and easy to design around without necessitating the addition of a response address to the RRQ.
Regards,
Dave Walker Mitel Corporation Ontario, CANADA
Espen Skjæran wrote:
Jim,
Concerning the use of lightweight RRQ:
A lightweight RRQ consists of (ref h225.0, 7.9.1 : "keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens, and timeToLive") A gatekeeper receiving a lightweight RRQ in cases the registration has aged (and is removed) has no information of where to reply to this RRQ. Using the gk discovery port and RRQ sender's IP address is not a good option.
Can we add rasAddress to this list in section 7.9.1 of H.225.0 ?
Espen