Limitation of nonStandardData

Paul Long plong at SMITHMICRO.COM
Wed Dec 3 16:25:16 EST 1997


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.

> 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,

> 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
be present?

> 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
> on.

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.

> As far as how this is captured in the standard, this seems a fairly
> important feature for H.225.  I think we should include this as a
> separate root in the H.225 ASN.1 and give a fairly official OBJECT
> IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which
> shouldn't clash with anything in the context that we are using it).

This kinda bothers me. We having a similar need in H.324 for an ID that
all vendors will use. I think some entity, such as the IMTC or an
individual vendor, should control the use of the ID, whether it's an
OBJECT or H.221 ID. This way, we will have a central authority for
controling the namespace for that ID. For example, what if we need
another one down the line? Will it be {itu-t (0) recommendation (0) h(8)
2250 1}? How will we know if someone else has already used this OID
unless it is under centralized control?

> 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
need.

> 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
Recommendation.

> 3. We have no other SET OFs in H.225

So error propagation is a good thing, 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
this.

--
Paul Long___________________________http://www.cmpu.net/public/plong
Smith Micro Software, Inc.__________http://www.smithmicro.com/



More information about the sg16-avd mailing list