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

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

Re: H.323 delta doc
by Bruce Allen 11 Jan '98

11 Jan '98

DUh. I forgot to attach it! -----Original Message----- From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] Sent: Friday, January 09, 1998 6:01 PM To: ITU-SG16(a)mailbag.jf.intel.com Subject: H.323 delta 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 ------------------------------------------------------ << File: H323DL.DOC >>

2 1

H.323 delta doc
by Gary A. Thom 09 Jan '98

09 Jan '98

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

1 0

Changes to the H.450.1 and H.450.2 white drafts
by Korpi Markku PN VS LP3 09 Jan '98

09 Jan '98

Greetings, Attached is a delta document describing the the changes to the H.450.1 and H.450.2 white drafts to address the issues discussed on the reflector. There are currently no changes to H.450.3. The intent is for this change document and the final documents to be submitted next week for distribution to the SG16 meeting. Please let me know if I've missed anything. Best Regards, Markku ---------------------------- Markku Korpi korpim(a)scn.de Siemens Private Communication Networks Tel +49 89 722 34570 Mobile +49 171 3345338 Fax +49 89 722 39335

1 0

Phase transition in H.310 and H.324
by Sakae Okubo 09 Jan '98

09 Jan '98

Dear SG16 colleagues, Attached please find my correspondence with Seung ho SHIN, Korean Telecom, regarding the phase change from A4 (logical channels setup) to B (audiovisual communication) in H.310 terminals. The same discussion will apply to the phase change from D (initialization) to E (communication) in H.324 terminals. I hope my understanding in the reply is correct. 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 ******************************************************************** Dear Seung ho SHIN, >In phase A4(logical channels setup), which is one of H.310 call phases >for native H.310 communication, H.310 terminal establishes multiple >logical channels. After completing logical channels setup, H.310 >terminal transit from phase A4 to phase B. The out-going terminal can >know the instant that H.245 completes multiple logical channels setup. >But the in-coming terminal can't know it. > >The in-coming terminal can't know how many the out-going terminal >attempts to setup logical channels. Therefore, the in-coming terminal >doesn't know when it transits from phase A4 to phase B. > >How can I solve this problem? Communication phases set out in Section 7 of H.310 are to describe the communication steps from the start to the end of an H.310 call, not necessarily to specify state machines of the terminal. In case of moving from phase A4 (logical channels setup) to Phase B (audiovisual communication), there is no clear state transition of the terminal as a whole. As soon as a logical channel is in the ESTABLISHED state, its corresponding media content (either of audio, video, data, or video frame synchronous signalling) can be transmitted, thus communication can start. Transmission of multiple media contents can be synchronous, or can be audio first and video later, or can be left as they start according to the terminal design. Data, in particular, may usually start some time after audio and video communications have started. Therefore even in the transmitting side, transition from phase A4 to phase B differs from one logical channel to another. Identification of phase transition at the receiving side similarly depends on each logical channel. Please note, however, that H.245 defines state machines for their signalling entities to assure their operation. I hope this information would help your resuming H.310 terminal implementation. END

1 0