- sg16-avd - lists.packetizer.com

FW: Remote Device Control Conference
by Gary Thom 15 Feb '98

15 Feb '98

FYI, ---------------Original Message--------------- On Thursday May 7, 1998 an audio conference to discuss Remote Device Control (RDC) has been scheduled at 11:00 AM Eastern Time. The telephone number is +1-212-547-0228, with a passcode of 1139. The bridge will be available for 2 hours. [I assume Bruce DeGrasse or John Boucher will forward this information to other reflectors as needed.] -- Murry ----------------------------------------------------------------------- Murry McEntire Senior Engineer networkMCI Conferencing email: Murry.McEntire(a)mci.com phone: 719 535-6954 vnet: 622-6954 MCI, 4177/117, 2424 Garden of the Gods Road, Colorado Springs, CO 80919 ----------------------------------------------------------------------- ----------End of Original Message---------- ------------------------------------- Name: gary thom E-mail: gthom(a)delta-info.com Date: 02/05/98 Time: 01:14:03 -------------------------------------

1 0

Please Add me to the reflector
by Robert Kaplan 13 Feb '98

13 Feb '98

Robert Kaplan Director Product Development AC & E, Ltd 14101 Sullyfield Circle Chantilly, VA 20151 Phone: (703) 968-5700 Fax: (703) 968-4331 rkaplan(a)aceltd.com

2 1

Nested Crypto Token
by Jim Toga 13 Feb '98

13 Feb '98

Orit and others.... Upon further investigation (and memory recovery...) the nested 'cryptoToken' does in fact look like it didn't come out as intended. The intent was to allow for nested generic (H.235) tokens to be passed within the explicit types defined in H.225.0. This would allow tokens to be 'double-wrapped' as one of the choices. In addition it allows for non-standard or manufacturer specific tokens to be presented easily. The bottom line is that the editing changes are extremely minor but result in enabling this (I believe this was simply a typo that got missed in final review...) The line below nestedcryptoToken CryptoH323Token, should change to nestedcryptoToken CryptoToken, If this change cannot be made to H.225.0, I will put it in the implementors guide, and it should be widely publicized. Comments? jimt. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ideal.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

FW: Clarification of tunneling text in H.323v2
by Orit Levin 13 Feb '98

13 Feb '98

Hello Toby! I do agree that it clarifies the procedure, however, I would just like to point out that it has already been written in the "Encapsulation of H.245 Messages within Q.931 Messages " chapter: "A calling endpoint capable of and willing to use H.245 encapsulation shall set the h245Tunneling element to TRUE in the SETUP message and any subsequent Q.931 messages it sends so long as it desires tunneling to remain active. A called endpoint capable of and willing to use H.245 encapsulation shall set the h245Tunneling element to TRUE in the first Q.931 message sent in response to SETUP and in every subsequent Q.931 message it sends so long as it desires tunneling to remain active." 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 -----Original Message----- From: Toby Nixon [SMTP:tnixon@MICROSOFT.COM] Sent: Thursday, February 12, 1998 9:14 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Clarification of tunneling text in H.323v2 After going back over the Tunneling text in H.323v2 on the airplane home, I wished I had added one more clause to the first and second sentences of the second paragraph of the new section 8.2.3, as follows: "shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages,". It would then read like this: If tunneling was being used, the endpoint initiating the separate H.245 connection shall not send any further tunneled H.245 messages on the call signalling channel, shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages, and shall send no H.245 messages on the separate H.245 connection until the establishment of the TCP connection is acknowledged. The endpoint acknowledging opening of the separate H.245 connection shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages, and shall not send any further tunneled H.245 messages on the call signalling channel after acknowledging the opening of the separate H.245 connection. The fact that this is required is implied by the text that follows (which depends on the flag being set FALSE on subsequent messages), but the insertion of these clauses would make it explicit. Does anyone else think this would be helpful? Should we think about putting this in the implementor's guide? Or am I just being my usual verbose self? * 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

1 0

TDs from Geneva
by Sakae Okubo 13 Feb '98

13 Feb '98

Dear Mr. Kajos and other SG16 colleagues, >>Is it possible to place the H.mediamib TD38 and TD53 on the gctech >>site? H.mediamib documents (TD38_wp2.doc and TD53_wp2.ppt) have been placed at: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/ 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-0053 Japan ********************************************************************

1 0

Clarification of tunneling text in H.323v2
by Toby Nixon 12 Feb '98

12 Feb '98

After going back over the Tunneling text in H.323v2 on the airplane home, I wished I had added one more clause to the first and second sentences of the second paragraph of the new section 8.2.3, as follows: "shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages,". It would then read like this: If tunneling was being used, the endpoint initiating the separate H.245 connection shall not send any further tunneled H.245 messages on the call signalling channel, shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages, and shall send no H.245 messages on the separate H.245 connection until the establishment of the TCP connection is acknowledged. The endpoint acknowledging opening of the separate H.245 connection shall set the H245Tunneling flag to FALSE on all subsequent Q.931 messages, and shall not send any further tunneled H.245 messages on the call signalling channel after acknowledging the opening of the separate H.245 connection. The fact that this is required is implied by the text that follows (which depends on the flag being set FALSE on subsequent messages), but the insertion of these clauses would make it explicit. Does anyone else think this would be helpful? Should we think about putting this in the implementor's guide? Or am I just being my usual verbose self? -- 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

1 0

Re: SessionDependency in H.245
by Mark Reid 12 Feb '98

12 Feb '98

SessionDependency was added when the layered video codec support was added. Check the annex on layered video in H.323. (Or AVC's from Intel on the subject) Mark Reid VideoServer Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [SMTP:ITU-SG16@mailbag.jf.intel.com] Sent: Thursday, February 12, 1998 12:13 PM To: ITU-SG16 Subject: SessionDependency in H.245 Hello all! I have a question about a new field in H.245: SessionDependency INTEGER (1..255) OPTIONAL What is it used for? Does it hold a SessionId value? Does anybody have (or remember the # of ) the related TD about it? Thank you, 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

Re: SessionDependency in H.245
by Corey Gates 12 Feb '98

12 Feb '98

> I have a question about a new field in H.245: > SessionDependency INTEGER (1..255) OPTIONAL > > What is it used for? Does it hold a SessionId value? > Does anybody have (or remember the # of ) the related TD about it? > > Thank you, > Orit Levin Orit, I believe this field is used for the layered codec model with H.263+. This is from AVC-1125: "The sessionDependency field is set by the MC to indicate when a session is dependent on another session for meaningful decoding of the its data." I believe sessionDependency identifies the session which has the base layer or enhancement layer for the video (if this is a video session). Hope this helps. Corey corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

1 0

SessionDependency in H.245
by Orit Levin 12 Feb '98

12 Feb '98

Hello all! I have a question about a new field in H.245: SessionDependency INTEGER (1..255) OPTIONAL What is it used for? Does it hold a SessionId value? Does anybody have (or remember the # of ) the related TD about it? Thank you, 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

H.245 Version 3
by Sakae Okubo 11 Feb '98

11 Feb '98

Dear Mike and other SG16 colleagues, I have placed H.245 Version 3 at the GCL ftp site: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/h245ver3.zip which contains the following files: Readme.txt H245NCMD.WW2 is the clean text H245WCMD.WW2 is the change marked document, with changes relative to COM 16-53 H245DELD.WW2 is the delta document, with changes relative to COM 16-53 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-0053 Japan ********************************************************************

1 0