Errors / ambiguities / problems found in specs at last, Re: Errors / ambiguities / problems found in specs at last

Paul Long plong at SMITHMICRO.COM
Wed Mar 15 13:19:53 EST 2000


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 at YAHOO.COM]
Sent: Tuesday, March 14, 2000 12:48 PM
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
   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.


More information about the sg16-avd mailing list