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

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 13 Feb '98

13 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

Re: Access to ITU-T Ties System
by Jerome Cabassu 11 Feb '98

11 Feb '98

Good afternoon, We used to have an ITU userid and password to the TIES system of ITU in SITA, but when trying to retrieve a document on ITU website, there was always a problem. The support told us that we were now, from January 1998, restricted to ITU on-line. The question is : how can we access the documents such as contributions ? Especially, I would like to retrieve contribution COM 16-23 E but cannot access neither the web site, nor the ftp site. I would be most grateful if you could help me on the above, or give me the email of John Magill to contact him directly. I look forward to your reply and remain, Yours faithfully Jerome Cabassu SITA (Societe Internationale de Telecommunications Aeronautiques) R&D - Teleconferencing group 26, Chemin de Joinville - Case 31 1216 Cointrin - Geneva / Switzerland Ph : (41 22) 710 02 15 Fax : (41 22) 710 02 27 Email : jc(a)gva.sita.int >Only people from ITU-T State or Sector Members - actively >involved in the standardization work of ITU-T SG16 - >can request from the ITU userid and password to the TIES system of ITU. >New users have to specify their need to access to the informal FTP Area of SG16. >There are the available documents - of course far not all - of the >last ITU-T SG16 meeting. > >More Info from John Magill possible. He is the responsible officer >to EDH in SG16. > >Regards, > >Istvan Sebestyen

1 0

Re: Security ASN.1 in H.225.0
by Jim Toga 10 Feb '98

10 Feb '98

Orit, The idea behind the nested 'cryptoToken' was specifically to allow for any of the pre-defined tokens to be 'double-wrapped' as one of the choices. In terms of redifining this as a sequence, that is allowed for by the parent structures that include the CryptoH323Token as a 'SEQUENCE OF'. With reference to the 'inconsistencies' you are correct, the comments are a bit mixed up. They should look like the following. jimt. { cryptoEPPwdHash SEQUENCE { alias AliasAddress, -- alias of entity generating hash timeStamp TimeStamp, -- timestamp used in hash token HASHED { EncodedPwdCertToken -- generalID set to GatekeeperId -- } }, ^^^^^^^^^^^ cryptoGKPwdHash SEQUENCE { gatekeeperId GatekeeperIdentifier, -- GatekeeperID of GK generating hash timeStamp TimeStamp, -- timestamp used in hash token HASHED { EncodedPwdCertToken -- generalID set to alias -- } }, ^^^^^^^ cryptoEPPwdEncr ENCRYPTED { EncodedPwdCertToken -- generalID set to Gatekeeperid --}, cryptoGKPwdEncr ENCRYPTED { EncodedPwdCertToken -- generalID set to alias --}, ^^^^^^ cryptoEPCert SIGNED { EncodedPwdCertToken -- generalID set to Gatekeeperid -- }, cryptoGKCert SIGNED { EncodedPwdCertToken -- generalID set to alias -- }, cryptoFastStart SIGNED { EncodedFastStartToken }, nestedcryptoToken CryptoH323Token, ... } At 12:17 PM 2/10/98 -0500, you wrote: >Hello! > >Although we don't have the final H.225.0 version yet, I have questions regarding the following definition: > >CryptoH323Token::= CHOICE >{ > cryptoEPPwdHash SEQUENCE >{ > alias AliasAddress, -- alias of entity generating hash > timeStamp TimeStamp, -- timestamp used in hash >token HASHED { EncodedPwdCertToken -- generalID set to 'alias' -- } > }, > cryptoGKPwdHash SEQUENCE >{ >gatekeeperId GatekeeperIdentifier, -- GatekeeperID of GK generating hash > timeStamp TimeStamp, -- timestamp used in hash >token HASHED { EncodedPwdCertToken -- generalID set to Gatekeeperid -- } > }, > cryptoEPPwdEncr ENCRYPTED >{ EncodedPwdCertToken -- generalID set to Gatekeeperid --}, > cryptoGKPwdEncr ENCRYPTED >{ EncodedPwdCertToken -- generalID set to Gatekeeperid --}, > cryptoEPCert SIGNED { EncodedPwdCertToken -- generalID set to Gatekeeperid -- }, > cryptoGKCert SIGNED { EncodedPwdCertToken -- generalID set to alias -- }, > cryptoFastStart SIGNED { EncodedFastStartToken }, > nestedcryptoToken CryptoH323Token, > ... >} > >1. What is the meaning a recursive definition of "nestedcryptoToken" as a part of the general CHOICE clause? Shouldn't it be like it is shown below (i.e. providing a "layered" encription) , for example? >CryptoH323Token::= SEQUENCE >{ cryptoNewName CHOICE > { > cryptoEPPwdHash SEQUENCE >{}, > cryptoGKPwdHash SEQUENCE >{}, > cryptoEPPwdEncr ENCRYPTED >{ EncodedPwdCertToken -- generalID set to Gatekeeperid --}, > . > . > . > cryptoFastStart SIGNED { EncodedFastStartToken }, > ... > } > nestedcryptoToken CryptoH323Token >} > >2. It seems that there are at least two inconsistencies regarding the two following definitions >"generalID set to Gatekeeperid" and "generalID set to alias" >in the clause above. Please, revise the remarks for the following fields: >cryptoEPPwdEncr >cryptoGKPwdEncr >cryptoEPCert >cryptoGKCert > >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-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