Paul,
Could we run into problems with some country actually using the extension field? (I think the US always defines it to be zero.) I don't see any other alternative, though.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] Sent: Monday, June 28, 1999 9:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: New T.35
Folks,
As many of you know, the latest T.35 document supports more than 254 country codes. In the newest document, T.35 says that one or two octets may be used to indicate the country code. If the first octet contains 1111 1111, the second octet will contain the country code.
Unfortunately, the syntax in H.245 does not utilize extension markers, so there is no place to hold second octet for the country code. Therefore, I would like to propose that, both for H.225.0 and H.245, we change the comments in the ASN.1 from:
t35CountryCode INTEGER(0..255), -- country, as per T.35 t35Extension INTEGER(0..255), -- assigned nationally manufacturerCode INTEGER(0..65535), -- assigned nationally
to the following
t35CountryCode INTEGER(0..255), -- country, as per T.35 Annex A t35Extension INTEGER(0..255), -- assigned nationally, unless the -- t35CountryCode is 1111 1111, in -- which case this field shall -- contain the country code found -- in T.35 Annex B manufacturerCode INTEGER(0..65535), -- assigned nationally
This may be a perversion of the t35Extension field, but we have a limited number of options if we wish to support the usage of two octets for a country code in H.245.
What are your opinions?
Best Regards, Paul