Limitation of nonStandardData

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Thu Dec 4 06:29:04 EST 1997


Ernst,

Firstly, I don't think there is a problem with H.245 and the changes
proposed by Karl look good to me for H.450.x.  Only H.225 needs
attention.

I had assumed that the gatekeepers knew about each other.  I agree the
solution I proposed doesn't work for the scenario you described, but I'm
not sure that it is soluble within the constraints of the existing
nonStandardData field.

I had considered suggesting something like extraNonStandard in the
H323-UU-PDU field, but I thought others might object.  However, it makes
sense to me!

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Ernst Horvath[SMTP:Ernst.Horvath at SIEMENS.AT]
>Sent:  04 December 1997 10:35
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Limitation of nonStandardData
>
>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