I have a remark and some concerns regarding the ASN.1 coding. There is
already a H.450.1 field behind the three dots in the H.225 V2. Here is a
copy of the current V2 definition:
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,
...,
progress Progress-UUIE,
empty NULL -- used when a FACILITY message is sent,
-- but the Facility-UUIE is not to be invoked
-- (possible when transporting supplementary
-- services messages)
},
nonStandardData NonStandardParameter OPTIONAL,
...,
h4501SupplementaryService SEQUENCE OF OCTET STRING OPTIONAL
-- each sequence of octet string is defined as one
-- H4501SupplementaryService APDU as defined in
-- Table 3/H.450.1
Of cource it would be possible to add the new field of nonStandardSequence
either before or after the h4501SupplementaryService, but the question is
whether it is necessary.
The H.450.1 provides namely (in addition to the standardized H.450.x
supplementary service signalling) for a coordinated method of vendor specific
signalling. With H.450.1 header the sender can not only identify itself, but
the sender can, for example, tell what the receiver has to do if it does not
understand the contents of the message. For this purpose the header contains
the type and address of source (sender) and destination entity (intended
receiver) and Interpreter.
H.450.1 may sound a little bit more complicated than just the
nonStandardParameter, but it allows the SENDER to have some control what the
receiver does.
Since h4501SupplementaryService is already a SEQUENCE, different entities
(i.e. enpoint stack, application, gatekeeper, gateway ...) can use the
H.450.1 for their own purposes indepently from each other.
If everybody would use the H.450.1 for their vendor specific functionality,
we have a better change to cope with the installed base in the future as we
continue increasing the H.323 capabilities.
So the question remains: Do we still need yet another method of sending
non-standard information in H.225 ? Perhaps somebody has an argument that I
did not see, yet.
Markku
-----Original Message-----
From: Toby Nixon [SMTP:tnixon@MICROSOFT.COM]
Sent: Monday, January 19, 1998 1:36 PM
To: ITU-SG16@mailbag.jf.intel.com
Subject: Re: H.323 delta doc
That would certainly make me happier than overwriting existing
nonStandardData.
-- Toby
-----Original Message-----
From: Scott Petrack [SMTP:Scott_Petrack@vocaltec.com]
Sent: Sunday, January 18, 1998 12:08 AM
To: ITU-SG16@mailbag.jf.intel.com
Cc: Toby Nixon
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@MICROSOFT.COM on 01/16/98 09:57:39 PM
Please respond to ITU-SG16@mailbag.jf.intel.com
To: ITU-SG16@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@microsoft.com
-----Original Message-----
From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK]
Sent: Friday, January 16, 1998 4:59 AM
To: ITU-SG16@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@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@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@BT-SYS.BT.CO.UK>
Subject: Re: H.323 delta doc
Date: Wed, 14 Jan 1998 14:01:48 -0000
To: ITU-SG16@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@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@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@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@delta-info.com
------------------------------------------------------
Korpi Markku PN VS LP3