Re: Errors / ambiguities / problems found in specs at last week's interop
How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?How do I unsubscribe?
Get the question NOW?
Thanks Stuart -----Original Message----- From: Sherlock, Stuart [mailto:stuart.sherlock@INTEL.COM] Sent: Monday, March 13, 2000 8:52 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Errors / ambiguities / problems found in specs at last week's interop
How do I unsubscribe?
Thanks Stuart
-----Original Message----- From: Gene Schroeder [mailto:erschroeder@LUCENT.COM] Sent: Monday, March 13, 2000 8:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Errors / ambiguities / problems found in specs at last week'sinterop
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
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
participants (1)
-
Sherlock, Stuart