Limitation of nonStandardData
dclowes at OZEMAIL.COM.AU
Wed Dec 3 20:22:05 EST 1997
There seems to be a mismatch in the understanding here and I'm not sure
that it isn't me. So I'll give my version the understanding and hope to be
corrected where I'm wrong. (BTW, I don't understand what the '...' in the
ASN.1 does and why it's in the middle of the H.323 V2 stuff.)
At 13:25 3/12/97 -0800, Paul Long wrote:
>Pete Cordell wrote:
>> We are mainly interested in gatekeepers. We have a need to ship
>> nonStandard information between cooperating gatekeepers, particularly in
>> the SETUP message.
>Okay, I see that H.225.0 apparently wasn't engineered for multiple
>nonStandardParameters, whereas H.245 at least originally was, but at a
>higher level, not merely a SET OF NonStandardParameters. I agree that
>this is a problem in H.225.0, but I don't think there is a problem with
>H.245, unless someone can give me specific examples.
The problem tends to arise in a channel where there are multiple nodes.
This could be true of RAS if there is a hierarchy of gatekeepers. It is
true of of the Call Signalling Channel and the H.245 Control Channel when
going via one or more gatekeepers, proxies or other devices.
An obvious problem arises in the following situation. Two endpoints require
a NonStandardParameter in the Q.931 SETUP message so that they can
cooperative complete a connection. Two intermediate (to the endpoints) and
cooperative gatekeepers require to add a NonStandardParameter for their
participation in the SETUP process. Two intermediate (to the gatekeepers)
and cooperative proxies require to add a NonStandardParameter for their own
use. The problem arises when the intermediaries throw away the
NonStandardParameter already in the message and substitute their own
because the syntax only allows one NonStandardParameter.
I don't understand how H.245 intrinsically solves this problem for, say,
>> To do this, I propose that the piece of ASN.1 put in the data part of
>> nonStandardParameter should be:
>> ExtendedNonStandardData ::= SEQUENCE
>> previousNonStandard NonStandardParameter OPTIONAL,
>> extraNonStandard SEQUENCE OF NonStandardParameter,
>Please constrain this aggregate with something like this:
> extraNonStandard SET SIZE (0..255) OF NonStandardParameter,
Given that a NonStandardParameter contains a data field that is an
unconstrained OCTET STRING, I don't see the point of arbitrarily
constraining the number of them.
>> A V1 endpoint could put its own piece of nonStandardData into the
>> existing nonStandard field. When a gatekeeper (or something else)
>> received it, it would take the data from the existing nonStandard field
>> and put it in the previousNonStandard field of the above SEQUENCE.
>Copying it or moving it? IOW, would the original nonStandardData still
The original nonStandardData is moved, by the first gateway of the above
example, into the previousNonStandard field. This allows the first gateway
to add its own NonStandardParameter to the extraNonStandard field.
The whole ExtendedNonStandardData is placed in the data field of the V1
NonStandardParameter which is included in the original message in place of
the original nonStandardData.
The first proxy does exactly the same thing.
The message is still V1 compliant so if it goes through anything else that
cares, it still sees a standard V1 message with the single
NonStandardParameter allowed in the standard and, hopefully, passes it on
to the second proxy.
The second proxy recognizes the NonStandardparameter as its very own and
unwraps it to reveal, in the previousNonStandard field, the
NonStandardParameter that the first proxy received from the first
gatekeeper. It takes its own stuff out and restores the
NonStandardparameter from the previousNonStandard field, places it in the
outgoing message as the one and only NonStandardParameter allowed in the
message and sends it to the second gatekeeper.
The second gatekeeper does exactly the same thing. The message that it
sends to the second endpoint contains the original (from the first
endpoint) NonStandardparameter as received by the first gatekeeper.
>> It would then add whatever nonStandard stuff it needed to the
>> extraNonStandard bit. It would put the combined nonStandard data in the
>> data part of the nonStandardParameter and give it the tag that we decide
>I don't understand, why have "previousNonStandard?" Why not just have a
>single nonStandard SET SIZE (0..255) OF NonStandardParameter, and simply
>append any GK stuff to the end? Also, as someone said previously in this
>thread, what if a third-party stack uses the single, original
>NonStandardParameter, yet the layer above that stack also wishes to
>include NonStandardParameters. Sounds like NonStandardParameters can be
>added and removed at any point in the data path, not just by GKs.
In V1, there is only a single nonStandard, not a set of them. To include a
NonStandardParameter where there alreay is one requires the original to be
discarded which is the root of the problem. To extend the standard to have
a SET or SEQUENCE OF is a possible solution to the problem. If the message
goes through something that only tollerates a single NonStandardParameter
as specified in the standard, there could be a problem.
>> I've used an unconstrained SEQUENCE OF for the following reasons:
>> 1. No other SEQUENCE OFs are bounded within H.225.
>They should have been, and this will cause implementation problems down
>the line. Each vendor guesses what the max should be. Although all
>guesses are equally "correct," some will be too low and could cause the
>system to fail through no fault of the vendor. Remember that not all
>implementations will have 32MB of RAM and all the virtual memory they
I understand your concern but, again, the NonStandardParameter is unbounded
(if I correctly interpret 'OCTET STRING') and so, limiting the number of
them to 255 doesn't add a lot and imposes an arbitrary constraint.
>> 2. Size constraints on SEQUENCE OF are not always that useful
>> (especially in the case of H.245!)
>I have no idea what you mean by this. There are always real size
>constraints--no system has infinite resources. It would just be nice if
>the constraints were agreed upon and stated up front in the
If you impose limitations that fit the lowest hardware of today, they will
be innappropriate for the hardware of this afternoon. If you set the limits
to handle the growth, does it help today. Say we imposed a limit of a 4GB
today, would it help. If we made that limit 16K today, how would that
impact us later?
>> 3. We have no other SET OFs in H.225
>So error propagation is a good thing, right? :-)
This bit I agree with, so it probably means I don't understand the finer
points of difference between sequences and sets, right? :-)
>> 4. As I understand it, for some strange reason, because the order of the
>> members of a SET OF is intended to be un-important the compiler takes it
>> upon itself to sort the values entered into some form of order!!! This
>> seems a waste of time and is a step best avoided by using SEQUENCE OF.
>I've never heard of this before. I'll check with Bancroft. Sounds like a
>bug in the OSS compiler, which by the way we don't use for reasons like
Sounds like a problem with implementation in a particular compiler, not a
good basis for setting the direction of a standard. I think that the *best*
way to avoid such a problem is to fix or replace the compiler.
More information about the sg16-avd