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:
- 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.
- 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.
- We have no other SET OFs in H.225
So error propagation is a good thing, right? :-)
- 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/