H.323 delta doc

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Mon Jan 19 10:42:39 EST 1998


Dear All,

The text presented was intended to cover the "Netmeeting case".
Mandating that intermediaries shouldn't over write a piece of data seems
to be a waste of ink as if the intermediary needs to over write to do
what it wants to do, there's no police around to prevent it doing so.
Hence the encouragement of nesting, rather than mandating.

However, Scott's proposal looks good to me and I am happy to go with
either.  I think somebody raised this option earlier but there were
concerns that it was too much of a change.  Mind you it would be nice to
do a good job without ITU politics getting in the way!

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


>----------
>From:  Scott Petrack[SMTP:Scott_Petrack at VOCALTEC.COM]
>Sent:  18 January 1998 08:08
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: H.323 delta doc
>
>Thinking about Toby's concern, the only way I can think of to mandate
>preservation and to be totally backward compatible is to add to the
>H323-UU-PDU structure a new field after the dots:
>
>H323-UU-PDU ::= SEQUENCE
>{
>     h323-message-body   CHOICE
>     {
>          setup               Setup-UUIE,
>          callProceeding CallProceeding-UUIE,
>          connect        Connect-UUIE,
>          alerting       Alerting-UUIE,
>          userInformation     UI-UUIE,
>          releaseComplete     ReleaseComplete-UUIE,
>          facility       Facility-UUIE,
>          ...
>     },
>     nonStandardData          NonStandardParameter OPTIONAL,
>     ...
>     nonStandardSequence SEQUENCE of NonStandardParameter OPTIONAL
>}
>
>v2 implementations should be told not to write into the old
>nonStandardParameter and to use the new one. Such a change is pretty
>tiny,
>and if I'm not mistaken would guarantee complete backward compatible
>and
>give the required new function.
>
>If it is really too late it could be done in the implementor's guide, I
>suppose.
>
>Scott
>
>
>
>
>
>tnixon at MICROSOFT.COM on 01/16/98 09:57:39 PM
>
>Please respond to ITU-SG16 at mailbag.jf.intel.com
>
>To:   ITU-SG16 at mailbag.jf.intel.com
>cc:    (bcc: Scott Petrack)
>Subject:  Re: H.323 delta doc
>
>
>
>
>While we don't necessarily oppose migrating to a sequence of
>nonStandardParameter in the nonStandardData element of H323-UU-PDU in
>H.225.0 messages, everyone should be aware that NetMeeting does make
>use of
>this element in the "old" unstructured form. I think you'd find
>NetMeeting
>users disturbed by the loss of functionality that occurred if
>intermediate
>devices overwrote nonStandardData, as provided for in the last
>paragraph of
>the proposed text. We would be much more comfortable if the text did
>not
>permit overwriting -- or mandated preservation -- when the message is
>being
>conveyed between H.323v1 endpoints.
>        -- Toby
>___________________________________________________________
>Toby Nixon, Program Manager - NetMeeting
>http://www.microsoft.com/netmeeting
>Microsoft Corporation, Applications and Internet Client Group, Redmond
>WA
>USA
>+1 (425) 936-2792     Fax: +1 (425) 936-7329
>mailto:tnixon at microsoft.com
>
>> -----Original Message-----
>> From: Pete Cordell [SMTP:pete.cordell at BT-SYS.BT.CO.UK]
>> Sent: Friday, January 16, 1998 4:59 AM
>> To:   ITU-SG16 at MAILBAG.INTEL.COM
>> Subject:      Re: H.323 delta doc
>>
>> 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 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:  16 January 1998 00:40
>> >To:    ITU-SG16 at 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 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
>> >------------------------------------------------------
>> >
>



More information about the sg16-avd mailing list