Errors / ambiguities / problems found in specs at last week'sinterop

[Gene Schroeder]

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 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
> 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:
> >
> > 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?).
>
> Chris
> --
> 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
>