Errors / ambiguities / problems found in specs at last week'sinterop
erschroeder at LUCENT.COM
Mon Mar 13 11:41:02 EST 2000
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.
> -----Original Message-----
> From: Mailing list for parties associated with ITU-T Study Group 16
> [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Chris Wayman Purvis
> Sent: Monday, March 13, 2000 9:02 AM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: Errors / ambiguities / problems found in specs at last
> 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:
> > 1) GK cannot increase TTL in RCF.
> This is true.
> > 2) Mandatory parameters of type SEQUENCE OF ... can have empty list.
> This is also true.
> > 1)
> > 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?).
> Dr Chris Purvis -- Development Manager
> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> Winkfield Row, Berkshire. RG42 6LY ENGLAND
> Phone: +44 1344 899 007
> Fax: +44 1344 899 001
More information about the sg16-avd