Q12-14/16 Rapporteur meeting on 9-10 November

Sakae OKUBO okubo at GITI.WASEDA.AC.JP
Sat Oct 7 12:05:11 EDT 2000


Logan,

No, I am proposing this because we are shipping actual v3 endpoints and not
stacks (we developed everything in our products--we don't license anything
from anybody). Other vendors may, however, be shipping v3 stacks to their
licensees. I don't know. Also, H.225.0v2, H.323IGv2, and H.225.0v3 are all
Decided Recommendations, therefore they are all "correct" yet contradictory.
We now need to find the most interoperable solution to this mess.

Now, on to the particulars...

A v3 GK sends routeCallToSCN to a v3' (v3 + my proposal) EP. The EP attempts
to parse this SEQUENCE OF choice as a deprecatedAliasesInconsistent NULL
choice (but then treats it semantically like undefinedReason). Obviously the
types are different; however, the question is, what will the EP actually do
when this happens? Our ASN.1 parser will simply skip over the encoded
SEQUENCE OF value and treat it as if a NULL value were encoded. There is no
reason for it to check the encoded value since this is a NULL type, after
all. It can do this because components not in the extension root are always
encapsulated within an open type. (I can explain how this works if
necessary.) If the RELAXPER decoder flag is specified with a very popular
ASN.1 decoder ;-), the same thing will happen. From my experience, I would
guess that most or all licensees of this parser run their decoders this way.
Also from my experience, I believe that a very popular H.323 stack and in
fact most or all ASN.1 PER decoders behave this way. If anybody knows
otherwise (and is not simply guessing), please come forward.

At a higher level, though, remember that we are trying to _minimize_ the
overall impact of whatever solution we specify--we cannot eliminate it
altogether. On the plus side, notice that if a v2 GK sends
aliasesInconsistent to a v3' EP (see attached spreadsheet), there would be
absolutely no chance of a decode error, and this is a much more likely
scenario these days (many more v2 GKs than v3 GKs). That's why I chose to
place deprecatedAliasesInconsistent ahead of deprecatedRouteCallToSCN.

FWIW, here is a summary of the relevant parts of the AdmissionRejectReason
type for the different syntaxes under discussion:

Current H.323v2 syntax (with IGv2 applied)
        aliasesInconsistent             NULL    -- multiple aliases in request identify distinct
people

Current H.323v3 syntax
        routeCallToSCN                  SEQUENCE OF PartyNumber,
        aliasesInconsistent             NULL    -- multiple aliases in request identify distinct
people

Proposed IGv3 syntax
        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
        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

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Logan Modahala [mailto:lmodahal at CISCO.COM]
Sent: Friday, October 06, 2000 9:23 AM
To: Paul Long
Cc: Mailing list for parties associated with ITU-T Study Group 16;
h323implementors at imtc.org; h323implementors at pulver.com
Subject: Re: Error in H.323v3 ASN.1


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

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


More information about the sg16-avd mailing list