Error in H.323v3 ASN.1

Logan Modahala lmodahal at CISCO.COM
Mon Oct 9 12:53:30 EDT 2000


With extension addition fields, I do understand that the encoding is
OpenType and the OpenType field's encoding length is included. But my
point is that if the field is encoded by the peer EP, how does the ASN.1
decoder know whether to
ignore the entire field or decode the OpenType field. If the field is to
be ignored, then fine. If the field is not to be ignored, the the types
must match between the two entities for a field occupying the same
position in the ordering.

What you are proposing can only be achieved if the ASN.1 compiler
supports a directive(such as the RELAXPER decoder flag) to inform the
encode/decode library to ignore a particular field.

I am not sure if I will support this, though. Personally, H323v3 is in
it early stage and let us correct it the right way. We have been in this

- Logan

Paul Long wrote:
> 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; h323implementors at
> 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
> 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
>   ------------------------------------------------------------------------
>                  Name: ARJfix.xls
>    ARJfix.xls    Type: Microsoft Excel Worksheet (application/
>              Encoding: base64

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list