Draft H.310 version 2

[Kiyoshi SAKAI]

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 at BT-SYS.BT.CO.UK>
  Subject: Re: H.323 delta doc
  Date: Wed, 14 Jan 1998 14:01:48 -0000
  To: ITU-SG16 at 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 at bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> =================================
>
>
> >----------
> >From:  Gary A. Thom[SMTP:gthom at DELTA-INFO.COM]
> >Sent:  09 January 1998 23:00
> >To:    ITU-SG16 at 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 at 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 at delta-info.com
------------------------------------------------------