Error in H.323v3 ASN.1

[Paul E. Jones]

Anatoli,

This is a difficult situation here: and we've been here before.  I received
e-mail from one company this morning that said they need the H.323v2 field,
because they did use the Implementers Guide definitions.

Now, it appears that we have the same problem as we had with the TokenOID
problem back in May 1999 where one published document contradicted another.

So, how can we resolve this issue?  I've already concluded that, based on
the number of vendors out there with H.323 products, we can't possibly
contact them all and take a vote :-)

Without getting into specific details: at this point, 1 year after the
published H.323v3 document, how much effort would it be to try to change the
H.323v3 software you have deployed and how much of an impact would that
have?  Did you also pick up all of the other H.323v3 ASN.1 changes that have
been made?  See this file for a complete, updated ASN.1 for v3:
http://www.packetizer.com/iptel/h323/h2250v3.asn.  Of course, it does
contain the error we're talking about here, but that is only because I
copied the ASN.1 from the published v3 document and then modified it
according to the Implementers Guide.

Paul

----- Original Message -----
From: "Anatoli Levine" <alevine at RADVISION.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Wednesday, October 04, 2000 6:54 AM
Subject: Re: Error in H.323v3 ASN.1


> Paul,
>
> RADVision's current implementation matches H.323 v3 syntax (with
"incorrect
> field"), also we never had the version which would match
AdmissionRejectReason
> from H.323v2 Implementors Guide. Thus if we would move this field now, it
would
> rather create interoperability problems so we would like to keep it the
way it
> is currently in the H.323 v3.
>
> Best regards,
> Anatoli
>
> "Paul E. Jones" wrote:
>
> > 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.
> > >
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>

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