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 =================================
From: Paul Long[SMTP:plong@SMITHMICRO.COM] Sent: 02 December 1997 21:05 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData
Scott Petrack wrote:
This problem has bothered me for a long time. I considered many times introducing into the VoIP Forum an OID which would be used precisely as Jim suggests, so that the entire industry could signal a SEQUENCE of NonStandardParameter.
So do you mean something like this?:
NonStandardParameter ::=SEQUENCE { nonStandardIdentifier NonStandardIdentifier, -- e.g., VoIP OID data OCTET STRING }
where data contains the following:
SET SIZE (1..256) OF NonStandardParameter
BTW, I believe that it should be a SET OF and not a SEQUENCE OF, because SEQUENCE OF implies that the order is important, and I don't think that is the intent here. Or is it?
One way to handle this for _future_ syntax is to define a type that is itself a set of NonStandardParameters, as in:
NonStandardParameters ::=SEQUENCE { nonStandardParameters SET SIZE (1..256) OF NonStandardParameter }
One example of why this is necessary is so that when someone else uses our stack we can both pass non-standard parameters.
Just to play devil's advocate, can you give an example of a specific need for this? A quick review of H.245 didn't turn up very many situations where aggregation isn't handled already at a higher level or where it just doesn't make sense in the first place.
Here is an example of where iteration is expressed at a higher level. The capability table contains multiple capabilities, so there is no need for a single capability containing multiple NonStandardParameters--just add more nonStandard capabilities. Case in point: it makes no sense, IMO, for UserInputCapability to have a nonStandard CHOICE of multiple NonStandardParameters, when multiple nonStandard UserInputCapabilities would have served just as well. I agree with Dykstra--_I don't like more than one way of doing the same thing._
An example of where multiple NonStandardParameters may not make sense in the first place is in the NonStandardMessage type. Is there ever a need to combine several NonStandardParameters in the same RequestMessage, for example? IOW, these uses are atomic.
-- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/