Jane,
A warning about your suggested use of lightweight RRQs, or keep-alives, to change registration parameters. This was discussed back in October on the H.323 implementors reflector. I agreed to put together some words to clarify this for H.323v4 but never did get around to it. Anyway, the consensus was that only the requestSeqNumber and timeToLive components of RCF are significant. If a GK wishes to change registration parameters, such as the security information that you mention, it must force the EP to unregister (URQ/reason=reregistrationRequired) and then register again. IOW, a lightweight RRQ does not actually "reregister" the EP. It sole purpose is to merely extend the duration of an existing registration.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Tuesday, March 14, 2000 12:48 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Errors / ambiguities / problems found in specs at last, Re: Errors / ambiguities / problems found in specs at last
Dear Mr. Gene,
There is an assumption in your theory that the endpoint may be doing a favor to the network by providing frequent keep alives. But, What I feel is, the TTL specified by the endpoint is the value it seems, it is going to be alive. (The definition of being alive here may mean the agreement duration with the service provider or it may be the time for which you are present in the cyber cafe...). This way, the endpoint is telling that it intends to use the services of the Gatekeeper for this much duration. Now, the Gatekeeper, in opposition to this, may say that I need to know every nth minute that you are still there. The reason may be, every nth minute, the gatekeeper will like to change the security information. By forcing the endpoint to reregister every nth second, it can change the security information. And, as you yourself have said that the Gatekeeper has better knowledge of the condition of the network. So, given the maximum time the EP wants to work with the gatekeeper, the GK may select the optimum value of the TTL, which will always be less than or equal to the TTL asked by the EP.
Please point out any mistake in this description.Your comments are most welcome.
Regards, Jane