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(a)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
