- sg16-avd - lists.packetizer.com

joint meeting with modem experts
by Glen Freundlich 01 Nov '00

01 Nov '00

Regarding the relatively new topics of modem relay or transparent modem in Q13 (H.323 Annex P) and Q14, the modem experts in WP1 have expressed a desire to meet jointly with Q13 and Q14. We have arranged for a meeting on 9 November (the first day of the joint Q12-14 rapporteurs' meeting), starting at 1:30 in the afternoon. We will determine the room for the meeting during the morning session on the 9th. Best Regards, Glen Freundlich

1 0

apc-1960 uploaded
by Greg Ratta 01 Nov '00

01 Nov '00

APC-1960 has been uploaded to the Picturetel site. This contribution proposes that SG 16 should create an SDL representation of ITU-T Recommendation H.248 and presents proposed initial text as the basis for future contribution. Note that John Segers will represent this document during the Rapporteur meeting. This document is also being submitted as a Lucent Technologies contribution to the SG 16 meeting, where I will serve as the contact. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1968 Annex R
by Terry L Anderson 01 Nov '00

01 Nov '00

I have uploaded APC-1968.zip to the avc-site/incoming directory containing APC-1968 Draft H.323 Annex R: Robustness Methods for H.323 Entities as well as a copy with change marks compared to TD-33 from the Portland meeting. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

APC1954, APC1955, APC2016
by Takashi Suzuki 31 Oct '00

31 Oct '00

Dear Experts, I've uploaded the contributions: APC-1954, "Proposal for support of H.324 Annex C multimedia calls in decomposed gateway" APC-1955, "Identification of References to IETF Documents in H.225.0 version 4 (per Recommendation A.5)" APC-2016, "Support of HTTP in H.324" to the incoming directory of the PictureTel FTP server. ftp://standard.pictel.com/avc-site/Incoming/ Best regards, Takashi Suzuki NTT DoCoMo, Inc. Multimedia Labs. TEL : +81 468 40 3515, FAX : +81 468 40 3788 email : suzuki(a)spg.yrp.nttdocomo.co.jp takashi.suzuki(a)ties.itu.int ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-2003
by BOUGANT Fran�ois FTRD/DAC/ISS 31 Oct '00

31 Oct '00

Dear all, Please find in attachment the following contribution : Source : France Telecom Title : Mobility management protocol in H.323 Annex H Best regards. ---------------------------------------------------------------------------- --------------- François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail : francois.bougant(a)francetelecom.fr 38, 40 rue du Général Leclerc Téléphone : (33) 1 45 29 51 84 92794 Issy Moulineaux Cedex 9 Télécopie : (33) 1 46 29 31 42 ---------------------------------------------------------------------------- --------------------------------------

1 0

RE: fastStart element in all Q.931 messages up to and including C onnect
by Danail Kirov 31 Oct '00

31 Oct '00

It seems bullet-prone to me. If the called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect, then The calling endpoint may choose to expect the fastStart in Connect only. At the same time the called endpoint is not required to send fastStart in Connect and may choose not to send fastStart in Connect and as a result the calling endpoint may never get fastStart in Connect and fast connect may fail miserably. Isn't it clear that those are two mutually exclusive choices? 1. The called endpoint is required to include the fastStart element in only one Q.931 message. 2. The called endpoint is required to repeat the exact same fastStart element in all subsequent message up to and including Connect. There is no middle ground and no mix and matches are allowed, if we want to have bulletproof fast connect procedure. Any correction in the standard must make it clear and definite that it is either choice 1, or choice 2, but not both at the same time. Danail Kirov -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Tuesday, October 31, 2000 8:47 AM To: 'Paul E. Jones'; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: RE: fastStart element in all Q.931 messages up to and including C onnect I have not problem with your proposed addition. It seems bullet-proof to me. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, October 30, 2000 10:34 PM To: Audet, Francois [SC2:4K02:EXCH]; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: Re: fastStart element in all Q.931 messages up to and including C onnect Francois, You proposed the following textual changes (see enclosed in <NEW></NEW>): _____ The called endpoint accepts a proposed channel by returning the corresponding OpenLogicalChannel structure in a Q.931 message sent in response to Setup, up to and including Connect. <NEW>A called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect. Calling endpoints should react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.</NEW> _____ I don't have any problem inserting this text into H.323, but I do fear that people will rely on such repetitions and they may not happen. Indeed, I would state that an H.323 entity shall not expect more than one response to Fast Connect. I don't disagree with this text, because I always encourage developers to be very tolerant of "noise" on the wire-- and I consider repetitive data like this to be "noise". :-) You call these religious arguments... they might be, but we really need closure on this issue. Unlike the MGCP vs H.248 debates, the world can live with two media gateway control protocols. However, I don't want to see vendors split on implementation issues relating to H.323: that's not good for anybody at all. If we don't come to an agreement on it here and now, you know that we'll be correcting it as a customer fumes over interoperability issues later on. I'd much rather see us agree to something than to bring grief upon our customers. Can everyone live with the above textual changes? Do we need more? Is it well understood that there may be one and only one response containing fastStart? Paul ----- Original Message ----- From: Francois <mailto:audet@nortelnetworks.com> Audet To: 'Anatoli <mailto:alevine@RADVISION.COM> Levine' Cc: h323implementors(a)imtc.org <mailto:h323implementors@imtc.org> Sent: Monday, October 30, 2000 5:51 PM Subject: RE: fastStart element in all Q.931 messages up to and including C onnect > I disagree with your claim that the stack which sends > multiple Fast Start > responses (as long as they are identical) is not compliant > with the standard - > none of the citations you used claim that ONLY ONE Q.931 > message can carry Fast > Start information. I believe that the wording should be > changed to explicitly > allow Fast Start elements to be sent in every Q.931 message > up to Connect as > long as information in those messages stays the same. Correct. That was my proposal too. I didn't keep the exact wording I had. Paul Jones probably still has it. These religious arguments over "one" or "many" are getting nowhere. It seems that sending one and sending many are a fait accomplit. Not much we can do about it except tell the implementor about it.

1 0

RE: Fast Connect - Switching to H.245 procedure / UII vs. Keypad IE
by Francois Audet 31 Oct '00

31 Oct '00

Use H.245 tunnelling. Also, H.323v4 will explain how to do TCS and M/S at the same time as fastStart during call setup so that they be completed extremely rapidly. See 8.2.3 of the H.323v4 draft. If you need H.323v2 or v3, you can still use H.245 tunnelling, and initiate TCS and M/S from the called end as soon as possible (right after sending fastStart) > -----Original Message----- > From: Dan Davidson [mailto:dan.davidson@commatch.com] > Sent: Tuesday, October 31, 2000 1:09 AM > To: 'Paul E. Jones' > Cc: h323implementors > Subject: RE: Fast Connect - Switching to H.245 procedure / > UII vs. Keypad IE > > > (This mail is a fusion of two previously separated streams: > Fast Connect - Switching to H.245 procedure and UII vs. Keypad IE) > > Paul, > All this would mean that when using fast connect to > set-up a call against > and IVR (i.e. calls in which DTMF are sent immediately after > call set-up), > H.245 UII > messages shall be used for DTMF transport and the first H.245 > UII message > has to be preceded by Capability Exchange and Master Slave > Determination > procedures. > Isn't this slow ( and I'm not counting in all the TCP > connection set-up when > tunnelling is not supported)? > > Isn't there a faster, standardised, way to convey DTMF when using fast > connect ? > > Thanks, > Dan > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, October 31, 2000 7:59 AM > To: Dan Davidson; h323implementors(a)imtc.org > Subject: Re: UII vs. Keypad IE > > Dan, > > An endpoint that communicates with a SET device may certainly > do this-- and > must if they expect to get DTMF digits from a SET device. > However, two > non-SET devices should not use this method. As far as I > know, there is no > means of signaling to the other endpoint that you have the > "capability" of > using the keypad IE. That means that any non-SET device must use UII. > > That might be something worth considering as a means of > removing further > dependencies on H.245. We could very easily add such support > and signal it > within H.225.0. However, I have seen no proposals for that. > > Paul > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, October 31, 2000 7:59 AM > To: Dan Davidson; h323implementors(a)imtc.org > Subject: Re: Fast Connect - Switching to H.245 procedure > > > Dan, > > There's nothing hidden there. Essentially, this text is > re-enforcing the > idea that Fast Connect does not somehow bypass any of the > H.245 messages > (except that channels are opened). When starting H.245, you > send the H.245 > terminal capability set and the master/slave determination messages as > appropriate. > > Paul > > ----- Original Message ----- > From: "Dan Davidson" <dan.davidson(a)commatch.com> > To: <h323implementors(a)imtc.org> > Sent: Monday, October 30, 2000 2:38 PM > Subject: Fast Connect - Switching to H.245 procedure > > > > > > The H.323v2 Recommendation describes the Fast Connect procedure and > mentions > > that if necessary, a H.245 connection can be established. > > > > It also mentions: " When H.245 procedures are activated, > all mandatory > > procedures of > > H.245 that normally occur upon initiation of an H.245 > connection shall be > > completed prior > > to initiation of any additional H.245 procedures." > > > > Question: What are the H.245 mandatory procedures the recommendation > refers > > to ? > > > > Dan > > > > > -------------------------------------------------------------- > ------------ > - > > ------------------------------ > > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > > subscribe or unsubscribe from this list > > ------------------------------ > > > -------------------------------------------------------------- > ------------ > - > > > > -------------------------------------------------------------- > ------------- > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > -------------------------------------------------------------- > ------------- >

1 0

contributions APC-1961 - APC-1967 uploaded
by Euchner Martin 31 Oct '00

31 Oct '00

Dear experts, I've uploaded the contributions APC-1961 ... APC-1967 to the incoming directory of the picturetel FTP server ftp://standard.pictel.com/avc-site/Incoming/ <ftp://standard.pictel.com/avc-site/Incoming/> Once Mr. Okubo has moved them to the appropriate place you will find them at ftp://standard.pictel.com/avc-site/0011_Gen/ <ftp://standard.pictel.com/avc-site/0011_Gen/> Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Sakae OKUBO [SMTP:okubo@giti.waseda.ac.jp] Gesendet am: Samstag, 21. Oktober 2000 05:33 An: Euchner Martin; Terry L Anderson Cc: Q.12-14/16 Reflector Betreff: Re: Request for APC numbers Dear Mr. Euchner, In response to your requests, the following APC numbers have been allocated to your contributions: At 09:09 +0200 00/10/20, Euchner Martin wrote: >The following block of contributions relate to corrections of the H.235 >Version 2 white text for decision: APC-1961 >Source Title >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding Section B.4.3 APC-1962 >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding the use of the password and shared secret APC-1963 >Editor Clarification on the use of sendersID and generalID in >white Draft H.235 Version 2 APC-1964 >Editor REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND >ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS >- CORRECTED VERSION FOR DECISION >The following block of contributions relate to the new H.235 Version 3: APC-1965 >Source Title >Editor Draft H.235 Version 3 - Security and encryption for >H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 >Editor Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 >Editor Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 >Mobile Environments" Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp <mailto:okubo@giti.or.jp> *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1981 Uploaded
by Klaghofer Karl ICN EN HC SE 81 31 Oct '00

31 Oct '00

APC-1981 "Editorial comments to H.450.9 Whitedocument (COM16-117E)" has been uploaded to the pictel Incoming directory. Regards, Karl ------------------------------------ Karl Klaghofer Siemens AG Tel.: +49 89 722 31488 Fax.: +49 89 722 37629 E-Mail: karl.klaghofer(a)icn.siemens.de ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Roy, Radhika R, ALCOO 31 Oct '00

31 Oct '00

Hi, Martin: I am responding to your general question: I like to pint out that we will create "one common VLF/HLF protocol" that can be used by all applications (H.323, H.310, H.324, IMT-2000, and others) that like to support mobility related value-added services. So, I do not think that we have agreed at all to extend H.225.0 Annex G for that purpose that will ONLY be specific to H.323 mobility. If the properties of H.225.0 Annex G protocol are so good that we need to use all those for solving the mobility related VLF/HLF problems, we can still use those properties, if needed, for the "VLF/HLF protocol," but we will definitely NOT term as "H225.0 Annex G protocol." We will name it as a "new protocol" that can be used by all applications without restricting it ONLY to H.323. The conclusion is that the proposal of extending the H.225.0 Annex G for the VLF/HLF services to make it specific ONLY for H.323 is HIGHLY controversial and will create many protocols (instead of one) for the same purpose within ITU. It will be disaster for both service provider and equipment manufacturer community. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Monday, October 30, 2000 10:31 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G) Hi Jaakko, I'm not certain, whether I really understand the purpose of the EncryptionToken. If I look at Annex G v1, H.235 Clear and CryptoTokens are always present in each Annex G message; they are conveyed within AnnexGCommonInfo and thus are already part of each annex G message. Thus, I would say, that EncryptionToken is somewhat redundant and we do not need that this way. The other question I have concerns AuthenticationRejection: Why do you reverse tunnel - that is, feed back - the tunneled message in the reject? Finally a general question: Once there was a discussion that Annex G not only be used among Border elements as currently defined in the H.225 Annex Gv1 scope, but to extend its usage for mobility purposes. If this were true, then Annex G could be applied also between the GK-VLF/BE and between HLF/BE-AuF. What is the current status of that discussion? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] Gesendet am: Montag, 30. Oktober 2000 11:11 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Annex G) Mr. Fortinsky et al, I have uploaded MD-110 containing a contribution on adding new, authentication related messages to the H.225 Annex G protocol, to the URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-110_AdditionOfMe ssagesToH225AnnexG.zip . I will send the contribution also to the two meetings in Geneva, but if you send comments really quickly (tomorrow) to me, I may be able to make some changes to the contribution, before distributing it. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0