- sg16-avd - lists.packetizer.com

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

Delayed SG16 contribution from Siemens AG/Germany
by Sakae Okubo 14 Jan '98

14 Jan '98

Dear Q.12-14/16 experts, >>you find enclosed in the attachment the delayed SG16 contribution >>from Siemens AG/Germany as zipped Word7 document. >> >>The contribution has the title: "Approach for T.120 Security and Threat >>Analysis" >> >>Please, assign an (APC) number for the delayed contribution, insert >>it on the title page and put the document in the appropriate directory >>on the Q12-Q14-FTP server - thank you! Mr. Euchner's Delayed Contribution has been placed at the GCL ftp site as requested (except assigning APC number this time because all documents are managed by ITU-TSB): ftp://itu-t:sg15!avc@ftp.gctech.co.jp/t120_sec_ME.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 ********************************************************************

1 0

Section_8.3_rev to include point-to-multipoint VC connection configuration (root initiated join)
by Li Yan 14 Jan '98

14 Jan '98

Dear Mr. Okubo, Mr. Harasaki, and other Q.12/16 experts, Since the current Section_8.3 only covers the basic multipoint procedures for point-to-point VC connection configuration, I try to add more text in this section to include the point-to-multipoint case. Please review the attached Section_8.3_rev. There are still some information missing, I think, such as Information Elements tables for SETUP on point-to-multipoint call. Current Annex A describes Q.2971 multicast call setup and release procedures but does not have detailed information. Do we need to put more information on Annex A or to add some text in Section 6? Any thought? 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. ****************************************************************

2 1

Clock synchonization of H.bmultipoint conference
by Hidenobu Harasaki 13 Jan '98

13 Jan '98

Dear Mr. Okubo and other Q.12/16 experts, This is a draft for the clock synchonization section. It is a contribution as one of Q.12 experts, not an editor. Although attached text is not yet complete, I would like to hear the comment/suggestion from other experts. {Assumption: I guessed that a highly stable 27MHz clock is only recoverable when a common network clock is available. The common network clock availability, however, seems to be impractical especially in customer premises ATM network environments, I would like to propose clock synchonization/adaptation shall be achieved solely in an H.bmultipoint MCU. } ------------------------------------------------------------------------ 7.5 Clock synchronization 7.5.1 General There are two independent clock sources need to be considered in H.bmultipoint conference: 1) 27MHz system time clock (STC) in each H.310 terminal and MP, 2) transmission clock for the multiplexed stream. Recommendation H.310 leaves STC synchronization as further study, current H.310 terminals may generate their STCs as follows: 1) by a local oscillator (local master), Note: In this case a frame synchronizer for video input or a video camara with clock reference input is necessary. 2) by referencing video input (video slave), 3) by referencing network clock (network slave), 4) by referencing recovered system_clock_frequency of the decoder (receiver slave). Transmission clock synchronization is also left as further study, the followings are possible to generate transmission clock in each terminal and MCU: 1) by referencing common network clock (common network clock), 2) by referencing receiver clock (local network clock), Note: Local ATM switch generates the network clock, not referencing public B-ISDN network clock. 3) by a local oscillator (local oscillator), 4) by referencing video input (video input). 7.5.2 STC generation in MP STC frequency in an MP shall conform to H.222.0 Section 2.4.2.1. PCR tolerance due to PCR modification during re-multiplexing in the MP shall conform to H.222.0 Section 2.4.2.2. Since there exists the case that STC frequency in each terminal is independent, MP shall adjust the difference. One possible implementaion is to equip a frame synchronizer for video and sample clock synchonizer for audio. MP may use a recovered STC of a selected peer as a re-multiplexing STC source, only if the stability of the recovered STC satisfies H.222.0 requirements. The ITU-T Timing Descriptor defined in H.222.1 will help the STC recovery process. When the recovered STC is used and video is switched, PCR discontinuity happens. Within a certain period of time after the PCR discontinuity, frame skip or repeat and/or audio discontinuity may occurs by the PCR clock recovery and AV synchronization processing. 7.5.3 Transmission clock synchronization Common network clock is not always available to all of the terminals. It is especially true in customer premises ATM networks. Thus, H.bmultipoint MCU and terminals shall operate under the environment that each terminal has its own transmission clock source. The receiver side of the MCU and each terminal shall recover the transmission clock by the method indicated through AAL paramter IE. {Source clock frequency recovery method IE only exists in AAL1? How can we inform the source clock frequency recovery method when we use AAL5?} ------------------------------------------------------------------------ > 4. Bit rate management > > We will need a sub-section in Section 7 which addresses how to manage > elementary stream and multiplexed stream bit rate, particularly in the > switched video environment. The description may not be normative, but > give some guidance to the implementors. Yes, I agree. FlowControlCommand can be used to limit the bit rate of video elementary stream. Is it apparent that a multiplexer will insert TS null packets to fill the transmission bit rate? I will try to describe some text tomorrow. 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

Q13 related whites
by Sakae Okubo 12 Jan '98

12 Jan '98

Dear SG16 colleagues, Dale Skran> I have just place zipped versions of all Q13 whites in Dale Skran> word 6.0 format in the incoming directory. Thank you Dale for your efforts, I have placed all of them at: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/ with file names like H2250v2w_6.zip. I have found that all the white contributions up to COM 16-58 are now available at the ITU web site: http://www.itu.ch/itudoc/itu-t/com16/contr.html Files can be retrieved by TIES registered users. Editors are encouraged to see your documents because there may be some editorial changes from our submission during the process of publication. 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

WP2/16 meeting plan by Mr. Tosco
by Sakae Okubo 11 Jan '98

11 Jan '98

Dear SG16 colleagues, Attached please find the update of WP2/16 meeting plan provided by Mr. Tosco. Its Word version is available at: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/wp2_sche.doc 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 ******************************************************************** DRAFT MEETING SCHEDULE FOR THE WP2/16 MEETING Date AM Schedule PM Schedule Mon 26 SG16 Plenary WP2 Plenary Tue 27 Q3, Q11, Q12, Q13 SG16 Plenary Wed 28 Q1, Q11, Q12, Q13 Q3, Q11, Q12, Q13 Thu Q3, Q11, (Q12,13,14)#1 Q3, Q11, |(Q3,12,13.14) 29* (Q12,13,14)#1 |#3 Fri Joint WP1, 2, 3 Q1, Q11 (Q3,12,13,14)#2 30* Mon 2* Q1, Q3, Q1, Q3, |Q1, Q3, Q13 (Q11,12,13,14)#5 (Q11,12,13,14,15)#|(Q11,15)#6 4 Tue 3 Q1, Q11, Q12, Q14 Q1, Q2, Q13 Wed 4 WP2 Plenary WP2 Plenary Thu 5 - SG16 Plenary Fri 6 SG16 Plenary SG16 Plenary Notes: *Thu 29, Fri 30 and Mon 2 have split AM or PM Schedules. (Qxx, Qyy) - Questions in parentheses meet in joint session. #1- H.235V2, H.MediaMIB, T.130/H.AVC #2- T.120 series Audio[Video requirements #3- T.120 security #4- Discussion of future directions, last 1/4 day in the afternoon #5- Conference control, H-245V4, H.246 addition and other common protocols #6- Future direction of advance video as it relates to H.324L

1 0

Real-Time fax documents
by Dale L. Skran 11 Jan '98

11 Jan '98

I have just put in the Incoming directory of the GCL site the following: 1)TF21.doc - this is a set of comments sourced by me on the SG8 Real-time fax document. It will be discussed at the SG8 Q4 experts meeting next week. Comments welcome. 2)T.fax2R12.doc - this is the current (determined) draft of T.ifax2 that will be discussed and against with the comments of TF21.doc were made. Sourced Rapporteur SG8 Q4 H. Silbiger. It is my hope to determine a real-time fax annex to H.323 at the January meeting. TF21.doc contains an initial draft of this annex, which is not very long, but which may contain controversial passages. Email sent soon will have the greatest impact. Please cc the whole list. Dale Skran Rapporteur SG16 WP WP2 Q13

1 0