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@imtc.org mailto:contact@imtc.org to subscribe or unsubscribe from this list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com