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

Editorial comments to Annex A to H.bmultipoint
by Sakae Okubo 17 Jan '98

17 Jan '98

Dear Mr. Haradaki, Here are some editorial observations to your Annex Ato H.bmultipoint. 1) Section 4/Annex A to H.bmultipoint The Table A.1/H.bmultipoint is the Information Elements ... ==> Table A.1/H.bmultipoint shows the Information Elements 2) Table A.2/H.bmultipoint, AAL Parameters, AAL-5 Note: Default value for the video service component in this specification is 376 bytes. N is an integer. ==> Note: Default value is 376 bytes as per H.222.1. N is an integer. 3) Table A.2/H.bmultipoint, Endpoint Reference There is a note as follows: Note: Endpoint Reference = 0 if the first party establishment Does this mean that when MCU sets up the first leaf, it shall encode Endpoint Reference as 0? If so, the wording should be "for the first party establishment"? 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

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

16 Jan '98

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 16 Jan '98

16 Jan '98

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

Draft H.310 version 2
by Kiyoshi SAKAI 16 Jan '98

16 Jan '98

Dear SG16 colleagues, I have uploaded the draft revision ducument of H.310 to the "Incoming" directory of GCL's ftp site. This document will be submitted to the coming SG16 meeting as a TD(Temporary Document). The file name is "H310v2-A.doc" and it has been created by MS-Word97 (US version) then converted to the ver.6.0/95 compatible format. Main changes against existing version 1 are as follows: 1) Changes proposed in APC-1259(Contribution to the Sunriver meeting) - Corrections described in the H.310 Implementers Guide are imported. - An informative description in the H.310 Implementers Guide about H.310 CorrelationID is imported as a new Appendix. 2) Changes made after APC-1259 - Proposed corrections in COM 16-55 and APC-1300(Contribution to the Sunriver meeting) regarding the H.320/H.321 interoperation mode stack of RAST-5 terminals are adopted. - Proposed additions in APC-1299(Contribution to the Sunriver meeting) regarding the procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals are included. - According to the liaison from SG11/WP1(Sep.1997, TD-XX for meeting), descriptions for the use of resourceId within the B-HLI in the absence of Q.2941 are totally deleted. - Proposed addition by the Editor of H.bmultipoint regarding the additional VC setup procedure in the presence of MCU is adopted. (This needs discussion during the SG16 meeting period). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please pay attention to the last item. If you have any problems to reproduce the document, please let me know. Best regards, K. Sakai ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

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

15 Jan '98

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 >------------------------------------------------------ >

2 1

revised version of TF21 on gcl incoming area
by Dale L. Skran 15 Jan '98

15 Jan '98

RT fax interested parties: Please find in the GCL incoming area TF21-revised-3-ww6.doc which is the current revision of both a proposed Annex A for T.ifax2 and proposed Annex IV for H.323 The ideas of TF21 have been generally although not finally accepted by the meeting, with the idea that call realated messages will be removed from T.ifax2 and replaced by a new Annex, to be determined at the next SG8 meeting in June 98, that is H.323 compatible. My proposal is to seek to determine Annx IV of H.323 at our January meeting. Note that T.ifax2 is already determined, but the white has not yet been issued. Comments welcome. This will all play with fast start issues as interoperability hinges on using fast start procedures. Dale Skran Rapporteur Q13 WP2 SG16

2 1

H.321 Version 2 (COM 16-39 E)
by Sakae Okubo 15 Jan '98

15 Jan '98

Dear Corey, I have compared COM 16-39 E (H.321 V2 for decision) with your submission using the Word 6 revision tool. There are some small changes of editorial style, but nothing substantial. We need not issue a Rapporteur TD in this regard. 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

Liaison statements from SG11
by Sakae Okubo 15 Jan '98

15 Jan '98

Dear Q.12-14/16 experts, I have placed the following four SG11 liaison statements at the 9801_Gen directory: LS_11_01.zip: H.310 Correlation Identifier In DSS 2 Recommendation Q.2941 LS_11_02.zip: AAL type indication for H.310 Terminal Protocol Identification LS_11_03.zip: Separation of call and bearer control LS_11_03.zip: Adaptive Transmitter Timing Notification Mechanism For DSS 2 We should review and respond to them at the forthcoming SG16 meeting. 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

Re: Section_8.3_rev to include point-to-multipoint VC connection
by Li Yan 15 Jan '98

15 Jan '98

Dear Mr. Harasaki, Thanks for your confidence in me. The followings are my comments regarding Section_8.3. If you think using Section_8.3 for both point-to-point and point-to-multipoint configurations is ok, I can modify this specific section to reflect your comments. >Since initial VC is used for a transport of H.245 messages, it must be >bi-directional point-to-point VC connection. Yes, you are right. >Either MCU or aterminal can initiate the call. In the root-initiated point-to-multipoint case, it's still MCU who should initiated the call since the addditional VC is setup by the calling party, the party who initiated the first VC (Do I understand H.310 procedure right?) >A point-to-multipoint VC connection can only be used in an additional >VC setup phase. The additional VC is used for AV communication. You are right. I should only put change in the addtional VC setup. >We may need to put some guidelines for selecting point-to-point and >point-to-multipoint VC. In the case of one SOT and many ROTs case >shown in Figure 3 (b), MCU shall initiate point-to-multipoint VC >connection as an additional I agree. But I don't want to make it mandatory. >I would like to add something like below in Section 7 or 8. > "MCU shall use point-to-multipoint VC connection for all receive only >terminals. ROT terminals are always receive only. I understand that it's more efficent to use point-to-multipoint VC connection for ROTs but I am not so sure about making this mandatory. I do not want to exclude the case, where for some reason, MCU does not support Q.2971 but still want to support ROTs. Then in this case, MCU should be able to use point-to-point connection to support ROTS. >If I understand correctly, Information Elements that are used for >point-to-multipoint VC setup is exactly same as a uni-directional >point-to-point VC setup, except user plane configuration field of B-BC >and Endpoint Reference IE. >I will cut from Table B.3/H.310, modify it and paste the revised table >into Annex A. This is good enough for me. Li Yan **************************************************************** Lucent Technologies Phone: 732-957-3877 2E-433, 200 Laurel Ave., Fax: 732-957-5627 Middletown, NJ, 07733 E-amil:lyan@lucent.com U.S.A. ****************************************************************

3 3

Re: Section_8.3_rev to include point-to-multipoint VC connection
by Hidenobu Harasaki 15 Jan '98

15 Jan '98

Dear Mr. Okubo, Mr, Sakai, Ms. Li Yan and other Q.12 experts, Mr. Okubo, thank you for your help on additional VC setup procedure. After I sent my previous mail, I checked H.310 Phase A3, and found the problem for H.bmultipoint. Problem: If a leaf terminal initiated initial VC ("meet-me") and the MCU would like to add the terminal as a point-to-multipoint leaf, H.310 Phase A3 description does not seem to allow the MCU to initiate an additional VC setup. {Is this true?} Possible solution (that I propose): Add a description for MCU and terminal case to H.310 version 2 Phase A3 as following: (If this proposal is accepted, we need to revise H.bmultipoint 8.3 Phase C, also. ) ------------------------------------------------------------------------ In this phase, and based on the communication mode determined above, the calling terminal, that is, the one that initiated the first VC SETUP message, shall firstly indicate the characteristics of the additional VC(s) to the remote end using the H.245 NewATMVCIndication message, and then shall setup the additional VC(s) with the appropriate parameters, such as bitrate and AAL type, for the transfer of the audiovisual and other data between the two H.310 terminals. If the calling terminal is talking to an MCU, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that is known by a terminalType during Master Slave Determination, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the calling terminal shall wait for the indication of the additional ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ VC(s) characteristics and the H.245 NewATMVCIndication message. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The additional VC(s) with the appropriate parameters, such as bitrate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and AAL type, for the transfer of the audiovisual and other data ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ shall be initialted by the MCU. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NOTE - This allows the remote end to receive the H.245 NewATMVCIndication message before responding to the VC setup message. ------------------------------------------------------------------------ I would like to hear any comments or other possible solutions from experts. Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0