Pete,

maybe I misunderstand the whole matter, but I think all proposals so far have a problem with backward compatibility. Let me summarize how I see the situation:

If nonStandardData is essential for a call, the call will not succeed unless both ends have a common understanding of the nonStandardData.

But there may be cases where a rudimentary service can be provided based on standard data, and nonStandardData provide additional value if both ends understand it. I.e., an endpoint can communicate with endpoints from other vendors, but if it communicates with an endpoint from the same vendor some additional proprietary features are available. This is the idea behind the extension fields in H.450.x.

Now, regarding the limitation problem:

- In H.450.x the limitation concerns only Type NonStandardParameter, extensions in the ISO style can already be repeated. If there is sufficient justification, I am sure we remove the limitation before publication, along the lines indicated by Karl.

- In H.245, I noticed there are already SEQUENCE OF NonStandardParameter at various places, so I assume there is no problem.

- In H.225.0, we should aim for backwards compatibility. This eliminates the possibilty to replace NonStandardParameter by a SET OF or SEQUENCE OF NonStandardParameter.

But your proposal of embedding a new structure into the data part of NonStandardParameter has a similar problem: Suppose a V1 endpoint sends nonStandardData, and a V2 gatekeeper replaces it with another element (with another identifier), containing the original nonStandardData in the previousNonStandard field. There is no guarantee that another GK unwraps the original nonStandardData again, in which case the new element will end up at the destination endpoint. If this is V1 it will not recognize this element, although it may well understand the original nonStandardData wrapped inside it. So it cannot act on the information.

In my opinion, the only way to achieve backwards compatibility is to add extraNonStandard as a new element, and there are many places where this has to be done!

Example:

McuInfo ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, ..., extraNonStandard SEQUENCE OF NonStandardParameter OPTIONAL }

Ernst ================================ Ernst Horvath Siemens AG Tel: +43 1 1707 45897 Fax: +43 1 1707 56992 enail: ernst.horvath@siemens.at ================================

Pete Cordell wrote:

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