Errors / ambiguities / problems found in specs at last week's int erop
The following errors / ambiguities / problems were reported at last week's ETSI-TIPHON/IMTC interop event at ETSI: - 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. - H323: GK cannot increase TTL in RCF. Mandatory parameters of type SEQUENCE OF ... can have empty list. - 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. - In H.323, the destination address in UUIE in SETUP is mandatory, in H.225.0 it is not. - 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. - MCU should probably also have "prefix", not just the gateway. - Need BE message formats so that packet dumps can be quickly interpreted. - When using a GK, should the CRV in the admission and setup be the same? Reinhard Scholl ETSI
Reinhard, I have responded to each of the items you listed. - I've wondered myself why there is a separate codepoint for G.729a. From my understanding, the use of G.729 or G.729a is a local issue and does not change the bits on the wire. Maybe we need to state in a future version of H.323 that they are equivalent with respect to signaling. - Are you saying that a GK cannot return a TTL in RCF that is larger than the TTL in the corresponding RRQ or that it cannot subsequently increase the TTL without first having received a lightweight RRQ? I believe that a GK could return a larger value, but you are correct that there is no way for it to update this value without responding to a lightweight RRQ. I don't see how the mandatory-parameters issue is related to TTL. Regardless, this points out a general weakness in semantics for later additions to H.245 (since H.245v2) and especially H.225.0. IMO, the description of all SEQUENCE OF and SET OF components should include the semantics for these situations, even if it is "obvious" to the author what the semantics should be: - OPTIONAL component whose encoding is absent - zero components (empty) - exactly one component - more than one component - component order (we should also use SEQUENCE OF and SET OF where appropriate) We continue to have interoperability problems due to the differing interpretations as to what these mean. - Regarding call reference value, since H.323 is the top-level Recommendation that references H.225.0, if there is a conflict, H.323 is always normative. This is true in all referencing relationships between Recommendations, e.g., between H.225.0 and Q.931. - I can't find in H.323 where destinationAddress is required. H.225.0v2 does require it, though, "if available" (whatever that means). - The audio framing expressed in H.245 is _not_ ambiguous. It is clearly stated that this is the maximum framing. B.2.2.6/H.245v5: "When an H.225.0 multiplex is used, these numbers indicate the maximum number of audio frames per packet." The problem is that some _implementations_ do not support variable framing, e.g., some DSPs used in GWs can only process 30ms frames. Possible solutions: "fix" decoders so that they support variable framing, reframe into fixed-size frames before passing along to decoder, add ability to express fixed framing in H.245. - MCU prefix. I surprisingly have nothing to say about this one. :-) - What is a "BE message format?" - CRV. Wasn't this already described in a previous item? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Reinhard Scholl [mailto:Reinhard.Scholl@etsi.fr] Sent: Wednesday, March 01, 2000 10:34 AM To: 'h323implementors@imtc.org'; 'ITU-SG16@MAILBAG.INTEL.COM'; TIPHON_WG6 Subject: Errors / ambiguities / problems found in specs at last week's int erop The following errors / ambiguities / problems were reported at last week's ETSI-TIPHON/IMTC interop event at ETSI: - 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. - H323: GK cannot increase TTL in RCF. Mandatory parameters of type SEQUENCE OF ... can have empty list. - 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. - In H.323, the destination address in UUIE in SETUP is mandatory, in H.225.0 it is not. - 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. - MCU should probably also have "prefix", not just the gateway. - Need BE message formats so that packet dumps can be quickly interpreted. - When using a GK, should the CRV in the admission and setup be the same? Reinhard Scholl ETSI
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
participants (3)
-
Paul E. Jones -
Paul Long -
Reinhard Scholl