Error in H.323v3 ASN.1

[Paul E. Jones]

Folks,

I heard a number of comments from people expressing their concerns over this
matter.  I believe that most people just want to have a resolution, rather
than debate the technical merits of one solution or another.

I know that a few people will not like this, but my recommendation is that
we correct H.225.0v3.  I believe that this would be the fairest solution,
given that there are H.323v2 implementations in the field which expect the
ASN.1 encoding as detailed in the H.323v2 implementers guide and which is
inconsistent with H.323v3.  While H.323v3 has been decided for a year now,
it seems that products are just now emerging, so the impact is less
significant.

Bear in mind that my recommendation is merely that: a recommendation.  I
will present my recommendation at the Rapportuer's meeting and/or the ITU-T
SG16 meeting in November.  The final decision on this matter will not be
official until that time.

However, I would rather have the support of the H.323 community now, rather
than a month from now, so that those interested parties trying to bring
their H.323v3 products to market can rest assured that their ASN.1 syntax is
final.

I have already updated my copy of the Implementers Guide and the ASN.1 file
for H.225.0v3 on Packetizer to reflect my proposed change (see
http://www.packetizer.com/iptel/h323/h2250v3.asn).

Again, this change is intended to be "fair", giving consideration to
equipment that is older and already in the field, which is almost always
more difficult to change than recently released or emerging products.  In
addition, the error here truly is in H.225.0v3, not H.225.0v2, so it is more
logical to make the correction in H.225.0v3.

Best Regards,
Paul

----- Original Message -----
From: "Paul E. Jones" <paulej at packetizer.com>
To: "XuPeili" <xupeili at huawei.com>
Cc: <h323implementors at imtc.org>; <ITU-SG16 at mailbag.cps.intel.com>;
<h323implementors at pulver.com>
Sent: Wednesday, October 04, 2000 1:35 AM
Subject: Error in H.323v3 ASN.1


> XuPeili and other H.323 Developers,
>
> This does appear to be in error.  Unfortunately, this was published this
way
> in the H.225.0v3 Recommendation.  However, you are correct that a previous
> H.323v2 Implementers Guide was published which contained the
> aliasesInconsistent field.
>
> So, we have an issue to contend with.  I must ask the developer
community--
> I do not want to make this change without wide support for making such a
> change.
>
> Since the Version 2 field was added via the Implementers Guide, it is
> entirely possible that H.323v2 vendors did not even include it in their
> ASN.1
>
> So, I need to hear from all of the developers on this issue.  This may
have
> been addressed, but I don't have notes on this matter.  A similar issue
with
> the LocationRejectReason was found and I corrected that back in June when
> discussing with everybody that "I would never change the ASN.1 and more".
> Well, unfortunately, it appears that we have one last error-- honestly,
I'm
> quite shocked this one slipped through.
>
> So... should the "aliasesInconsistent" field be moved above the
> "routeCallToSCN" element in the AdmissionRejectReason sequence as shown in
> an earlier H.323v2 Implementers Guide?
>
> Please post and debate this publicly.  We need to resolve this matter
> quickly so as to minimize impact on everybody.
>
> Best Regards,
> Paul
>
> ----- Original Message -----
> From: "XuPeili" <xupeili at huawei.com>
> To: "Paul E. Jones" <paulej at packetizer.com>
> Cc: <h323implementors at imtc.org>
> Sent: Tuesday, October 03, 2000 9:42 PM
> Subject: ;X84: Multiple Call Proceedings in a H.323 call
>
>
> > hi  Paul,
> >
> > In the H225.0v3.asn downloaded form www.packetizer.com
> > the ARJ is specified like this
> >
> > AdmissionRejectReason ::= CHOICE
> > {
> >  calledPartyNotRegistered NULL, -- cannot translate address
> >  invalidPermission  NULL, -- permission has expired
> >  requestDenied   NULL, -- no bandwidth available
> >  undefinedReason   NULL,
> >  callerNotRegistered  NULL,
> >  routeCallToGatekeeper  NULL,
> >  invalidEndpointIdentifier NULL,
> >  resourceUnavailable  NULL,
> >  ...,
> >  securityDenial   NULL,
> >  qosControlNotSupported  NULL,
> >  incompleteAddress  NULL,
> >  routeCallToSCN   SEQUENCE OF PartyNumber,
> >  aliasesInconsistent  NULL -- multiple aliases in request identify
> distinct
> > people
> > }
> >
> > Since the routeCallToSCN is a new choice in H.225.0v3, I think it should
> be
> > placed
> > after the aliasesInconsistent choice which is already exist in v2.
> >
> >
>
> --------------------------------------------------------------------------
-
> ------------------------------
> Please send E-mail to contact at imtc.org <mailto:contact at imtc.org>  to
> subscribe or unsubscribe from this list
> ------------------------------
> --------------------------------------------------------------------------
-
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com