- sg16-avd - lists.packetizer.com

Add me into this alias
by Jenn Yeh 18 Feb '98

18 Feb '98

Hi: I am in Sun's Networking Product Group. Brnet Browning and I will track on Study Group 16 activitie for Sun in future. Please add my Email (jenn.yeh(a)eng.sun.com) into itu-sg16(a)mailbag.jf.intel.com alias. Thanks, Jenn -------------------------------------------------------------------------------- ______ Jenn Yeh, Internet Telephony/Staff Engineer /_____/\ /_____\\ \ SUN Microsystems Inc. /_____\ \\ / 140 Scott Drive, MS UMPK03-213 /_____/ \/ / / Menlo Park, CA 94025 /_____/ / \//\ \_____\//\ / / email: jenn.yeh(a)eng.sun.com \_____/ / /\ / phone: +1.650.688.9404 \_____/ \\ \ fax: +1.650-688-9007 \_____\ \\ \_____\/ SunTeleco Web site: http://www.sun.com/products-n-solutions/sw/SunXTL Java Telephony API specification Web site: http://java.sun.com/products/javatel/index.html --------------------------------------------------------------------------------

1 0

H.245 OCTET STRINGs
by Jim Toga 18 Feb '98

18 Feb '98

It has come to my attention that there are a number of OCTET STRINGS defined in H.245 along the lines of "h235Key OCTET STRING (SIZE(1..65535))" "value OCTET STRING (SIZE(1..65535))" "certificateResponse OCTET STRING (SIZE(1..65535)) OPTIONAL" The problem with these difinitions is that with the terminating NULL ( I think...) the lentgh goes over by one byte, a 64k block of data. The OSS compiler generates the following warning, which goes away if we change the lenth to '65534'.... "h245.asn", line 1941 (MULTIMEDIA-SYSTEM-CONTROL): C0470W: The size of the generated C structure for the SET OF or SEQUENCE OF exceeds 64K bytes and may adversely affect CPU and memory performance. Consider use of the LINKED or UNBOUNDED directive. Comments?....fixes?...... 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*** *************************************************************************

2 2

Re: H.245 OCTET STRINGs
by Mike Nilsson 18 Feb '98

18 Feb '98

Jim, I think it is just a matter of compiler options. We are using the OSS tools. If no options are set, there are many such warnings, and the resulting H.245 structure is about 32 Mbytes. This seems to be because by default all parts of the structure (except object IDs) are included, as specified, in a union. To eliminate the warnings and reduce the structure size to something manageable we have used the options --<LINKED SET OF, SEQUENCE OF , OCTET STRING>-- This causes the compiler to create a structure with pointers to objects rather than a structure with the objects included directly. Best regards Mike ************************************************************************ * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [MLB3/11] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * ************************************************************************ >---------- >From: Jim Toga[SMTP:jtoga@jf.intel.com] >Sent: 17 February 1998 21:44 >To: itu-sg16(a)mailbag.jf.intel.com >Cc: mike.nilsson(a)BT-SYS.BT.CO.UK; dskran(a)ascend.com; >mreid(a)videoserver.com >Subject: H.245 OCTET STRINGs > >It has come to my attention that there are a number of OCTET STRINGS >defined in H.245 along the lines of > > "h235Key OCTET STRING (SIZE(1..65535))" > > "value OCTET STRING (SIZE(1..65535))" > > "certificateResponse OCTET STRING (SIZE(1..65535)) >OPTIONAL" > >The problem with these difinitions is that with the terminating NULL ( >I >think...) the lentgh goes over by one byte, a 64k block of data. The >OSS >compiler generates the following warning, which goes away if we change >the >lenth to '65534'.... > > >"h245.asn", line 1941 (MULTIMEDIA-SYSTEM-CONTROL): C0470W: The size of >the >generated C structure for the SET OF or SEQUENCE OF exceeds 64K bytes >and may >adversely affect CPU and memory performance. Consider use of the >LINKED or >UNBOUNDED directive. > > >Comments?....fixes?...... > >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

Q.931 for MCU
by Vincent Chen 17 Feb '98

17 Feb '98

Dear All, Is it correct that an MCU just act as a Q.931 USER but not a Q.931 NETWORK? Thanks! Best Regards, Vincent Chen E-mail:VincentSHChen@acer.com.tw

2 1

Re: Q.931 for MCU
by isabelle haignere 17 Feb '98

17 Feb '98

Hi Vincent, What does it mean ? From the user information point of view, you mean ? Isabelle Haignere isabelle.haignere(a)cnet.francetelecom.fr At 14:48 17/02/1998 GMT, you wrote: >Reply-To: "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16(a)mailbag.jf.intel.com> >Importance: Normal >X-Mailer: ccMail Link to SMTP R8.00.01 >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit > > Dear All, > > Is it correct that an MCU just act as a Q.931 USER but not a Q.931 > NETWORK? Thanks! > > Best Regards, > Vincent Chen > E-mail:VincentSHChen@acer.com.tw > > > --------------------------------------------------- Isabelle HAIGNERE FT/BD - CNET/DSE/SGV 38-40 rue du general Leclerc 92131 Issy-Moulineaux Tel : 33 1 45 29 40 08 Fax : 33 1 45 29 52 94 Email : isabelle.haignere(a)cnet.francetelecom.fr ---------------------------------------------------

1 0

Re: Q.931 for MCU
by Ami Amir 17 Feb '98

17 Feb '98

Hi Vincent All of the Q.931 messages are user side (end point, MCU and gateway) Ami Amir RADVision -----Original Message----- From: Vincent Chen [SMTP:vincentshchen@ACER.COM.TW] Sent: Sat, January 17, 1998 2:21 PM To: ITU-SG16(a)mailbag.jf.intel.com Subject: Q.931 for MCU Dear All, Is it correct that an MCU just act as a Q.931 USER but not a Q.931 NETWORK? Thanks! Best Regards, Vincent Chen E-mail:VincentSHChen@acer.com.tw

1 0

H.323, H.320 and H.324
by Brian A. Root 17 Feb '98

17 Feb '98

Hi. My name is Brian Root. I am trying to organize a family of products for a moderate size wireless Internet access company to offer for video conferencing. The company provides wireless 10Mbs connections two hops away from T3 or greater connections to the InterNet and one hop between their 40 areas of current coverage, so bandwidth is not a problem, interconnectivity is. I know about VideoServers product line that allows interconnectivity/bridging between H.323 and H.320 products. What I do not know is the interconnectivity between H.323, H.320 and H.324 products. From my understanding, products that support H.324 are mainly for dial up connectivity over POTS lines, but also provide LAN connectivity. Is this the connectivity that is represented by H.323? If not, do you know of any products like the VideoServer product that bridge H.320, H.323 and H.324 products? Thank you. Brian Root UBI 504-266-3560

1 0

Re: Compatibility
by Chris Purvis WVdevmt-WS 17 Feb '98

17 Feb '98

>I have purchased a TV Phone which uses ITU-T Standard H.324. Will I be able >to videoconference with someone using an H.320 system. Not until someone builds the appropriate gateway. ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Compatibility
by Fp41326＠AOL.COM 16 Feb '98

16 Feb '98

I have purchased a TV Phone which uses ITU-T Standard H.324. Will I be able to videoconference with someone using an H.320 system. Thanks Joe Peck

1 0

None
by Martin Laczko 15 Feb '98

15 Feb '98

LIST GLOBAL/Q.850

1 0

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

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

Security ASN.1 in H.225.0
by Orit Levin 10 Feb '98

10 Feb '98

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 0

Access to ITU-T Ties System
by Istvan Sebestyen 10 Feb '98

10 Feb '98

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 At 16:30 10.02.1998 +0100, isabelle haignere wrote: >Is it possible to receive the same piece of information : where is it >possible to pick up the unified H323 change document (is there the same >document for H245 : unified doc, for H225 ) > >Thank you very much > > >Best regards >--------------------------------------------------- >Isabelle HAIGNERE > >FT/BD - CNET/DSE/SGV >38-40 rue du general Leclerc >92131 Issy-Moulineaux > >Tel : 33 1 45 29 40 08 >Fax : 33 1 45 29 52 94 >Email : isabelle.haignere(a)cnet.francetelecom.fr > >--------------------------------------------------- > > ------------------------------------------------------------------ Istvan Sebestyen Siemens AG Standardization, Large Networks PN GS 94, Private Communications Systems Group, Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me occasionally may get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

1 0

Re: TD72PLEN
by isabelle haignere 10 Feb '98

10 Feb '98

Is it possible to receive the same piece of information : where is it possible to pick up the unified H323 change document (is there the same document for H245 : unified doc, for H225 ) Thank you very much Best regards --------------------------------------------------- Isabelle HAIGNERE FT/BD - CNET/DSE/SGV 38-40 rue du general Leclerc 92131 Issy-Moulineaux Tel : 33 1 45 29 40 08 Fax : 33 1 45 29 52 94 Email : isabelle.haignere(a)cnet.francetelecom.fr --------------------------------------------------- At 13:58 10/02/1998 GMT, you wrote: >Reply-To: "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16(a)mailbag.jf.intel.com> >Importance: Normal >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: 7bit > >Can somebody point me to (or send me) the electronic copy of the TD72(PLEN) - i.e. the unified H.323 change document. >This file is not stored on the Geneva itu ftp server currently. > >Thanks, >Karl Klaghofer >-------------------------------------------- >Karl Klaghofer >Siemens AG >Tel.: +49 89 722 31488 >Mail: karl.klaghofer(a)mch.pn.siemens.de > > > --------------------------------------------------- Isabelle HAIGNERE FT/BD - CNET/DSE/SGV 38-40 rue du general Leclerc 92131 Issy-Moulineaux Tel : 33 1 45 29 40 08 Fax : 33 1 45 29 52 94 Email : isabelle.haignere(a)cnet.francetelecom.fr ---------------------------------------------------

1 0