H.323 Implementers Guide Edits
Greetings, After some delay, I have completed the edits coming out of the Monterey meeting for the Implementers Guide. Please review the changes and verify that everything is as expected. I have incorporated (I believel) all of the relevent text mentioned in the Meeting report namely: APCs 1511,1512, 1520, 1522, 1533, 1506, and TDs 10, 14, 33. If I do not have any comments back by 4/16/99 then I will integrate these changes with the complete document in preparation for the Chile meeting. Best Regards, jimt. MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7
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 Jim Toga wrote:
Greetings,
After some delay, I have completed the edits coming out of the Monterey meeting for the Implementers Guide. Please review the changes and verify that everything is as expected.
I have incorporated (I believel) all of the relevent text mentioned in the Meeting report namely: APCs 1511,1512, 1520, 1522, 1533, 1506, and TDs 10, 14, 33.
If I do not have any comments back by 4/16/99 then I will integrate these changes with the complete document in preparation for the Chile meeting.
Best Regards, jimt.
------------------------------------------------------------------------ Name: TD-implementers guide.doc TD-implementers guide.doc Type: Microsoft Word Document (application/msword) Encoding: base64
------------------------------------------------------------------------ MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7
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
participants (3)
-
Dave Walker -
Espen Skjæran -
Jim Toga