Limitation of nonStandardData

Ernst Horvath Ernst.Horvath at SIEMENS.AT
Thu Dec 4 05:35:29 EST 1997


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 at 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 at bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> =================================
>



More information about the sg16-avd mailing list