difficulty within the UCLA proposal "Generic Uneven Level Protect ion(ULP)"

Baese Gero Gero.X.Baese at MCHP.SIEMENS.DE
Fri Oct 6 11:33:48 EDT 2000


Paul,

If my understanding is as mentioned below, with all due respect, I wish
to point out that this proposal will not work.


I assume you are proposing this because the H323v3 code is already sent
out by some stack vendors but find  it  difficult to go to those
customers and change thye stack. If I am correct, your proposal is that
the H323v3 code that already shipped out will use the "erroneous" v3
spec. i.e the "routeCallToSCN   SEQUENCE OF PartyNumber" parameter
appearing first; but the new H323v3 code with your proposal  has
"deprecatedAliasesInconsistent   NULL" first. i.e in the logical
incresed ordering of the extension additions both take the same position
(#3) in the choice. However, one is of type NULL and the other is of
type SEQUENCE OF.

Let us say H.323v3 endpoint with erroneous spec use, encodes a message
choosing the routeCallToSCN field (poistion #3 with type SEQUENCE OF),
the new H.323v3 with your proposed change will attempt to decode that
same field to a NULL type. As a result, all the subsequent decodings
will be inconsistent based on how many elements were added in the
SEQUENCE OF encoding. In this discussion, always remember that the
parent type is a CHOICE. Hence there should be one and only one field
should be present.

In my opinion, even well known ASN.1 decoders (not appropriate for me to
mention names) will go crazy here when a message from H.323v3 EP with
erroneous spec use sends a message to the EP using newly proposed spec.

o we have a compatibility problem between the erroneous H.323v3 endpoint
and the endpoint using the proposed H.323v3 spec.

- Logan

Paul Long wrote:
>
> 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.
> ---------------------------------------------------------------------------
> ------------------------------
> 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



More information about the sg16-avd mailing list