January 1998 - sg16-avd - lists.packetizer.com

Strategy for standardisation of text conversation protocols
by Gunnar Hellstrom 21 Jan '98

21 Jan '98

A TD has been delivered to the ITU today, describing alternate strategies for standardisation of text conversation protocols. It is the same issue that has been up for discussion many times last year - can we rely on T.120 as the base for data comms in multimedia or do we need to produce environment specific protocols. The document is named Q9-16textstrategy.doc and is also stored in Q9/16 informal web area http://www.pi.se/~omnitor/standd.htm where you can find all other Q9/16 related documents that have been submitted to me. I hope we can assign a time slot for example during the joint sessions on Friday to reach a conclusion on this issue. Best regards Gunnar Hellström ______________________________________ Gunnar Hellström Sweden Tel +46 701 100 501 Fax +46 8 556 002 06 Video +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.pi.se/~omnitor

1 0

nonStandardSequence and nonStandardData
by Orit Levin 21 Jan '98

21 Jan '98

Hello all! We are in favor of "nonStandardSequence" proposal. I would like to mention, that for truly backward compatibility, v2 entities should use the old nonStandardData field along with the new one. It means that the NonStandardParameter value (or in case of more then one: the most important among the NonStandardParameter values) should be inserted by v2 entities into both nonStandardData and nonStandardSequence fields. As to the use of H.450.1 h4501SupplementaryService field for this purpose, since H.450 is an optional subset of H.225.0, it seems more proper to keep the nonStandardData basic capability apart from it, for the sake of H.323 "light" implementations, that don't support H.450. ============ >> 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 >> } >> ============ Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516

1 0

FW: H.323 delta doc
by Korpi Markku PN VS LP3 20 Jan '98

20 Jan '98

>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(a)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(a)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(a)MICROSOFT.COM on 01/16/98 09:57:39 PM >> >> Please respond to ITU-SG16(a)mailbag.jf.intel.com >> >> To: ITU-SG16(a)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(a)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(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 >> > >------------------------------------------------------ >> > > >> >> >> >> >> >>

1 0

TDs from Q.12/16 Rapporteur
by Sakae Okubo 20 Jan '98

20 Jan '98

Dear SG16 colleagues, I have sent the following five Rapporteur TDs to TSBEDH: H222_AM5.zip Draft for Amendment 5 to ITU-T Rec. H.222.0|ISO/IEC 13818-1 H310v2-C.doc DRAFT REVISED RECOMMENDATION H.310 - VERSION 2 Q12_stat.zip REPORT ON THE STATUS OF Q.12/16 "B-ISDN MULTIMEDIA SYSTEMS AND TERMINALS" Interim.zip REPORT OF INTERIM RAPPORTEUR MEETINGS hbmul6nc.zip DRAFT RECOMMENDATION H.BMULTIPOINT The fourth one is to report the summary of two Q.12-14/16 Rapporteur meetings held in Hertzlia and Sunriver. They are placed at the GCL ftp site: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/ (user: itu-t, password: sg15!avc) Please refer to 9801_Gen.html for the list of the next week SG16 meeting documents. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Q.12/16 status report
by Sakae Okubo 20 Jan '98

20 Jan '98

Dear SG16 colleagues, Attached please find my status report to be presented next week at the WP2/16 plenary. If you have any advice, particularly on items needing guidance of WP2/16, please tell me. I will include them in my presentation. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** INTERNATIONAL TELECOMMUNICATION UNION Temporary Document TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 1997-2000 STUDY GROUP 16 Geneva, 26 January - 6 February 1998 Question : 12/16 SOURCE* RAPPORTEUR FOR Q.12/16 : TITLE : REPORT ON THE STATUS OF Q.12/16 "B-ISDN MULTIMEDIA SYSTEMS AND TERMINALS" --------------------- 1. Interim activities After the SG16 meeting in March 1997, Q.12/16 held two Rapporteur meetings jointly with Q.13/16 and Q.14/16: - 10 - 13 June 1997, in Hertzlia (Israel), hosted by RADVision and Vocaltec - 8-11 September 1997, in Sunriver (USA), hosted by Intel After the Sunriver meeting, Q.12/16 work has been carried out through correspondence. 2. Progress of the work The progress of Q.12/16 work is summarized in the following table: ------------------------------------------------------------- Study subject Document Editor Det. Dec. ------------------------------------------------------------- H.222.0|ISO/IEC 13818-1 COM 16-29 S. Okubo 97/0 98/0 Amendments 3 and 4 (GCL - 3 1 Japan) H.222.0|ISO/IEC 13818-1 TD S. Okubo 98/0 98/0 Amendment 5 (GCL - 1 9 Japan) H.310 Correction COM 16-55 S. Okubo 98/0 98/0 (GCL - 9 1 Japan) H.310 Version 2 TD K. Sakai 98/0 98/0 (Fujitsu - 1 9 Japan) H.321 Version 2 COM 16-39 C. Gates 97/0 98/0 (FVC - USA) 3 1 H.bmultipoint TD H. Harasaki 98/0 98/0 (broadband multipoint (NEC - 1 9 systems) Japan) Security for broadband {solicited} TBD TBD systems* VBR aspects M. Nilsson TBD TBD (BT - UK) H.246 Annex (broadband {solicited} TBD TBD system interworking) ------------------------------------------------------------- * Security for broadband systems address ATM specific considerations; generic specifications are covered by H.235. The major work items toward determination of H.310 Version 2 and H.bmultipoint are listed as follows: H.310 Version 2 - Reflection of H.310 Implementers Guide - Reflection of corrected H.320/H.321 interoperation mode stack of RAST-5 terminals - Inclusion of procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals - Reflection of the advice from SG11 regarding the use of B- HLI for resourceId indication. H.bmultipoint - Reflection of the Sunriver meeting discussion outcome - Inclusion of basic communication procedures using H.245 control and H.310 VFS C&I for the video switching and video mixing multipoint - Discussion of clocking issues - Review of the call setup procedures in the light of point- to-multipoint configuration These and other items need be further reviewed and discussed at this meeting. 3. Objectives of this meeting - Decision of H.222.0|ISO/IEC 13818-1 Amendments 3 and 4 - Decision of H.321 Version 2 - Approval of H.310 Correction - Determination of H.310 Version 2 - Determination of H.bmultipoint - Determination of H.222.0|ISO/IEC 13818-1 Amendment 5 - Discussion on security, VBR and interworking aspects - Production of liaison statements to relevant groups - Discussion on future direction 4. Particular items needing the guidance of WP2 1) Forward referencing to the SG11 definition H.321 Version 2 relies on SG11 definition of new signalling capabilities: - Section 7.3"End Station Identifier" in Q.2941.1 GIT - Section C.4parameter "X"in a Q.2931 Notification Indicator IE At the time of decision of H.321 Version 2, they are under development in SG11. A possible solution will be to issue Implementers Guide of H.321 when SG11 has completed these works. 2) Future direction of standardizing ATM-based audiovisual communication systems H.310 Version 2 and H.bmultipoint will provide the basic set of specifications for the ATM-based audiovisual communication systems. The next step target should be set as part of the future H-series workplan with cosideration of the current level of interest in the ATM-based systems. ____________________________ *Contact: Sakae OKUBO Tel.: +81 3 5351 0181 Graphics Communication Laboratories Fax: +81 3 5351 0184 Tokyo, Japan E-mail: okubo(a)gctech.co.jp

1 0

FYI - H.263 RTP Packetization
by Jim Toga 20 Jan '98

20 Jan '98

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Author(s) : C. Maciocco, J. Ott, C. Bormann, C. Zhu, L. Cline, D.Newell, G. Sullivan, G.Deisher, S. Wenger Filename : draft-ietf-avt-rtp-h263-video-01.txt Pages : 10 Date : 14-Jan-98 This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263. The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode (ISD), the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options. The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries. With the independent segment decoding option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others. The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference fra Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-h263-video-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv(a)ds.internic.net" Content-Type: text/plain Content-ID: <19980115112135.I-D(a)ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h263-video-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980115112135.I-D(a)ietf.org> --OtherAccess-- --NextPart-- ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Re: H.323 delta doc
by Toby Nixon 19 Jan '98

19 Jan '98

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(a)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(a)MICROSOFT.COM on 01/16/98 09:57:39 PM > > Please respond to ITU-SG16(a)mailbag.jf.intel.com > > To: ITU-SG16(a)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(a)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(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 > > >------------------------------------------------------ > > > > > > > > >

1 0

Re: H.323 delta doc
by Pete Cordell 19 Jan '98

19 Jan '98

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(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >Sent: 18 January 1998 08:08 >To: ITU-SG16(a)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(a)MICROSOFT.COM on 01/16/98 09:57:39 PM > >Please respond to ITU-SG16(a)mailbag.jf.intel.com > >To: ITU-SG16(a)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(a)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(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 >> >------------------------------------------------------ >> > >

1 0

DAVIC Call for Proposals CFP11
by Sakae Okubo 18 Jan '98

18 Jan '98

Dear SG16 colleagues, Attached please find DAVIC announcement regarding its Call For Proposals (CFP11): End to End Digital Audio Visual Systems over IP based Networks, Storage in the Home, and Content Contribution Systems CFP11 Word document has been placed at /9801_Gen directory as follows: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/DAVIC_11.zip Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** DAVIC Call for Proposals for IP based Networks, Storage in the Home, and Content Contribution Systems. Dear DAVIC Members, As those of you who were at the Monterey Meeting will be aware, great progress was made in agreeing the 11th Call for Proposals for DAVIC, the responses to which will be considered at the next DAVIC meeting on March 9-13 in Milan, Italy. This CFP represents a very important stage in our development of the DAVIC Specifications. DAVIC has a unique opportunity to contibute to the whole systems design of emerging services based on IP networks and local or distributed mass storage systems in a way that no other organisation in the world currently can. Please make known the importance of this opportunity in all relevant areas of your company, and be sure to respond in good time for the very important meeting in Milan. The results of this work will be published in December 1998. You only have until February 13th to inform Nicola Bellina of your intention to respond and until February 28 to work out the detail of your company's response. I wish a Happy New Year to you all. Let us make this the big year for DAVIC ! Regards Hiroshi Yasuda 14 January 1998

1 0

Re: H.323 delta doc
by Scott Petrack 18 Jan '98

18 Jan '98

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(a)MICROSOFT.COM on 01/16/98 09:57:39 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)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(a)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(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 > >------------------------------------------------------ > >

1 0