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
------------------------------------------------------ Chris,
I agree that the scenario you mention (of the endpoint asking for a larger TTL than the gatekeeper wants) is the expected and most common one by far. However, there might be endpoints who believe they are doing the network a favor by providing frequent keep-alives (or who believe their status to be more important than the gatekeeper does). So in a case where the client says "my registration TTL is 5 seconds, and of course I'll be notifying you every 5 seconds that I'm still alive because I'm sure you will want to know," it is reasonable for the gatekeeper to respond with "no, please, your registration is good for 10 minutes, no need to burden yourself sending those keep-alives so frequently, really, I insist" (sort of like telling your kids to stop asking "are we there yet?" every 30 seconds while on a 2 hour trip). Of course, the endpoint might not get the hint and send keep-alives every 5 seconds anyhow. If the endpoint does get the hint, but is insulted by the insinuation, it could unregister and find someone else to play with (just as if the gatekeeper assigned the endpoint aliases it didn't like). This would seem to lead to better interoperability than to have the gatekeeper reject the RRQ, particularly since there is no explicit RRJ reason code to tell the endpoint what the problem is. Of course, the standard doesn't support this TTL negotiation scenario, but it still seems reasonable to me.
As I said, I believe that this really isn't much of a problem in practice, but the same issue has come up in other places. Like many other H.323 procedures, it's really just a simple case of the gatekeeper trying to use its broader knowledge of the network/service to manage it as effectively as possible, and for the endpoints to be good citizens and assume the gatekeeper knows best.
Gene
-----Original Message----- From: Mailing list for parties associated with ITU-T
Study Group 16
[mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of
Chris Wayman Purvis
Sent: Monday, March 13, 2000 12:38 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Errors / ambiguities / problems found
in specs at
lastweek'sinterop
Gene,
It Simply Doesn't Work Like That.
The endpoint WOULD be honouring the request if it
sent RRQs "too
frequently", by sending keepalive RRQs at least as often as
requested - which
is what the time the gatekeeper gives in RCF asks of it. In principle endpoints should give a time they think
is
incredibly long in RRQ (essentially they're saying "my timers will get
confused if you
ask them to run longer than this!"), and the gatekeeper cuts them
down to size,
saying "if you want to live in MY zone you'll behave yourself and
renew your
registration at least THIS often.". There is NO way in the standard
that a
gatekeeper can ask an endpoint not to send it RRQs at more than a
certain frequency
- and for good
reasons. And it would look a little odd if you were
allowed to
send "normal" RRQs arbitrarily frequently, but keepAlives mustn't
be more than a fixed
frequency.
If an endpoint's threatening to send keep-alives
every few seconds, as you
describe, and this is likely to cause you problems,
my advice would be to
reject the RRQ...
Chris
Gene Schroeder wrote:
One common reason the gatekeeper might want to
increase the
registration TTL
is to control the rate of incoming keep-alive
RRQs. If a gatekeeper has
many endpoints registered, and these endpoints
select a very
low TTL (say a
few seconds), then the gatekeeper will be forced
into
processing a high rate
of keep-alive RRQs. If the gatekeeper does not
require nor
need such timely
information on endpoint status, then IMHO it
should be able to specify a
higher TTL in the RCF. And it seems the endpoint
should honor
this request,
just as if it would honor a lower TTL.
Regards Gene Schroeder elemedia
-----Original Message----- From: Mailing list for parties associated with
ITU-T Study Group 16
[mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf
Of Chris
Wayman Purvis
Sent: Monday, March 13, 2000 9:02 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Errors / ambiguities / problems
found in specs at last
week'sinterop
Comments inline:
"Johan Gerhardsson (ETX)" wrote:
Hi folks,
To clarify things:
It seems that my writing was a bit sloppy when
I wrote the
problems about TTL and SEQUENCE OF... on the
interop. I intended
to describe two different problems:
- GK cannot increase TTL in RCF.
This is true.
- Mandatory parameters of type SEQUENCE OF
... can have empty list.
This is also true.
h323v2, 7.2.2: "The Gatekeeper may respond with an RCF
containing the same
timeToLive or a shorter timeToLive.".
As I see it, according to this, a GK is not
allowed to increase
the timeToLive value proposed by the endpoint in
RRQ, regardless
if the endpoint makes a full registration or a
keep-alive
registration.
I think it should be possible for the gk to do
it.
I disagree. As the endpoint is permitted to
renew its
registration any time up to the assigned time to live, allowing the GK to
increase time to
live would have no effect whatsoever (the endpoint would
send keepalives
at whatever
frequency it always wanted to). There would be
no effect, so
there's no reason to change.
As for your second point about SEQUENCE OF being
permitted to
have an empty list, this has always been the case. Is there a
specific problem
with this? It looks more like a (true) observation than a
problem to me! I
doubt you'll get ASN.1 changed in existing stuff to make
things SEQUENCE
[1..something] OF rather than SEQUENCE OF (even if such a
structure is
permitted - any ASN.1
experts wish to comment?).
Chris
%3.crumb=v8.e34f9bxp, 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 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com