Minor H.225.0 Corrections

[Joerg Ott]

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 at tzi.org
Universitaet Bremen, Germany                              fax + 49 421 218-2085
TELES AG                                                voice + 49 421 218-7000