- sg16-avd - lists.packetizer.com

Re: fastStart element in all Q.931 messages up to and including C onnect
by van Schelven, Richard 02 Nov '00

02 Nov '00

Can anybody enlighten me: 1. Why would an endpoint change fastStart elements in mid stream? How would you implement that in real life. 2. Why are things so complicated? Why not have a fastStart element in a Setup and Connect only. All the other things are complicating matters and IMHO unnecessarily. Faststart is suppose to be fast, clean (simple) and crisp solution. Ries van Schelven Principal Engineer Marconi 100 Upper Georges Street Dun Laoghaire Co. Dublin Ireland > -----Original … [View More]Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Thursday, November 02, 2000 7:08 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: fastStart element in all Q.931 messages up to > and including > Connect > > > Bob, > > This opens a whole can of worms. Essentially, I can't agree > that fastStart > may be modified and re-transmitted. The calling endpoint may > have freed > resources and certainly may not be prepared to accept the > newly modified > proposals. > > Paul > > ----- Original Message ----- > From: "Bob Gilman" <rrg(a)AVAYA.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, November 01, 2000 12:03 PM > Subject: Re: fastStart element in all Q.931 messages up to > and including > Connect > > > > Francois and Paul - > > I agree with François' change to "shall react to the first > > fastStart element", but I would suggest that "ignore" be > > replaced by "may ignore" for any subsequent fastStart elements. > > (If a called endpoint changes fastStart elements in mid-stream, > > then it's the caller's choice whether it reacts or not.) > > BTW, doesn't this overlap with the redirection problem in which > > we perhaps should say that the called endpoint "shall" react to > > any subsequent [different] fastStart element? > > -Bob > > ---------------------------------------------------- > > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > > > > ----- Original Message ----- > > From: Francois Audet > > To: h323implementors > > Sent: Tuesday, October 31, 2000 1:32 PM > > Subject: RE: fastStart element in all Q.931 messages > up to and > including > > C onnect > > > > Change the should to a shall then: > > > > 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 shall > react to the > first > > fastStart element received in a response message > > to the Setup message and ignore any eventual subsequent > fastStart > > elements. > > > > If somebody manages to get it wrong after that, they > deserve to be > taken > > out of business. > > > > I completely disagree with your assertion that we must choose > either one > > or many. Currently some implementations send one, > > others send many, and we don't see interoperability problems. > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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 [View Less]

2 1

APC 2009 uploaded
by Espen Skj�ran 02 Nov '00

02 Nov '00

Hi all, APC 2009 (Use of Call Independent Signalling for Service Control) has now been uploaded to the Incoming directory on the pictel site. It proposes some minor additions to Annex K in order to mention the possible use of a call independent connection to transport the URLs. Regards, Espen Skjæran ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

v4 dependent on v2?
by Paul Long 02 Nov '00

02 Nov '00

(While reviewing H.323v4 for a tunneling thread over on the implementors reflector, I noticed a few unrelated things that concern me to varying degrees. I'll discuss them in separate emails to make it easier to follow the ensuing threads.) Annexes E and F in H.323v4 are dependent on normative behavior defined in H.323v2 (see below for examples). Besides being rather strange, is this even possible because the ITU-T only publishes a single version of a Recommendation at any one time. For example,… [View More]

2 2

Tunneling in fastStart?
by Paul Long 02 Nov '00

02 Nov '00

This sentence doesn't make sense to me. It seems to be saying that H.245 Tunneling involves the use of the fastStart component whereas H.245 Tunneling and Fast Connect are actually completely independent facilities. Is it just using the term, "tunneling," in a general sense and not in reference to "H.245 Tunneling?" Annex F.10/H.323v4: "NOTE All these messages are transmitted as tunnelled H.245 messages; i.e. the resulting bit patterns are encoded as a single OCTET STRING of the SEQUENCE in … [View More]

1 0

Re: joint meeting with modem experts
by Hutton, Charles 01 Nov '00

01 Nov '00

Glenn: AT&T Wireless is very interested in relay of FAX and modem traffic. Is there a draft of Annex P yet? Thanks - Please note new FAX number and street address as of 8-21-00 Charles (Chuck) Hutton Strategic Architecture Engineering Wireless Local Technology Group AT&T Wireless Services PO Box 97059 Redmond, WA 98073 (USPS only) 14500 NE 87th St. Redmond, WA 98052 (FEDEX/UPS) 425-702-2938 Voice * 425-702-2826 FAX charles.hutton(a)attws.com * > ---------- > From: … [View More]

1 0

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, … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]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. [View Less]

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 … [View More]> 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 > ------------------------------ > -------------------------------------------------------------- > ------------- > [View Less]

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. ----------------------------------------------------------------------… [View More]- | 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 [View Less]

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 … [View More]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 [View Less]

1 0

Contributions APC-1984, APC-1985, APC-1986 uploaded
by Michael Fortinsky 31 Oct '00

31 Oct '00

The following contributions: APC-1984 editor (M. Fortinsky) H.225.0 Annex G Version2 Draft APC-1985 VocalTec Communications Ltd H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Ltd Clarifications Related to H.225.0 Annex G Service ID's have been uploaded to: ftp://standard.pictel.com/avc-site/Incoming/ Mr Okubo: could you please move them to the 0011_Gen directory? Thank you. Michael Fortinsky -------------------------------------------------------… [View More]

1 0

AW: fastStart element in all Q.931 messages up to and including C onnect
by Klaghofer Karl ICN EN HC SE 81 31 Oct '00

31 Oct '00

Paul, The clarifying text below as proposed by Francois looks good to me. It should be added to v4 in this way. Regards, Karl -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@packetizer.com] Gesendet am: Dienstag, 31. Oktober 2000 07:34 An: Francois Audet; 'Anatoli Levine'; Paul Long Cc: h323implementors(a)imtc.org Betreff: Re: fastStart element in all Q.931 messages up to and including C onnect Francois, You proposed the following textual changes (see enclosed in … [View More]

1 0

Contributions APC-1982 and 1983 uploaded
by Horvath Ernst 31 Oct '00

31 Oct '00

Dear all, contributions APC-1982 and APC-1983 have been uploaded to the incoming directory on the PictureTel site. These are the third drafts of Recs. H.450.10 (Call Offer) and H.450.11 (Call Intrusion). Both are proposed for determination at the forthcoming SG16 meeting. Best regards, Ernst Horvath Siemens AG ======================== Tel: +43 5 1707-45897 Fax: +43 5 1707-56992 Email: ernst.horvath(a)siemens.at ======================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~… [View More]

1 0

Contribution APC-1995.zip uploaded
by John Segers 31 Oct '00

31 Oct '00

Dear all, A few minutes ago I uploaded my contribution APC-1995 to the incoming directory on the PictureTel site. Best regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~… [View More]

1 0

Re: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Jaakko Sundquist 31 Oct '00

31 Oct '00

Hi again Martin, My comments embedded & marked with [Jaakko:]. > > The other question I have concerns AuthenticationRejection: > > Why do you reverse tunnel - that is, feed back - > the tunneled > > message in the reject? > > Well, this was just a thought that maybe it would be > beneficial, if the > originating gatekeeper would receive the (presumably) > same message it has > tunneled, so that it can … [View More]make sure that the message > indeed is the one it has > sent. On the other hand, since we are talking about > communications taking > place through a route of trusted parties (also > secured with H.235 methods), > maybe this kind of integrity check is unnecessary. > What do you think? > > Meu:> If the reverse tunnel is solely for security > purposes, then I do not consider this useful. As you said, > the entire authentication message including the tunneled > message is integrity protected on a hop-by-hop basis. Due to > the principle of chained trust in the security architecture, > the MT can be certain that the authentication message has not > been tampered in transit. As a conclusion, the reverse tunnel > does not make sense from a security point of view. [Jaakko:] I guess you're right. I'll take this away also. > > I thought, that the reverse tunnel were useful > perhaps for matching the confirmation with the request > message. But then, some simpler means than conveying the > entire message should be sufficient. [Jaakko:] I also thought about this, but came to the same conclusion that it should be the GK's responsibility to construct the GCF or RCF (or whatever) messages to be sent to the MT based on the information received in the AuthenticationConfirmation. > What about the following scenario: > Several MTs "attach" to the same GK. All these MTs > are subscribed to the same AuF. Thus, the GK has several > outstanding AuthenticationRequests issued for each MT. How > does the GK associate the related AuthenticationConfirmation then? [Jaakko:] The purpose of the destinationInfo field is to indicate to which User's authentication the message is related. Now, thinking of this, I think the field shouldn't be optional, so I'll make a correction here also. > > 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? > > I guess this issue hasn't been throughly discussed > yet. My personal opinion > is that we should extend the usability of the H.225 > Annex G protocol also to > other functional entities besides the BE. On the > other hand, I would be > quite happy also, if we would limit the first version > of H.323 Annex H by > not handling all the interfaces in the architecture > diagram and concentrate > on the VLF - HLF -interface (with or without BEs) > instead. The reason for > the latter argument is that I would assume that > implementors might be quite > happy with co-located functional entities so that > they would have a > GK/VLF/BE and HLF/AuF/BE elements, thus necessitating > only the mentioned > VLF/BE - HLF/BE network interface. > > Meu>: this could simplify things a lot! I'll include the proposition for only defining this one interface in the first version of the annex in my contribution "Changes to H.323 Annex H". Thanks again for the mails, this discussion has rendered the contribution much better already. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

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

31 Oct '00

(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 … [View More]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 > ------------------------------ > -------------------------------------------------------------------------- - > [View Less]

1 0

AW: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Euchner Martin 31 Oct '00

31 Oct '00

Jaakko, Thanks for your answers. Please see my comments marked with meu:> below. 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 &… [View More]lt;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(a)nokia.com [SMTP:jaakko.sundquist@nokia.com] Gesendet am: Dienstag, 31. Oktober 2000 09:12 An: Martin.Euchner(a)icn.siemens.de; ITU-SG16(a)mailbag.cps.intel.com Betreff: RE: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G) Hi Martin, See my comments embedded. > 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. You're quite right, the encryptionToken certainly seems unnecessary, thus I'll take it away from the contribution. Meu> ok. Thanks. > > The other question I have concerns AuthenticationRejection: > Why do you reverse tunnel - that is, feed back - the tunneled > message in the reject? Well, this was just a thought that maybe it would be beneficial, if the originating gatekeeper would receive the (presumably) same message it has tunneled, so that it can make sure that the message indeed is the one it has sent. On the other hand, since we are talking about communications taking place through a route of trusted parties (also secured with H.235 methods), maybe this kind of integrity check is unnecessary. What do you think? Meu:> If the reverse tunnel is solely for security purposes, then I do not consider this useful. As you said, the entire authentication message including the tunneled message is integrity protected on a hop-by-hop basis. Due to the principle of chained trust in the security architecture, the MT can be certain that the authentication message has not been tampered in transit. As a conclusion, the reverse tunnel does not make sense from a security point of view. I thought, that the reverse tunnel were useful perhaps for matching the confirmation with the request message. But then, some simpler means than conveying the entire message should be sufficient. What about the following scenario: Several MTs "attach" to the same GK. All these MTs are subscribed to the same AuF. Thus, the GK has several outstanding AuthenticationRequests issued for each MT. How does the GK associate the related AuthenticationConfirmation then? What do you think? > 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? I guess this issue hasn't been throughly discussed yet. My personal opinion is that we should extend the usability of the H.225 Annex G protocol also to other functional entities besides the BE. On the other hand, I would be quite happy also, if we would limit the first version of H.323 Annex H by not handling all the interfaces in the architecture diagram and concentrate on the VLF - HLF -interface (with or without BEs) instead. The reason for the latter argument is that I would assume that implementors might be quite happy with co-located functional entities so that they would have a GK/VLF/BE and HLF/AuF/BE elements, thus necessitating only the mentioned VLF/BE - HLF/BE network interface. Meu>: this could simplify things a lot! Thanks for the mail, it was very useful. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

Re: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Jaakko Sundquist 31 Oct '00

31 Oct '00

Hi Martin, See my comments embedded. > 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. You're quite right, the … [View More]

1 0

Re: Request for APC number
by Sakae OKUBO 30 Oct '00

30 Oct '00

Dear Mr. Jones, Ms. Levin, Mr. Bowen, In response to your request, APC numbers have been allocated to your contributions as attached. This would be an almost final list of contributions to the 9-10 November Rapporteur meeting. 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 … [View More]3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents of the Q.12-14/16 Geneva meeting (9-10 November 2000) APC-1950 SG11 (Q.BIC/11) Liaison To SG 12, SG 13 And SG 16 Asking For Guidance On Quality Of Services to be Supported with the BICC Protocol APC-1951 Study Group 11 BICC Special Rapporteurs Liaison to SG 16 proposing some additional clarifications in the H.323 Implementers Guide for H.246 Annex C. APC-1952 SG 11 Joint Special Rapporteurs for BICC Support of directionality in "H.248 Annex K - Announcement Package" APC-1953 Accord Networks Support bi directional channels in annex C fast start APC-1954 Lucent Technologies, NTT DoCoMo H.324 Annex C multimedia call package for H.248 APC-1955 NTT DoCoMo, NEC Identification of references to IETF Documents in H.225.0 version 4 (per Recommendation A.5) APC-1956 Oki Electric Adding ServiceControl fields to LCF/LRJ APC-1957 Editor (P Jones) H.323 Implementor's Guide APC-1958 Editor (P Jones) H.323 v4 APC-1959 Editor (O Levin) H.323 Annex O Draft APC-1960 Lucent Technologies Proposal to create an SDL representation of H.248 APC-1961 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding Section B.4.3 APC-1962 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the password and shared secret APC-1963 Editor (M Euchner) Clarification on the use of sendersID and generalID in white Draft H.235 Version 2 APC-1964 Editor (M Euchner) 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 APC-1965 Editor (M Euchner) Draft H.235 Version 3 - Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 Editor (M Euchner) Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 Editor (M Euchner) Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 Mobile Environments" APC-1968 Editor (T Anderson) Draft H323 Annex R APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 APC-1978 AT&T Mobility Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1979 AT&T Application Layer QOS Signalling Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1980 AT&T Common Value Added Intelligent Backend Services (BES) Protocols for all Applications APC-1981 Editor (K Klaghofer) Editorial comments to H.450.9 White document (COM16-117E) APC-1982 Editor (K Klaghofer) H.450.10 Call Offer Supplementary Service for H.323 APC-1983 Editor (K Klaghofer) H.450.11 Call Intrusion Supplementary Service for H.323 APC-1984 Editor (M Fortinsky) H.225.0 Annex G version 2 APC-1985 VocalTec Communications H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Clarifications Related to H.225.0 Annex G Service ID's APC-1987 Editor (F Audet) H.323 Annex M.1 - QSIG tunnelling APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 APC-1990 Comverse Network Systems H.225.0 Annex G v2: support for Service Zone APC-1991 Comverse Network Systems H.225.0 v4: Enhancing SupportedProtocols to indicate video APC-1992 Siemens {to be advised} APC-1993 Siemens {to be advised} APC-1994 Siemens {to be advised} APC-1995 Lucent Technologies Issues for H.248 implementors' guide APC-1996 Nortel Networks Proposed corrections to H.323v4 Annex D on T.38 fax switchover APC-1997 Editor (C Groves) Draft H.248 Implementors' Guide APC-1998 Editor (C Groves) Draft H.248 Annex K - Generic Announcement Package APC-1999 Editor (C Groves) Draft H.248 Annex L - Error Code and Service Change Reason Description APC-2000 Ericsson H.248 Annex x - Load Control Package APC-2001 Ericsson Direction in H.248 annex K APC-2002 Ericsson Signal on Root for H248v2 APC-2003 France Telecom Mobility management protocol in H.323 Annex H APC-2004 Editor (M Buckley) Latest Draft of Annex N of H.323 APC-2005 Lucent Technologies Transport QoS Parameters and Traffic Descriptor for QoS Characterisation in H.323 systems APC-2006 Editor (M Buckley) Latest draft of TIPHON DTS05003 "End to End Quality of Service Control and Signalling in TIPHON Systems" APC-2007 Editor (A Heidermark) Editorial changes to Annex H to H.248 APC-2008 Editor (A Heidermark) Editorial changes to Annex I to H.248 APC-2009 LM Ericsson Use of Call Independent Signalling for Service Control APC-2010 Nortel Networks Use of inband tones in H.323 using special RTP payload types APC-2011 Editor (J Sundquist) H.323 Annex H Draft APC-2012 Nokia New messages to the H.225 Annex G protocol APC-2013 Nokia Changes to the H.323 Annex H APC-2014 Korea Telecom Comment to H.323 Annex K APC-2015 Korea Telecom A Procedure for Multimedia Mail Service APC-2016 NTT DoCoMo Support of HTTP in H.324 APC-2017 Nokia Comparison of 3GPP All IP and H.323 Annex H architectures APC-2018 UCLA, Samsung Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-2019 UCLA, Samsung Proposals for H.323 Annex I APC-2020 France Telecom Support of a direction indication in the generic announcement package APC-2021 France Telecom Proposed package for data transmission over analog lines APC-2022 Editor (D Wolfstein) H.323 Annex P Draft (modem relay over H.323) APC-2023 Cisco Number Portability Release Cause Code APC-2024 Cisco TRIP Contribution for Annex O/H.323 APC-2025 RADVision Remarks on the scope of H.323 Annex L APC-2026 Editor (R Bowen) Draft H.225.0 v4 ---------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

APC- Number Request
by Louis Fourie 30 Oct '00

30 Oct '00

Mr. Okubo, Please allocate an APC-number for me for the following contribution: "Number Portability Release Cause Code" - as a Cisco contribution Thanks in advance. - Louis Fourie Cisco Systems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0