Re: Errors / ambiguities / problems found in specs at last week's interop
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. 2) Mandatory parameters of type SEQUENCE OF ... can have empty list. 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. Sorry about the late answer and confusion. Best regards /Johan Johan Gerhardsson Software developer Ericsson Telecom AB Data networks, IP telephony Phone: +46 (0)8 719 2396 ECN: 850 92396 email: Johan.Gerhardsson@etx.ericsson.se -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: den 2 mars 2000 08:01 To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Errors / ambiguities / problems found in specs at last week's interop Reinhard, Thanks for raising these issues. I'll throw out a few responses and let folks debate a little. If the points are confusing, I'll bring the issues to the next meeting for inclusion in the Implementers Guide.
- Terminal capabilities for G.729 and G.729 Annex A. Though mutually compatible, TCS often fails if vendors only specify support for one or the other. E.g. 729 <--> 729a should work but TCS fails.
Folks have responded to this issue: it definitely needs correction.
- H323: GK cannot increase TTL in RCF. Mandatory parameters of type SEQUENCE OF ... can have empty list.
It is definitely true that the GK may not return a higher TTL value. As for the rest of that sentence, are you referring to a different problem or something related to TTL?
- H.225 says that call reference value should be same in ARQ and SETUP. H.323 says that call reference value should be different in ARQ and SETUP.
Can you give me the reference in H.323. The CRV in the ARQ and the SETUP message are supposed to be the same. If H.323 says something to the contrary, it is wrong. You may be referring to this sentence in 7.4: ``There is one CRV for the Call Signalling Channel and an independent CRV for the RAS channel.'' That sentence does not mean that the values are different, it's just that they are logically independent. On the calling side, the CRVs are the same value (as specified in H.225.0). On the called side, the CRVs on the Call Signaling Channel and the RAS channel are indeed different values. 7.4 of H.323 also say to "refer to Recommendation H.225.0", as it is the protocol that specifies the assignment of those CRVs.
- In H.323, the destination address in UUIE in SETUP is mandatory, in H.225.0 it is not.
If that information is available, it is supposed to be provided according to H.225.0. Can you refer me to the specific clauses that are controdictory?
- H.245: if a capability being sent includes G.711 "20 msec", the other side may think that the sender supports both "20 msec" and "10 msec" rates. But it can be that the originator supports only 20 msec. Ambiguity.
Perhaps I don't understand the issue here. What is conveyed in H.245, I believe, is the maximum number of audio frames per RTP packet. So, if one endpoint says it can support 2 frames and other states that it can support 4 frames, the common modes would be 1 or 2 frames per packet. Is that not correct?
- MCU should probably also have "prefix", not just the gateway.
That might be desireable. H.323v4, however, has added some new fields that will probably make this a non-issue.
- Need BE message formats so that packet dumps can be quickly interpreted.
I'm not sure I understand the question here. BE? Are you referring to an Annex G Border Element or something else? (It's now approaching 2AM my time, so I may not be thinking as clearly as I should :-)
- When using a GK, should the CRV in the admission and setup be the same?
Yes. However, they called party will select a unique CRV when it communicates with its GK to accept the call. Best Regards, Paul
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
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:
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
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:
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
-- 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
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
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
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
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:
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
registration TTL processing a high rate this request, 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
-- 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 (3)
-
Chris Wayman Purvis -
Gene Schroeder -
Johan Gerhardsson (ETX)