Error in H.323v3 ASN.1

[Paul Long]

Paul,

I put together a spreadsheet to evaluate all possible combinations of fixes
and versions. It's pretty small (15K), so I attached it.

You are right that there will be some v2 entities that expect to see the old
aliasesInconsistent choice, but they will now only receive them from other
v2 entities (compatible ones choices) or v3 entities that have not applied
what I propose to be added to IGv3 (incompatible choices). The latter is
simply broken, and there is nothing we can do to fix it, no matter which
approach we take. A v2 entity will be no worse than a v1 entity in that it
will receive a reject reason that it doesn't understand because it was added
after v2, e.g., a new aliasesInconsistent. In this case, it should treat the
reason as undefinedReason. This is the way unrecognized reasons and choices
in general have always been treated.

Regarding v3, if we swap the choices in IGv3 and H.225.0v4 as you propose,
"pre-fix" v3 entities like our EPs will definitely encounter decode
errors--they will always be at risk. The same goes for v3 GKs. If a v3 GK
transmits either of these pre-fix choices, the receiving "fixed" EP will
encounter a decode error. On the other hand, the worse thing that can happen
using my proposal is that an entity would treat these pre-fix choices as
undefined reasons--a much better outcome.

We should also recommend that v2 GKs no longer send the old
aliasesInconsistent reason. They should instead send undefinedReason. It is
unfortunate that they would lose the ability to convey this particular info
to the EP, but the alternative is risking a decode error and dropping the
call.

I realize that my proposed fix of deprecating the two extant reasons is less
elegant than simply switching them around in order to agree with v2.
However, as you can see from the spreadsheet, the benefit of
interoperability far outweighs this.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Thursday, October 05, 2000 11:15 PM
To: Paul Long; Mailing list for parties associated with ITU-T Study
Group 16
Cc: h323implementors at imtc.org; h323implementors at pulver.com
Subject: Re: Error in H.323v3 ASN.1


Paul,

The problem with this simpler approach to deprecating the fields is that
there will still be v2 entities that expect to see the
aliasesInconsistent
field and there may be v3 entities out there that assume a different
field
is there and things will be broken between those endpoints.

Perhaps it might be less of an impact, though...

Paul

----- Original Message -----
From: "Paul Long" <Plong at SMITHMICRO.COM>
To: "Mailing list for parties associated with ITU-T Study Group 16"
<ITU-SG16 at mailbag.cps.intel.com>
Cc: <h323implementors at imtc.org>; <h323implementors at pulver.com>
Sent: Thursday, October 05, 2000 2:08 PM
Subject: RE: Error in H.323v3 ASN.1


> Paul,
>
> I just checked, and we are shipping v3 EPs. I agree that there are
probably
> many more v2 entities than v3 entities, and therefore if we have to
break
> one, we should break the one which will have the least impact on the
market.
>
> To minimize the impact this will have on interoperability, however,
let's
> don't simply move the reasons around. Instead, lets deprecate the
current
> routeCallToSCN and aliasesInconsistent reasons using the following
syntaxes
> in IGv3 and H.225.0v4.
>
> Proposed IGv3 syntax
>
> 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,
>
> -- changes start here:
> deprecatedAliasesInconsistent NULL, -- do not use
> deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use
> callCapacityExceeded NULL, -- destination has exceeded call capacity
> aliasesInconsistent NULL, -- multiple aliases in request identify
distinct
> people
> routeCallToSCN SEQUENCE OF PartyNumber
> }
>
>
> Proposed H.225.0v4 syntax
>
> 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,
>
> -- changes start here:
> deprecatedAliasesInconsistent NULL, -- do not use
> deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use
> exceedsCallCapacity NULL, -- destination does not have the capacity
for
> this call
> aliasesInconsistent NULL, -- multiple aliases in request identify
distinct
> people
> routeCallToSCN SEQUENCE OF PartyNumber,
> collectDestination NULL,
> collectPIN NULL
> }
>
> I assume we can change both because neither are Decided and these are
true
> irreconcilable errors in the documents, correct? Here are the
specifics:
We
> rename the old reasons to "deprecate*", add the new ones after
> callCapacityExceeded/exceedsCallCapacity, and then in the text of IGv3
and
> H.225.0v4 say that the old ones shall not be transmitted and if
received
> shall be treated like undefinedReason. Otherwise, a receiver would
have to
> parse the AdmissionReject message differently depending on the version
of
> the transmitter. We, Smith Micro, can actually do that with our ASN.1
parser
> but I'm guessing that most implementations cannot. Maybe we should
even
> change the type of deprecatedRouteCallToSCN to NULL so that the ASN.1
PER
> parser would simply skip over the contents via the encapsulating open
type.
> I know that our parser would do this. Would others?
>
> v1 implementations won't have a problem, because they would ignore
this
> reason, anyway, but we could encourage v2 implementations to treat
> aliasesInconsistent like undefinedReason since they won't know if it
is
> aliasesInconsistent from a v2 EP or some other extended choice from a
v3+
> EP.
>
> Paul Long
> Smith Micro Software, Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ARJfix.xls
Type: application/x-msexcel
Size: 14848 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001006/90e4027a/attachment-0006.bin>