Hm, I wonder where this UUIE myth came from...

Glen,

I can not even imagine that the 131 as a max. size for UUIE was suitable for H.225.0V1 - was it ? (thinking on the various arguments with its sequences of alias addresses, etc.)

It would not have been sufficient and we did not decide this. This length (2-131) restriction applies only to the User-User information encoded following the original Q.931. If present, this original Q.931 UUIE information is contained in the "user-data" part of the "H323-UserInformation" structure (where you also find the appropriate limitation of 2-131 OCTETs in total).

I agree that using the single term user-user information for both original Q.931 and H.225.0 extended UUIEs may be somewhat misleading (as are the entries in the tables). Section 7.2.2.28 states pretty clearly that the length field shall be 2 octets, but the rest of the wording could use be improved. However, the maximum length is also stated in 7.3 of H.225.0v2 and was at least pointed at in Note 1 to table 5/H.225.90v1.

The number 131 comes from the max. length definition of UUIE out of ISDN UU Service 2 and 3.

I agree that we have to extend it in H.225.0V2.

Besides clarification of the text, I don't see anything that needs to be done here.

Also:

TimeToLive should be INTEGER(1..4294967295) instead of 4294967296.

While it is very convenient for an implementation to have the restriction to 2^32-1 as upper constraint of an INTEGER, from an ASN.1 encoding point of view a range from 1..2^32 may also be represented as four octets and thus would be ok (since it is the range that counts rather than the absolute max value). Nevertheless, for practical implementation considerations, I support Glen's idea, (particularly because it does not make any noticeable difference in semantics but makes life easier).

With the addition in V2 of supplementary services, fast call setup, and other items, the length of the User-user IE specified in the tables for each of the various Q.931 messages should be extended from 2-131 to something larger (any suggestions?).

The callReferenceValue definition (at least in ARQ) should be modified to remove the statement that the CRV comes from the Q.931 message.

If you find other needed corrections, please let me know.

Glen

Lior Moscovici wrote:

...

There are two corrections we would like to suggest in H.225.0: In the Endpoint structure: "destinationInfo" field should be "remoteExtensionInfo". This was our original intent in the Sunriver contribution, but we had a typo, we ourselves overlooked. We apologize for the incovenience. The change has to be reflected in the ASN.1 section. In the INAK PDU the field altGkIsPermanent should be OPTIONAL, as it is in all other reject PDUs.

Sincerely,

Lior Moscovici

Joerg

------------------------------------------------------------------------------- Joerg Ott jo@tzi.org Universitaet Bremen, Germany fax + 49 421 218-2085 TELES AG voice + 49 421 218-7000