Re: Limitation of nonStandardData
Jim, Scott, Douglas, Paul,..... To answer Paul's question about the need for the change first: We are mainly interested in gatekeepers. We have a need to ship nonStandard information between cooperating gatekeepers, particularly in the SETUP message. However, endpoints may also wish to ship their own nonStandard information which the gatekeeper doesn't want to stamp on (because I'm a nice guy!). Hence we both have a need to use a field that is only intended to carry one value. This helps identify a suitable syntax for the data that goes into the data part of nonStandard data, as I believe we need to cater for both the nested form (for backwards compatibility) and multiple pieces of nonStandard data without any particular order. 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, ... } This would be used as follows: 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. 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. On the other side a gatekeeper could see that the extraNonStandard related to it, and remove parts the parts that it needed to. If all that was left was the previousNonStandard part, then it would use this to recover what was the original format of the nonStandard message. This allows endpoints to send nonStandardData transparently, but also allows gatekeepers to get in on the act. 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). I've used an unconstrained SEQUENCE OF for the following reasons: 1. No other SEQUENCE OFs are bounded within H.225. 2. Size constraints on SEQUENCE OF are not always that useful (especially in the case of H.245!) 3. We have no other SET OFs in H.225 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. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
Pete Cordell wrote:
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.
Please constrain this aggregate with something like this: extraNonStandard SET SIZE (0..255) OF NonStandardParameter,
Copying it or moving it? IOW, would the original nonStandardData still be present?
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.
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? :-)
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/
Paul, 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:
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, OpenLogicalChannel.
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.
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.
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. [cut]
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.
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? :-)
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. Regards, Douglas Clowes
Paul Long wrote:
[Bancroft's response follows. Apparently there is no reason _not_ to use SET OF, because H.245, and H.225.0, and presumably H.450 use BASIC PER, not CANONICAL PER, so there is no sorting.] This is true in the case of DER, which mandates this behavior. DER encoders does not take it upon themselves to do this; it is required in order to produce a valid DER encoding. This is also true in the case of CER and the canonical variants of PER. It is not true for the non-canonical variants of PER or for BER. As far as the OSS ASN.1 Tools go, DER is supported, so here SET OF's are sorted as required. The OSS ASN.1 Tools at this time does not support the canonical variants of PER, so no such sorting occurs for PER. Since all the sorting algorithms are in place for DER, it is easy to provide canonical PER support if it is required. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/
participants (3)
-
Douglas Clowes -
Paul Long -
Pete Cordell