Paul,
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 situation.
- 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@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@imtc.org; h323implementors@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
Name: ARJfix.xlsARJfix.xls Type: Microsoft Excel Worksheet (application/vnd.ms-excel) Encoding: base64
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com