Errors / ambiguities / problems found in specs at last week's int erop

[Hutton, Charles]

Paul:

729 and 729A do indeed use the same encoder. Only the decoder is different.
Performance of 729A is poorer, particularly with respect to tandeming.

I can see that it may sometimes be beneficial to control whether the 729 or
729A algorithm (if a choice is available) is used by the decoder in order to
prevent significant degradation of audio quality. If that is a real
scenario, then it becomes more than "a local issue".

Perhaps others can comment on the "realness" of this possibility.


Charles (Chuck) Hutton
Strategic Architecture Engineering
Wireless Local Technology Group
AT&T Wireless Services
PO Box 97059
Redmond, WA 98073 (USPS only)
9461 Willows Road
Redmond, WA 98052 (FEDEX/UPS)
425-702-2938 Voice
425-702-2518 FAX
charles.hutton at attws.com

> ----------
> From:         Paul Long[SMTP:plong at SMITHMICRO.COM]
> Reply To:     Mailing list for parties associated with ITU-T Study Group
> 16
> Sent:         Wednesday, March 01, 2000 10:00 AM
> To:   ITU-SG16 at mailbag.cps.intel.com
> Subject:      Re: Errors / ambiguities / problems found in specs at last
> week's int erop
>
> 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 at etsi.fr]
> Sent: Wednesday, March 01, 2000 10:34 AM
> To: 'h323implementors at imtc.org'; 'ITU-SG16 at 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
>