Gary,
Two things....
1. I included the wrong text in the mail I originally sent you... The
text should have been:-
"To include multiple elements of nonStandardData in an H.225 message the
nonStandardParameter is used in the following way. This special use of
the nonStandardParameter is identified by setting the
nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0)
recommendation (0) h (8) 2250}. In this case the information contained
in the data part of the nonStandardParameter consists of a fragment of
ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the
same as those for all H.225 messages). The ASN.1 fragment has the
following syntax:
ExtendNonStandard ::= SEQUENCE OF NonStandardParameter
It is recommended that entities use this method for including
nonStandardData in messages even if they only insert one piece of
information as it allows other entities in the signalling path to either
add or delete their own nonStandardData without overwriting information
inserted by the originating entity.
If intermediate entities on the signalling path need to insert
nonStandardData when there is already nonStandardData present that is
not of the extended form described above they are encouraged to take
measures to ensure that the original nonStandardData can be recovered by
entities further down the signalling path once those entities have
removed any nonStandardData specific to them. This can be achieved by
nesting the original nonStandardData field inside the
nonStandardParameter created by the intermediate entity.
However, endpoints should be aware that if they do not insert
nonStandardData in the extended form it may be overwritten by
intermediate signalling entities."
This is less enforcing than the text you received before, which seems
more in line with backwards compatibility.
2. If you're imply that it should be in H.225.0 I think that makes
sense (even though I had originally assumed it would go in H.323). In
the discussion on nonStandardParameter in Section 7.6 H.225.0 seems a
good place.
Regards,
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell(a)bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
>----------
>From: Gary A. Thom[SMTP:gthom@DELTA-INFO.COM]
>Sent: 16 January 1998 00:40
>To: ITU-SG16(a)MAILBAG.INTEL.COM
>Subject: Re: H.323 delta doc
>
>Pete,
>
>Is this text for a new section in H.323 or for
>the non-standard semantics in H.225.0???
>
>Gary
>
>------------------------
> From: Pete Cordell <pete.cordell(a)BT-SYS.BT.CO.UK>
> Subject: Re: H.323 delta doc
> Date: Wed, 14 Jan 1998 14:01:48 -0000
> To: ITU-SG16(a)MAILBAG.INTEL.COM
>
>
>> Gary,
>>
>> I think we got consensus on the nonStandard issue to the point that no
>> one objected (!) and most people seemed to be positive. The suggested
>> wording (including wording to cover off Joerg's comments) was:
>>
>> "To include multiple elements of nonStandardData in an H.225 message the
>> nonStandardParameter SHALL BE in the following way. This special use of
>> the nonStandardParameter is identified by setting the
>> nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0)
>> recommendation (0) h (8) 2250}. In this case the information contained
>> in the data part of the nonStandardParameter SHALL CONSIST of a fragment
>> of ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the
>> same as those for all H.225 messages). The ASN.1 fragment has the
>> following syntax:
>>
>> ExtendNonStandard ::= SEQUENCE OF NonStandardParameter
>>
>> Entities SHOULD use this method for including nonStandardData in
>> messages even if they only insert one piece of information as it allows
>> other entities in the signalling path to either add or delete their own
>> nonStandardData without overwriting information inserted by the
>> originating entity.
>>
>> If intermediate entities on the signalling path need to insert
>> nonStandardData when there is already nonStandardData present that is
>> not of the extended form described above (i.e. this sentence goes below
>> what I originally presented, just avoid any confusion!) they are
>> encouraged to take measures to ensure that the original nonStandardData
>> can be recovered by entities further down the signalling path once those
>> entities have removed any nonStandardData specific to them. This can be
>> achieved by nesting the original nonStandardData field inside the
>> nonStandardParameter created by the intermediate entity.
>>
>> However, endpoints should be aware that if they do not insert
>> nonStandardData in the extended form it may be overwritten by
>> intermediate signalling entities."
>>
>> Regards,
>>
>> Pete
>>
>> =================================
>> Pete Cordell
>> BT Labs
>> E-Mail: pete.cordell(a)bt-sys.bt.co.uk
>> Tel: +44 1473 646436
>> Fax: +44 1473 645499
>> =================================
>>
>>
>> >----------
>> >From: Gary A. Thom[SMTP:gthom@DELTA-INFO.COM]
>> >Sent: 09 January 1998 23:00
>> >To: ITU-SG16(a)MAILBAG.INTEL.COM
>> >Subject: H.323 delta doc
>> >
>> ><<File: H323DL.DOC>>
>> >Hi all,
>> >
>> >
>> >Attached is the Delta document for H.323.
>> >
>> >
>> >I did not include any changes for nonStandard or Fast Start as I did
>> >not hear a widely
>> >accepted proposal.
>> >
>> >If I missed anyones comments, please let me know.
>> >
>> >
>> >Gary
>> >------------------------------------------------------
>> >Name : Gary A. Thom
>> >Company: Delta Information Systems, Inc.
>> >Address: 300 Welsh Rd., Bldg 3
>> > Horsham, PA 19044 USA
>> >Phone : +1-215-657-5270 Fax : +1-215-657-5273
>> >E-mail : gthom(a)delta-info.com
>> >------------------------------------------------------
>> >
>
>---------------End of Original Message-----------------
>
>------------------------------------------------------
>Name : Gary A. Thom
>Company: Delta Information Systems, Inc.
>Address: 300 Welsh Rd., Bldg 3
> Horsham, PA 19044 USA
>Phone : +1-215-657-5270 Fax : +1-215-657-5273
>E-mail : gthom(a)delta-info.com
>------------------------------------------------------
>
