- sg16-avd - lists.packetizer.com

Agenda for Monterey meeting
by Matthew Dragiff 21 Jan '99

21 Jan '99

Has an agenda been published yet? Can anyone point me to it? Thanks.

2 1

cc:Mail Link to SMTP Undeliverable Message
by admin0 21 Jan '99

21 Jan '99

Message is undeliverable. Reason: A platform specific error occurred while writing to a file. Likely disk full. Original text follows: --------------------- Received: from senda.ari.es by internet.amperdatos.es (ccMail Link to SMTP R6.01.01) ; Thu, 21 Jan 99 17:48:14 +0100 Return-Path: <ITU-SG16(a)mailbag.cps.intel.com> Received: from chico.rediris.es (chico.rediris.es [130.206.1.3]) by senda.ari.es (8.9.1/8.9.1) with ESMTP id RAA17893; Thu, 21 Jan 1999 17:45:47 +0100 Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <13.00001FDE(a)chico.rediris.es>; Thu, 21 Jan 1999 17:45:29 +0100 Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 44754 for ITU-SG16(a)MAILBAG.INTEL.COM; Thu, 21 Jan 1999 08:47:17 -0800 Received: from pluto.nko.com (faxjetsmtp.faxjet.com [206.125.250.242] (may be forged)) by mailbag.cps.intel.com (8.8.6/8.8.5) with ESMTP id IAA02479 for <itu-sg16(a)mailbag.intel.com>; Thu, 21 Jan 1999 08:37:15 -0800 (PST) Received: from apollo.nko.com ([206.125.248.124]) by pluto.nko.com (Post.Office MTA v3.5 release 215 ID# 0-54139U100L2S100V35) with SMTP id com for <itu-sg16(a)mailbag.intel.com>; Thu, 21 Jan 1999 11:41:28 -0500 Received: by apollo.nko.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256700.005C21B7 ; Thu, 21 Jan 1999 11:46:19 -0500 X-Lotus-FromDomain: FAXJET Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <85256700.005C21A5.00(a)apollo.nko.com> Date: Thu, 21 Jan 1999 11:37:29 -0500 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> From: Matthew Dragiff <mdragiff(a)NKO.COM> Subject: Agenda for Monterey meeting To: ITU-SG16(a)mailbag.cps.intel.com Has an agenda been published yet? Can anyone point me to it? Thanks.

1 0

Re: Relationship of H.323 and H.245 versions
by Pete Cordell 20 Jan '99

20 Jan '99

Dave, Comments interleaved... > >Pete, > >I understand what you're trying to do, but I'm a little concerned >about allowing a v2 entity to support any version of H.245, >including unspecified future versions which may or may not be >compatible with what we have now. As an ITU requirement any future H.245 version must be backward compatible with an earlier one so this shouldn't (in theory) be an issue. > >So let me propose the following paragraph as replacement text for >the offending portion of the H.323 Version 2 Summary section (which >begins in the same way). One reason for suggesting new text is that I wanted a fairly definitive statement on this issue and the summary doesn't seem the right place for such normative text (i.e. it's a summary and everything it says should be in the main body of the document and so doesn't have any normative value by itself). However, if the text you describe were copied to a normative part of the document, subject to changing 'other versions' to 'more recent versions' (as I have attempted to indicate below) I would be happy. (Also I would like to add a note that the version of H.245 that they end up connected to may change as a call evolves, as it seems churlish not to mention a particular gotcha if we know about it. I've attempt to add text for this below.) > >"Products claiming compliance with Version 2 of H.323 shall comply >with all of the mandatory requirements of this document, H.323 (1998), >which references H.225.0 (1998) and H.245 (1998). The protocol >identifiers used in messages defined in H.225.0 (1998) and H.245 >(1998) are specified in those recommendations. An H.323 Version 2 >compliant product may also be compliant with (other)->(more recent) versions >of these >recommendations, but should not send messages or invoke procedures >defined in a newer version of a recommendation than a peer has identified itself as supporting. () ->(Implementations must also be aware that, due to the procedures for 'Third party initiated pause and re-routing,' they may be connected to different versions of H.245 at >different times during the life of a call.)" > >Regards, > >Dave Walker >Mitel Corporation >Ontario, CANADA Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

2 1

Re: Relationship of H.323 and H.245 versions
by Pete Cordell 20 Jan '99

20 Jan '99

Gary, Chris and others, To try an clear this issue up I propose that the text below should be added to the implementors' guide and be rolled into H.323 V3. Let me know what you think (No comment will probably mean OK by me as per normal, but will probably have to put a contribution into next meeting anyway.) Proposed text: In H.323 version 2 there is conflicting advice on which versions of H.245 should be used with versions H.323. The summary states that H.323 version 2 should use H.225 version 2 and H.245 version 3. However, in the Normative References section it states that implementors are "...encouraged to investigate the possibility of applying the most recent edition of the Recommendations...". To clarify this, the following section is published in the implementors' guide as a clarification to H.323 version 2 and a similar paragraph will be added to H.323 Version 3. The Relationship of H.323 versions to H.225.0 and H.245 versions Entities claiming compliance to H.323 Version 2 shall implement all mandatory features in this recommendation and in H.225.0 version 2. An H.225.0 version 2 implementation is identified by the protocolIdentifier in the messages being set to {itu-t (0) recommendation (0) h (8) 2250 version (0) 2}. H.323 version 2 compliant entities shall implement H.245 version 3 or later. An H.245 version 3 implementation is identified by the protocolIdentifier in the terminalCapabilitySet message being set to {itu-t (0) recommendation (0) h (8) 245 version (0) 3}. Implementations must also be aware that, due to the procedures for 'Third party initiated pause and re-routing,' they may be connected to different versions of H.245 at different times during the life of the call. Therefore, under no circumstances shall an entity infer the version of the H.245 implementation from the protocolIdentifier carried in H.225.0 messages. And as a word version to help editors! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Gary A. Thom[SMTP:gthom@delta-info.com] >Sent: 14 January 1999 19:02 >To: Pete Cordell >Subject: Re: Relationship of H.323 and H.245 versions > >Pete, > >This is a very good question, and one which may need to be answered by bigger >minds than mine. > >I do not have a definitive answer, but my opinion is: > >In order to claim compliance with H.323 V2, an entity shall implement at >lease H.225.0 V2 and >H.245 V3. This would allow an advanced H.323V2 terminal to incorporate H.245 >V4. > >However, as part of the H.225.0 and H.245 message exchange >(protocolIdentifier parameter), each >entity will be aware of the version of the entity which it is communicating >with. > >The receiver, "shall not malfunction or be adversely affected by receiving >H.245 messages it does >not recognize". Does this include messages from future versions??? Or does >the transmitter have to >know that it is talking to a version X entity, so it cant send any messages >from versions greater >than X??? > >Gary > >------------------------------------------------------ >Name : Gary A. Thom >Company: Delta Information Systems, Inc. >Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA >Phone : +1-215-657-5270 Fax : +1-215-657-5273 >E-mail : gthom(a)delta-info.com >------------------------------------------------------ > begin 600 H323-Versions.doc MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M````)0``````````$ ``)P````$```#^____`````"0```#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________LI<$`60`)" ```!*_````````$ ``````! `` M$PH```X`8FIB:O-7\U<````````````````````````)!!8`'A8``)$]`0"1 M/0$`$P8```````````````````````````````````````#__P\````````` M``#__P\```````````#__P\``````````````````````%T``````)H````` M````F@```)H`````````F@````````":`````````)H`````````F@```!0` M`````````````*X`````````K@````````"N`````````*X`````````K@`` M``P```"Z````# ```*X`````````B0(``+8```#2`````````-(````````` MT@````````#2`````````-(`````````T@````````#2`````````-(````` M````3@(```(```!0`@```````% "````````4 (```````!0`@```````% " M````````4 (``"0````_`P``] $``#,%``!B````= (``!4````````````` M````````````F@````````#2``````````````````````````````#2```` M`````-(`````````T@````````#2`````````'0"````````7@$```````": M`````````)H`````````T@```````````````````-(`````````T@`````` M``!>`0```````%X!````````7@$```````#2````1@```)H`````````T@`` M``````":`````````-(`````````3@(````````````````````````````` MK@````````"N`````````)H`````````F@````````":`````````)H````` M````T@````````!.`@```````%X!``#P````7@$``````````````````$X" M````````F@````````":```````````````````````````````````````` M````````````````````````````````````````````3@(```````#2```` M`````,8````,````8**(^7M$O@&N`````````*X`````````& $``$8```!. M`@`````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````26X@2"XS,C,@=F5R<VEO;B R('1H97)E(&ES(&-O;F9L:6-T:6YG M(&%D=FEC92!O;B!W:&EC:"!V97)S:6]N<R!O9B!(+C(T-2!S:&]U;&0@8F4@ M=7-E9"!W:71H('9E<G-I;VYS($@N,S(S+B @5&AE('-U;6UA<GD@<W1A=&5S M('1H870@2"XS,C,@=F5R<VEO;B R('-H;W5L9"!U<V4@2"XR,C4@=F5R<VEO M;B R(&%N9"!(+C(T-2!V97)S:6]N(#,N("!(;W=E=F5R+"!I;B!T:&4@3F]R M;6%T:79E(%)E9F5R96YC97,@<V5C=&EO;B!I="!S=&%T97,@=&AA="!I;7!L M96UE;G1O<G,@87)E(),N+BYE;F-O=7)A9V5D('1O(&EN=F5S=&EG871E('1H M92!P;W-S:6)I;&ET>2!O9B!A<'!L>6EN9R!T:&4@;6]S="!R96-E;G0@961I M=&EO;B!O9B!T:&4@4F5C;VUM96YD871I;VYS+BXNE"X@(%1O(&-L87)I9GD@ M=&AI<RP@=&AE(&9O;&QO=VEN9R!S96-T:6]N(&ES('!U8FQI<VAE9"!I;B!T M:&4@:6UP;&5M96YT;W)SDB!G=6ED92!A<R!A(&-L87)I9FEC871I;VX@=&\@ M2"XS,C,@=F5R<VEO;B R(&%N9"!A('-I;6EL87(@<&%R86=R87!H('=I;&P@ M8F4@861D960@=&\@2"XS,C,@5F5R<VEO;B S+@U4:&4@4F5L871I;VYS:&EP M(&]F($@N,S(S('9E<G-I;VYS('1O($@N,C(U+C @86YD($@N,C0U('9E<G-I M;VYS#45N=&ET:65S(&-L86EM:6YG(&-O;7!L:6%N8V4@=&\@2"XS,C,@5F5R M<VEO;B R('-H86QL(&EM<&QE;65N="!A;&P@;6%N9&%T;W)Y(&9E871U<F5S M(&EN('1H:7,@<F5C;VUM96YD871I;VX@86YD(&EN($@N,C(U+C @=F5R<VEO M;B R+B @06X@2"XR,C4N,"!V97)S:6]N(#(@:6UP;&5M96YT871I;VX@:7,@ M:61E;G1I9FEE9"!B>2!T:&4@<')O=&]C;VQ)9&5N=&EF:65R(&EN('1H92!M M97-S86=E<R!B96EN9R!S970@=&\@>VET=2UT("@P*2!R96-O;6UE;F1A=&EO M;B H,"D@:" H."D@,C(U,"!V97)S:6]N("@P*2 R?2X@($@N,S(S('9E<G-I M;VX@,B!C;VUP;&EA;G0@96YT:71I97,@<VAA;&P@:6UP;&5M96YT($@N,C0U M('9E<G-I;VX@,R!O<B!L871E<BX@($%N($@N,C0U('9E<G-I;VX@,R!I;7!L M96UE;G1A=&EO;B!I<R!I9&5N=&EF:65D(&)Y('1H92!P<F]T;V-O;$ED96YT M:69I97(@:6X@=&AE('1E<FUI;F%L0V%P86)I;&ET>5-E="!M97-S86=E(&)E M:6YG('-E="!T;R![:71U+70@*# I(')E8V]M;65N9&%T:6]N("@P*2!H("@X M*2 R-#4@=F5R<VEO;B H,"D@,WTN("!);7!L96UE;G1A=&EO;G,@;75S="!A M;'-O(&)E(&%W87)E('1H870L(&1U92!T;R!T:&4@<')O8V5D=7)E<R!F;W(@ MD51H:7)D('!A<G1Y(&EN:71I871E9"!P875S92!A;F0@<F4M<F]U=&EN9RR2 M('1H97D@;6%Y(&)E(&-O;FYE8W1E9"!T;R!D:69F97)E;G0@=F5R<VEO;G,@ M;V8@2"XR-#4@870@9&EF9F5R96YT('1I;65S(&1U<FEN9R!T:&4@;&EF92!O M9B!T:&4@8V%L;"X@(%1H97)E9F]R92P@=6YD97(@;F\@8VER8W5M<W1A;F-E M<R!S:&%L;"!A;B!E;G1I='D@:6YF97(@=&AE('9E<G-I;VX@;V8@=&AE($@N M,C0U(&EM<&QE;65N=&%T:6]N(&9R;VT@=&AE('!R;W1O8V]L261E;G1I9FEE M<B!C87)R:65D(&EN($@N,C(U+C @;65S<V%G97,N#0`````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````0``#,&``!T!@``-@<``$@'```E" ``-P@` M`#\(``!4" ``XPD``/4)```3"@```/L`^0#Y`/D`^0`````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````S4(@0<U"(%#2A@```L`! ``,P8``'0& M```3"@``_0```````````````/<```````````````#W```````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````%```.A- "#X0< M`@`!`````P`$```S!@``= 8``!,*```````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````#' `?L- O(+#@/2&P" <BL @'(Y"@ M!220H 4EL `````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````2``\` M"@`!`%L`#P`"`````````"P``$#Q_P(`+ ````8`3@!O`'(`;0!A`&P````* M````$Z0\`!2D/ `$`&U("00````````````````````````\`$% \O^A`#P` M```6`$0`90!F`&$`=0!L`'0`( !0`&$`<@!A`&<`<@!A`' `: `@`$8`;P!N M`'0``````````````````````!,&```$```6`````/____\`! ``$PH```@` M````! ``$PH```D`````! ``$PH```H`````````-@,``$@#```E! ``-P0` M`#\$``!4! ``<P4``'<%``#C!0``]04``!4&```'`!P`!P`<``<`' `'``0` M!P`<``<``````( !``""`0``9P,``)H#``".! ``F00``*,$``!Z!0``$08` M`!(&```5!@``!P`:``<`&@`'`!H`!P`$``<`&@`'`/__! ````P`4 !E`'0` M90`@`$,`;P!R`&0`90!L`&P`'@!#`#H`7 !0`&4`= !E`%P`5 !E`'@`= !< M`$@`,P`R`#,`+0!6`&4`<@!S`&D`;P!N`',`+@!D`&\`8P`,`% `90!T`&4` M( !#`&\`<@!D`&4`; !L`#L`7 !<`$$`5 !,`$$`3@!4`$D`0P!<`$@`;P!M M`&4`7 !#`$\`4@!$`$4`3 !0`$H`7 !0`$4`5 !%`%P`5 !%`%@`5 !<`%8` M20!/`$P`10!4`%P`2 `S`#(`,P`M`%8`90!R`',`:0!O`&X`<P`N`&0`;P!C M`/] `8 !`'<%``!W!0``))+0`+P!O %W!0```````$H%`````````A ````` M````$P8``$ ```@`0 ```P```$<6D $```("!@,%! 4"`P2'`@`````````` M````````GP````````!4`&D`;0!E`',`( !.`&4`=P`@`%(`;P!M`&$`;@`` M`#46D $"``4%`0(!!P8"!0<`````````$ ``````````````@ ````!3`'D` M;0!B`&\`; ```#,FD $```(+!@0"`@("`@2'`@``````````````````GP`` M``````!!`'(`:0!A`&P````B``0`<0B(& ``T (``&@!`````&BB,69SHS%F M``````@`'P```. ````"!0```0`"````! `#$ H```````````````$``0`` M``$`````````-"4````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````I0; ![0`M " `#(P```````````````````F!@`````` M```````````````````````````````````````````````````````````` M``````````````````````(``````/__$@`````````$`$D`;@`@`$@````` M````# !0`&4`= !E`" `0P!O`'(`9 !E`&P`; `,`% `90!T`&4`( !#`&\` M<@!D`&4`; !L```````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````````````````````_O\` M``0``@```````````````````````0```."%G_+Y3V@0JY$(`"LGL]DP```` M: $``! ````!````B ````(```"0`````P```* ````$````K ````4```#$ M````!P```- ````(````Y ````D```#\````$@````@!```*````) $```P` M```P`0``#0```#P!```.````2 $```\```!0`0``$ ```%@!```3````8 $` M``(```#D! ``'@````4```!);B!(``!F`!X````!`````&X@2!X````-```` M4&5T92!#;W)D96QL``!O`!X````!`````&5T91X````+````3F]R;6%L+F1O M= !L'@````T```!0971E($-O<F1E;&P``&\`'@````(````X`'1E'@```!,` M``!-:6-R;W-O9G0@5V]R9" X+C ``$ `````>J54! ```$ `````6.K86$2^ M`4 `````^E_I>T2^`0,````!`````P```. ````#`````@4```,````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````````````/[_ M```$``(```````````````````````(````"U<W5G"X;$).7" `K+/FN1 `` M``75S=6<+AL0DY<(`"LL^:XT`0``\ ````P````!````: ````\```!P```` M!0```( ````&````B ```!$```"0````%P```)@````+````H ```! ```"H M````$P```+ ````6````N ````T```# ````# ```-$````"````Y 0``!X` M```(````0E0@3&%B<P`#````"@````,````"`````P```"8&```#````:A ( M``L`````````"P`````````+``````````L`````````'A ```$````%```` M26X@2 `,$ ```@```!X````&````5&ET;&4``P````$`````F ````,````` M````( ````$````V`````@```#X````!`````@````H```!?4$E$7T=5240` M`@```.0$``!!````3@```'L`.0`Q`#4`0P`S`$,`-0`W`"T`0@`P`#0`0@`M M`#$`,0!$`#(`+0`X`$,`10`X`"T`,@`P`#0`0P`T`$8`- !&`#4`, `R`# ` M?0`````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````! M`````@````,````$````!0````8````'````" ````D````*````"P```/[_ M__\-````#@````\````0````$0```!(````3````_O___Q4````6````%P`` M`!@````9````&@```!L```#^____'0```!X````?````( ```"$````B```` M(P```/[____]____)@```/[____^_____O__________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________U(`;P!O`'0`( !%`&X`= !R`'D````````````` M```````````````````````````````````````````````6``4!________ M__\#````!@D"``````# ````````1@`````&@>.#>T2^`7 -R_I[1+X!* `` M`( `````````,0!4`&$`8@!L`&4````````````````````````````````` M``````````````````````````````````````X``@#_______________\` M```````````````````````````````````````````````,`````! ````` M``!7`&\`<@!D`$0`;P!C`'4`;0!E`&X`= `````````````````````````` M````````````````````````````&@`"`04```#__________P`````````` M```````````````````````````````````````````>%@````````4`4P!U M`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````````````````` M```````````````````H``(!`@````0```#_____```````````````````` M````````````````````````````% `````0````````!0!$`&\`8P!U`&T` M90!N`'0`4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````` M`````````#@``@'_______________\````````````````````````````` M```````````````````<`````! ````````!`$,`;P!M`' `3P!B`&H````` M```````````````````````````````````````````````````````````` M$@`"`0$````&````_____P`````````````````````````````````````` M``````````````!J`````````$\`8@!J`&4`8P!T`% `;P!O`&P````````` M```````````````````````````````````````````````````6``$`____ M____________``````````````````````````!P#<OZ>T2^`7 -R_I[1+X! M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````#_____________ M__\````````````````````````````````````````````````````````` M```````!````_O______________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________P$`_O\#"@``_____P8)`@``````P `` M`````$88````36EC<F]S;V9T(%=O<F0@1&]C=6UE;G0`"@```$U35V]R9$1O M8P`0````5V]R9"Y$;V-U;65N="XX`/0YLG$````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` G```````````````````````````````````````````````````` ` end

2 1

Re: Notice of the Monterey meeting
by Sakae OKUBO 20 Jan '99

20 Jan '99

Dear Henri Maenpaa, > I'm trying to prepare a brief proposal to one of the H.225's annex > concerning 'voice coding'. > > It will be just a brief text about transferring GSM in H.323, just like > there already is e.g. G.723 represented. APC-1491 has been allocated to your contribution. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

H.323 Security Issues
by Avikal Jain 18 Jan '99

18 Jan '99

Hi all, I am studying the security issues related to H.323 proxy. I need to find out more about the security issues posed by a H.323 proxy. I believe that the H.323 proxies such as those developed by TIS, Checkpoint and Cisco, although permitting H.323 traffic, are not considered very secure. What are the possible security hazards one must be aware of? Thanks. Avikal Jain Center for Development of Advanced Computing, Pune 411007, India. e-mail: avikal(a)usa.net

1 0

Re: Ambiguity in H.225.0 Appendix D
by Jim Toga 18 Jan '99

18 Jan '99

Chris, The problem is that it is a _client_ issue as much as a GK issue. The (enterprise) site administrator, wants to be assured that no rougue client will get on the network and simple start conferencing... If he has 'compliant' stacks than he can be assured that GK policy will be followed.... Regards, jimt. At 05:59 PM 1/18/99 -0000, you wrote: >Jim, > >Surely this could be left as a configuration option for the administrator. >If he doesn't want the assurance you describe, why shouldn't he be allowed >to configure it out of suitably-written gatekeepers? I would expect it to >be an unusual thing to want to do, bearing in mind your comments, but is it >the place of the standard to deny such possibilities? > >Chris > >> -----Original Message----- >> From: Jim Toga [mailto:jim.toga@INTEL.COM] >> Sent: 15 January 1999 1:47 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Ambiguity in H.225.0 Appendix D >> >> >> There is a point behind having a GK respond to all GRQ messages. >> >> The administrator must be able to be assured that >> unauthorized endpoints >> (with compliant stacks) do not conference. H.323 stipulates >> that _if_ GKs >> are present, then endpoints must use them.... so if the GK >> are present and >> none of them will allow a particular endpoint to register - >> then it is not >> supposed to make/receives H.323 calls. >> >> The endpoint on the other hand, must be able to reasonably detect the >> difference between the complete absence of GKs and the >> absence of 'their' >> GK (especially if some specific control/policy is in place). >> >> If the GK receives a GRQ, it must respond with a (directed) >> GCF or GRJ. >> >> jimt. >> >> >> At 10:55 AM 1/13/99 -0800, you wrote: >> >Hi, >> > >> >This is wrt the second problem in the attached mail. >> >Chris Purvis mentioned that GK needs to know whether >> >a GRQ or LRQ is received via multicast or unicast so that >> >the response could be different. >> > >> >Actually, H.323 V2 specifies different multicast and unicast >> >responses only in case of LRQ. In case of GRQ, spec specifically >> >mentions that even in multicast case a response shall be >> >given (Section 7.2.1 para three which _only_ talks about >> >multicast GRQs). >> > >> >I believe spec should not mandate a GK to respond to >> >a multicast GRQ. It should be left to the implementor whether >> >a response should be sent out to a multicast GRQ or not. >> >The GK may have some additional information like redirecting >> >the endpoint to a different GK with altGKInfo etc, otherwise it >> >is just plain waste of bandwidth to mandate GK's to respond to >> >multicast GRQ's. The endpoints would time out if they >> >haven't received a single GCF. >> > >> >May be the following line in para 3 of section 7.2.1: >> > >> >"If a Gatekeeper does not want the endpoint to register to it, >> >it shall return Gatekeeper Reject (GRJ)" >> > >> >should be changed to something like: >> > >> >"On receiving a multicasted GRQ, if a Gatekeeper does not want >> >the endpoint to register to it, it MAY return Gatekeeper >> >Reject (GRJ)" >> > >> >Comments? >> > >> >Regards, >> >-Kishore. >> > >> > >> >> -----Original Message----- >> >> From: Mailing list for parties associated with ITU-T Study Group 16 >> >> [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis >> >> Sent: Thursday, January 07, 1999 9:33 PM >> >> To: ITU-SG16(a)mailbag.cps.intel.com >> >> Subject: Ambiguity in H.225.0 Appendix D >> >> >> >> >> >> We have had an ambiguity show up during interoperability >> >> testing, which >> >> I would like clarified by means of the implementer's guide >> and future >> >> versions of the standard. Any objections, please shout in >> the usual >> >> way! >> >> >> >> The problem comes in 19.1.1.1 where UDP port numbers are >> defined. The >> >> standard currently (I'm looking at version 2) says: >> >> Gatekeeper UDP Discovery Port 1718 >> >> Gatekeeper UDP Registration and Status Port 1719 >> >> >> >> There are two problems with this. The first is that it >> >> implies that the >> >> LRQ message (which is nothing to do with discovery) always >> needs to be >> >> sent to port 1719, which is a problem for multicast LRQs, >> because only >> >> one IP address and port number pair has been registered with >> >> the IETF - >> >> 224.0.1.41:1718. >> >> >> >> The second problem is, if anything, more subtle... The >> standard also >> >> seems to imply by the above that GRQ, which is a discovery message, >> >> should always be sent to port 1718, whether it is sent to the >> >> multicast >> >> discovery port or not. >> >> The reason this is a problem is that gatekeepers need to >> know whether >> >> these messages (GRQ and LRQ) have arrived by multicast or >> by unicast, >> >> because the failure response is different in the two cases >> >> (no response >> >> to a multicast xRQ, but xRJ response to a unicast xRQ). The only >> >> indication that most IP stacks give as to how a message >> has arrived is >> >> by a port number, however, so if all GRQs appear to port >> 1718 (and all >> >> LRQs to port 1719), there is no way for the gatekeeper to >> tell whether >> >> the message arrived by unicast or multicast. >> >> >> >> Common (but not universal - at least in products under >> development!) >> >> usage, driven by these practical considerations, seems to >> be that the >> >> most common implementations send both sorts of multicast >> addresses to >> >> the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ >> >> messages to port 1719 (unless there is some private arrangement >> >> specifying other special usage). >> >> >> >> My suggestion is that this common usage is standardised, >> initially via >> >> the implementer's guide, and then when appropriate in future >> >> versions of >> >> H.225.0. >> >> >> >> Regards, >> >> Chris >> >> >> > >> +1-503-264-8816(voice) Intel - Hillsboro, OR >> mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int >> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >> > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: Ambiguity in H.225.0 Appendix D
by Chris Purvis 18 Jan '99

18 Jan '99

Jim, Surely this could be left as a configuration option for the administrator. If he doesn't want the assurance you describe, why shouldn't he be allowed to configure it out of suitably-written gatekeepers? I would expect it to be an unusual thing to want to do, bearing in mind your comments, but is it the place of the standard to deny such possibilities? Chris > -----Original Message----- > From: Jim Toga [mailto:jim.toga@INTEL.COM] > Sent: 15 January 1999 1:47 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Ambiguity in H.225.0 Appendix D > > > There is a point behind having a GK respond to all GRQ messages. > > The administrator must be able to be assured that > unauthorized endpoints > (with compliant stacks) do not conference. H.323 stipulates > that _if_ GKs > are present, then endpoints must use them.... so if the GK > are present and > none of them will allow a particular endpoint to register - > then it is not > supposed to make/receives H.323 calls. > > The endpoint on the other hand, must be able to reasonably detect the > difference between the complete absence of GKs and the > absence of 'their' > GK (especially if some specific control/policy is in place). > > If the GK receives a GRQ, it must respond with a (directed) > GCF or GRJ. > > jimt. > > > At 10:55 AM 1/13/99 -0800, you wrote: > >Hi, > > > >This is wrt the second problem in the attached mail. > >Chris Purvis mentioned that GK needs to know whether > >a GRQ or LRQ is received via multicast or unicast so that > >the response could be different. > > > >Actually, H.323 V2 specifies different multicast and unicast > >responses only in case of LRQ. In case of GRQ, spec specifically > >mentions that even in multicast case a response shall be > >given (Section 7.2.1 para three which _only_ talks about > >multicast GRQs). > > > >I believe spec should not mandate a GK to respond to > >a multicast GRQ. It should be left to the implementor whether > >a response should be sent out to a multicast GRQ or not. > >The GK may have some additional information like redirecting > >the endpoint to a different GK with altGKInfo etc, otherwise it > >is just plain waste of bandwidth to mandate GK's to respond to > >multicast GRQ's. The endpoints would time out if they > >haven't received a single GCF. > > > >May be the following line in para 3 of section 7.2.1: > > > >"If a Gatekeeper does not want the endpoint to register to it, > >it shall return Gatekeeper Reject (GRJ)" > > > >should be changed to something like: > > > >"On receiving a multicasted GRQ, if a Gatekeeper does not want > >the endpoint to register to it, it MAY return Gatekeeper > >Reject (GRJ)" > > > >Comments? > > > >Regards, > >-Kishore. > > > > > >> -----Original Message----- > >> From: Mailing list for parties associated with ITU-T Study Group 16 > >> [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis > >> Sent: Thursday, January 07, 1999 9:33 PM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: Ambiguity in H.225.0 Appendix D > >> > >> > >> We have had an ambiguity show up during interoperability > >> testing, which > >> I would like clarified by means of the implementer's guide > and future > >> versions of the standard. Any objections, please shout in > the usual > >> way! > >> > >> The problem comes in 19.1.1.1 where UDP port numbers are > defined. The > >> standard currently (I'm looking at version 2) says: > >> Gatekeeper UDP Discovery Port 1718 > >> Gatekeeper UDP Registration and Status Port 1719 > >> > >> There are two problems with this. The first is that it > >> implies that the > >> LRQ message (which is nothing to do with discovery) always > needs to be > >> sent to port 1719, which is a problem for multicast LRQs, > because only > >> one IP address and port number pair has been registered with > >> the IETF - > >> 224.0.1.41:1718. > >> > >> The second problem is, if anything, more subtle... The > standard also > >> seems to imply by the above that GRQ, which is a discovery message, > >> should always be sent to port 1718, whether it is sent to the > >> multicast > >> discovery port or not. > >> The reason this is a problem is that gatekeepers need to > know whether > >> these messages (GRQ and LRQ) have arrived by multicast or > by unicast, > >> because the failure response is different in the two cases > >> (no response > >> to a multicast xRQ, but xRJ response to a unicast xRQ). The only > >> indication that most IP stacks give as to how a message > has arrived is > >> by a port number, however, so if all GRQs appear to port > 1718 (and all > >> LRQs to port 1719), there is no way for the gatekeeper to > tell whether > >> the message arrived by unicast or multicast. > >> > >> Common (but not universal - at least in products under > development!) > >> usage, driven by these practical considerations, seems to > be that the > >> most common implementations send both sorts of multicast > addresses to > >> the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ > >> messages to port 1719 (unless there is some private arrangement > >> specifying other special usage). > >> > >> My suggestion is that this common usage is standardised, > initially via > >> the implementer's guide, and then when appropriate in future > >> versions of > >> H.225.0. > >> > >> Regards, > >> Chris > >> > > > +1-503-264-8816(voice) Intel - Hillsboro, OR > mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >

1 0

None
by Patrik Suter 18 Jan '99

18 Jan '99

subscribe patrik.suter(a)bluewin.ch

2 1

Re: Ambiguity in H.225.0 Appendix D
by Kishore Babu Ramisetty 14 Jan '99

14 Jan '99

Hi, This is wrt the second problem in the attached mail. Chris Purvis mentioned that GK needs to know whether a GRQ or LRQ is received via multicast or unicast so that the response could be different. Actually, H.323 V2 specifies different multicast and unicast responses only in case of LRQ. In case of GRQ, spec specifically mentions that even in multicast case a response shall be given (Section 7.2.1 para three which _only_ talks about multicast GRQs). I believe spec should not mandate a GK to respond to a multicast GRQ. It should be left to the implementor whether a response should be sent out to a multicast GRQ or not. The GK may have some additional information like redirecting the endpoint to a different GK with altGKInfo etc, otherwise it is just plain waste of bandwidth to mandate GK's to respond to multicast GRQ's. The endpoints would time out if they haven't received a single GCF. May be the following line in para 3 of section 7.2.1: "If a Gatekeeper does not want the endpoint to register to it, it shall return Gatekeeper Reject (GRJ)" should be changed to something like: "On receiving a multicasted GRQ, if a Gatekeeper does not want the endpoint to register to it, it MAY return Gatekeeper Reject (GRJ)" Comments? Regards, -Kishore. > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis > Sent: Thursday, January 07, 1999 9:33 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Ambiguity in H.225.0 Appendix D > > > We have had an ambiguity show up during interoperability > testing, which > I would like clarified by means of the implementer's guide and future > versions of the standard. Any objections, please shout in the usual > way! > > The problem comes in 19.1.1.1 where UDP port numbers are defined. The > standard currently (I'm looking at version 2) says: > Gatekeeper UDP Discovery Port 1718 > Gatekeeper UDP Registration and Status Port 1719 > > There are two problems with this. The first is that it > implies that the > LRQ message (which is nothing to do with discovery) always needs to be > sent to port 1719, which is a problem for multicast LRQs, because only > one IP address and port number pair has been registered with > the IETF - > 224.0.1.41:1718. > > The second problem is, if anything, more subtle... The standard also > seems to imply by the above that GRQ, which is a discovery message, > should always be sent to port 1718, whether it is sent to the > multicast > discovery port or not. > The reason this is a problem is that gatekeepers need to know whether > these messages (GRQ and LRQ) have arrived by multicast or by unicast, > because the failure response is different in the two cases > (no response > to a multicast xRQ, but xRJ response to a unicast xRQ). The only > indication that most IP stacks give as to how a message has arrived is > by a port number, however, so if all GRQs appear to port 1718 (and all > LRQs to port 1719), there is no way for the gatekeeper to tell whether > the message arrived by unicast or multicast. > > Common (but not universal - at least in products under development!) > usage, driven by these practical considerations, seems to be that the > most common implementations send both sorts of multicast addresses to > the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ > messages to port 1719 (unless there is some private arrangement > specifying other special usage). > > My suggestion is that this common usage is standardised, initially via > the implementer's guide, and then when appropriate in future > versions of > H.225.0. > > Regards, > Chris >

2 1

Re: Ambiguity in H.225.0 Appendix D
by Rajesh Patwardhan 14 Jan '99

14 Jan '99

Just FYI on multicast/unicast taken from Stevens book: "...Some applications also bind the multicast address to the socket, in addition to the port. This prevents any other datagrams that might be received for that port from being delivered to the socket. Historically, Berkeley-derived implementations only require that some socketon the host join the mcast group, not necessarily the socket that binds the port and then receives the mcast datagram. There is a potential, however, with these implementations for mcast datagrams to be delivered to the applications that are not mcast aware. Newer mcast kernels now require that the process bind the port and set any mcast socket option for the socket, the latter being an indication that the application is mcast aware. Solaris 2.5 differs slightly and only delivers received mcast datagrams to a socket that has both joined the group and bound the port. For portability, all mcast apps should join a group and bind the port. Some older mcast-capable hosts do not allow the bind of mcast addr to a socket. For portability an application may wish to ignore a bind error for a mcast address...." ----rrp

1 0

Re: Relationship of H.323 and H.245 versions
by Chris Purvis 14 Jan '99

14 Jan '99

Pete, The answer to your direct question is, I believe, a) - but I don't see why it needs to be. In some senses an H.323 version is defined by a combination of an H.225.0 version and an H.245 version. You may or may not discover the second of these pieces of information from another endpoint, in particular if you're using faststart (it seems only to be communicated in a terminalCapabilitySet message). How you'd discover an H.323 version by any other means I don't know! There's also the issue that when people say they support version n, they do not necessarily mean that they support ALL the features of that version (it generally simply means that all the ASN.1 is there); also there may be cases where different signalling channels follow different routes (eg a version 28 gatekeeper or proxy routing a version 1 endpoint's (or vice versa) H.225 but not H.245) - so it's dangerous to make assumptions on the basis of knowledge of another party's version. Is there something particular that you're trying to achieve? If there's a reason for it, we need to think about how to put more versioning information in to the standards. I'd add the further question: Is there any point at which we can assume support of some of the H.450 supplementary services? Or H.235 security? I doubt it... Regards, Chris > -----Original Message----- > From: Pete Cordell [mailto:pete.cordell@BT-SYS.BT.CO.UK] > Sent: 14 January 1999 2:59 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Relationship of H.323 and H.245 versions > > > Gary, > > As H.323 editor can you comment on which of the following > statements is > more correct: > > a) H.323 version 2 can be used with H.245 version 3 ONLY > b) H.323 version 2 can be used with H.245 version 3 OR LATER. > > My view is that it is undesirable to have to up-issue H.323 to a new > version if all you want to do is make use of new features in H.245. > Also, as part of third party re-routing, in the future it may > occur that > an H.323 version 3 endpoint originally connected to another H.323 > version 3 endpoint will end up being connected to the H.245 from an > H.323 version 2 endpoint. Hence assuming that the H.323 and H.245 > versions are locked together does not work. However, I'm not sure if > this aligns with the groups understanding. Do you have any comments? > > Regards, > > Pete > > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= >

1 0

Relationship of H.323 and H.245 versions
by Pete Cordell 14 Jan '99

14 Jan '99

Gary, As H.323 editor can you comment on which of the following statements is more correct: a) H.323 version 2 can be used with H.245 version 3 ONLY b) H.323 version 2 can be used with H.245 version 3 OR LATER. My view is that it is undesirable to have to up-issue H.323 to a new version if all you want to do is make use of new features in H.245. Also, as part of third party re-routing, in the future it may occur that an H.323 version 3 endpoint originally connected to another H.323 version 3 endpoint will end up being connected to the H.245 from an H.323 version 2 endpoint. Hence assuming that the H.323 and H.245 versions are locked together does not work. However, I'm not sure if this aligns with the groups understanding. Do you have any comments? Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: Ambiguity in H.225.0 Appendix D
by Joerg Ott 14 Jan '99

14 Jan '99

>Kishore, > >Looks a pretty good summary of our discussions - let's see what fallout it >generates!!! > Chris, Kishore, here are some ideas on the problem for further thinking (no solutions, of course :-) In essence, basing a protocol action on on whether the provoking message was sent via unicast or multicast is not a very good idea anyway -- even if you manage to solve the problem of distinguishing one from the other upon reception. Rather, we may need a "bit" indicating transmission via multicast or unicast: Our data transmission allows for multi-unicast, so why should discovery not do so as well? Particularly, you could imagine a scenario where you receive a set of potential gatekeeper locations via private DHCP extensions, via manual configuation, etc. some of which may be up and willing to register you and some may not -- be it for load balancing, robustness, etc. Now you have to try all those locations to find a gatekeeper that accepts your registration but your network (unfortunately) is not supporting multicast. Querying the gatekeepers one by one may (but need not) lead to having to wait for timers to expire before you try the next one. Querying them in parallel is semantically equivalent to multicast even if you do not us IP multicast to reach everybody. Finally note that a gatekeeper's decision if to respond (and how much information to include in a response) may depend on whether it was asked individually or together with a number of other gatekeepers. Assuming these considerations are valid, the remaining question would be which piece(s) of information to use to implement the "this-request-is- multicast-bit". Joerg

1 0

Re: Ambiguity in H.225.0 Appendix D
by Chris Purvis 14 Jan '99

14 Jan '99

Kishore, Looks a pretty good summary of our discussions - let's see what fallout it generates!!! Chris > -----Original Message----- > From: Kishore Babu Ramisetty [mailto:kish@TRILLIUM.COM] > Sent: 13 January 1999 6:56 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Ambiguity in H.225.0 Appendix D > > > Hi, > > This is wrt the second problem in the attached mail. > Chris Purvis mentioned that GK needs to know whether > a GRQ or LRQ is received via multicast or unicast so that > the response could be different. > > Actually, H.323 V2 specifies different multicast and unicast > responses only in case of LRQ. In case of GRQ, spec specifically > mentions that even in multicast case a response shall be > given (Section 7.2.1 para three which _only_ talks about > multicast GRQs). > > I believe spec should not mandate a GK to respond to > a multicast GRQ. It should be left to the implementor whether > a response should be sent out to a multicast GRQ or not. > The GK may have some additional information like redirecting > the endpoint to a different GK with altGKInfo etc, otherwise it > is just plain waste of bandwidth to mandate GK's to respond to > multicast GRQ's. The endpoints would time out if they > haven't received a single GCF. > > May be the following line in para 3 of section 7.2.1: > > "If a Gatekeeper does not want the endpoint to register to it, > it shall return Gatekeeper Reject (GRJ)" > > should be changed to something like: > > "On receiving a multicasted GRQ, if a Gatekeeper does not want > the endpoint to register to it, it MAY return Gatekeeper > Reject (GRJ)" > > Comments? > > Regards, > -Kishore. > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Chris Purvis > > Sent: Thursday, January 07, 1999 9:33 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Ambiguity in H.225.0 Appendix D > > > > > > We have had an ambiguity show up during interoperability > > testing, which > > I would like clarified by means of the implementer's guide > and future > > versions of the standard. Any objections, please shout in the usual > > way! > > > > The problem comes in 19.1.1.1 where UDP port numbers are > defined. The > > standard currently (I'm looking at version 2) says: > > Gatekeeper UDP Discovery Port 1718 > > Gatekeeper UDP Registration and Status Port 1719 > > > > There are two problems with this. The first is that it > > implies that the > > LRQ message (which is nothing to do with discovery) always > needs to be > > sent to port 1719, which is a problem for multicast LRQs, > because only > > one IP address and port number pair has been registered with > > the IETF - > > 224.0.1.41:1718. > > > > The second problem is, if anything, more subtle... The > standard also > > seems to imply by the above that GRQ, which is a discovery message, > > should always be sent to port 1718, whether it is sent to the > > multicast > > discovery port or not. > > The reason this is a problem is that gatekeepers need to > know whether > > these messages (GRQ and LRQ) have arrived by multicast or > by unicast, > > because the failure response is different in the two cases > > (no response > > to a multicast xRQ, but xRJ response to a unicast xRQ). The only > > indication that most IP stacks give as to how a message has > arrived is > > by a port number, however, so if all GRQs appear to port > 1718 (and all > > LRQs to port 1719), there is no way for the gatekeeper to > tell whether > > the message arrived by unicast or multicast. > > > > Common (but not universal - at least in products under development!) > > usage, driven by these practical considerations, seems to > be that the > > most common implementations send both sorts of multicast > addresses to > > the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ > > messages to port 1719 (unless there is some private arrangement > > specifying other special usage). > > > > My suggestion is that this common usage is standardised, > initially via > > the implementer's guide, and then when appropriate in future > > versions of > > H.225.0. > > > > Regards, > > Chris > > >

1 0

White contributions for the Santiago SG16 meeting
by Sakae OKUBO 13 Jan '99

13 Jan '99

Dear Q.12-14/16 experts, I have sent to ITU-TSB and placed at the ftp site the following two white contributions regarding H.222.0: White_H2220_AMD5.zip Draft for Amendment 5 to ITU-T Recommendation H.222.0|ISO/IEC 13818-1 White_H2220_AMD6.zip Draft for Amendment 6 to ITU-T Recommendation H.222.0|ISO/IEC 13818-1 Its location is: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ The first one (AMD5) is basically an integration of APC-1451 and 1450 of the Torino meeting. The second one is basically TD-30/P of the September 1998 meeting of SG16. I have considered the changes made at the MPEG meeting in December 1998 (actually there were elevated one step without changes at that meeting). Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Correction to the notice of the Monterey meeting
by Sakae OKUBO 10 Jan '99

10 Jan '99

Dear Q.12-14/16 experts, This is a minor correction to the meeting notice I posted on 9 January. The date of issue should read "9 January 1999" instead of "?? January 1999." The corrected version has been placed at the ftp site: ftp://standard.pictel.com/avc-site/9902_Mon/Notice_Monterey.txt or http://standard.pictel.com/ftp/avc-site/9902_Mon/Notice_Monterey.txt Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Notice of the Monterey meeting
by Sakae OKUBO 09 Jan '99

09 Jan '99

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. I. Sebestyen, IMTC BoD Member De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Gary Thom Rapporteur for Q.14/16 in ITU-T SG16 Delta Information Systems Inc. Horsham Business Center Bldg. 3 300 Welsh Road, Horsham, PA 19044 Tel: +1 215 657 5270 ex 23 Fax: +1 215 657 5273 E-mail: gthom(a)delta-info.com ------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting Date: ?? January 1999 ------------------------------------------------ Dear SG16 Colleagues, The subject meeting of ITU-T SG16 experts will be held in Monterey, USA at the kind invitation of IMTC. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) February 1999 starting at 9:00 on the first day Please note that this time we meet for FIVE days. 2. Venue ^^^^^^^^ Embassy Suites on Monterey Bay 1441 Canyon Del Rey, Seaside California 93955 USA Tel: +1.831.393.1115 Fax: +1.831.393.1113 or +1.831.899.1928 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - H.321 Implementors Guide - MPEG packetization (jointly with Q.13) - Future audiovisual communication system 3) Q.13/16 Packet switched multimedia systems and terminals - Advance the work of H.323 V3/H.225.0 V3 - Discussion of H.323 Annex C V3 - Further development of GK-GK communications - Preparation of new H.450.x drafts for determination - Discussion of new SUDs 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Preparation of H.GCP for determination - Preparation of H.224 V2 for determination - Discussion of ISUP signaling transport - Discussion of new H.246 interworking Annexes 5) Coordination with Q.11/16 and Q.15/16 - Requirements for IMT-2000 - Requirements for H.26L 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 5 February /// /// Distribution of the document: by 8 February /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 5 February (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Monterey, 15-19 February 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (by 8 February) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9902_Mon directory of the ftp site. 5) Please bring 60 copies of your document to Monterey. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited. 6) The document distribution / handling at the meeting will be electronic (i.e. participants must bring their laptops along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (ftp://standard.pictel.com/avc-site/9902_Mon/Invitation_Monterey.zip) 6. Registration ^^^^^^^^^^^^^^^ To confirm your meeting attendance, please reply directly to Georgia Lund (georgia(a)inventures.com) and include the following information for each individual from your organization attending the meeting: Mr./Ms. ?: Name: Job Title: Company: Official Mailing Address: Phone: Fax: E-mail: Will you attend the reception on Tuesday, February 16, 1999? Please indicate which of the group(s) below you intend to participate in: * Plenary meeting (Q.11-15) * Q.11 * Q.12-14 * Q.15 with copy to three Rapporteurs (e-mail: okubo(a)giti.or.jp, Dale.Skran(a)ascend.com, gthom(a)delta-info.com) 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact Embassy Suites on Monterey Bay using the form included in the host's invitation as indicated in 5 above. Participants are requested to book at the Embassy Suites, as its "conference arrangement" price is very reasonable, paying also for the conference facilities including beverages. Your cooperation helps the meeting host. CUTOFF DATE for the special room rate is Wednesday, 27 January 1999. We are looking forward to meeting with you in Monterey. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM ----------

1 0

Ambiguity in H.225.0 Appendix D
by Chris Purvis 08 Jan '99

08 Jan '99

We have had an ambiguity show up during interoperability testing, which I would like clarified by means of the implementer's guide and future versions of the standard. Any objections, please shout in the usual way! The problem comes in 19.1.1.1 where UDP port numbers are defined. The standard currently (I'm looking at version 2) says: Gatekeeper UDP Discovery Port 1718 Gatekeeper UDP Registration and Status Port 1719 There are two problems with this. The first is that it implies that the LRQ message (which is nothing to do with discovery) always needs to be sent to port 1719, which is a problem for multicast LRQs, because only one IP address and port number pair has been registered with the IETF - 224.0.1.41:1718. The second problem is, if anything, more subtle... The standard also seems to imply by the above that GRQ, which is a discovery message, should always be sent to port 1718, whether it is sent to the multicast discovery port or not. The reason this is a problem is that gatekeepers need to know whether these messages (GRQ and LRQ) have arrived by multicast or by unicast, because the failure response is different in the two cases (no response to a multicast xRQ, but xRJ response to a unicast xRQ). The only indication that most IP stacks give as to how a message has arrived is by a port number, however, so if all GRQs appear to port 1718 (and all LRQs to port 1719), there is no way for the gatekeeper to tell whether the message arrived by unicast or multicast. Common (but not universal - at least in products under development!) usage, driven by these practical considerations, seems to be that the most common implementations send both sorts of multicast addresses to the registered address - 224.0.1.41:1718, and unicast GRQ and LRQ messages to port 1719 (unless there is some private arrangement specifying other special usage). My suggestion is that this common usage is standardised, initially via the implementer's guide, and then when appropriate in future versions of H.225.0. Regards, Chris

1 0

FW: Notice of Meeting and Call for Contributions on new ITU quest ion on Internet Gateway Equipment
by Tom-PT Taylor 07 Jan '99

07 Jan '99

> -----Original Message----- > From: Jerry Skene [SMTP:Jerry.Skene@tellabs.com] > Sent: Thursday, January 07, 1999 10:41 AM > To: sigtran(a)BayNetworks.COM; list iptel; 'tsg16q13(a)itu.int'; > 'stg16q14(a)itu.int'; Taylor, Tom-PT [SKY:B318-I:EXCH]; > 'TIPHON_WG6(a)LIST.ETSI.FR'; 'TIPHON_WG2(a)LIST.ETSI.FR'; > 'TIPHON_WG5(a)LIST.ETSI.FR' > Subject: Notice of Meeting and Call for Contributions on new ITU > question on Internet Gateway Equipment > > Notice of Meeting and Call for Contributions on new ITU question on > Internet Gateway Equipment > > In October, the Telecommunications Standardization Bureau of the > International Telecommunications Union, (ITU-T) Study Group 15 > (Transport Networks, Systems and Equipment)approved a new Question > dealing with interconnection equipment between the GSTN and IP Networks. > The first meeting of this new Question (Q21/15)will be held in > conjunction with the Study Group 15/Working Party 2 interim meeting on > 16 - 19 February, 1999. > > ITU members can find the full text of the question on the ITU Informal > FTP Area, at: > http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm > Note that this site is password protected, and is accessible to ITU > members only. > > Non-ITU members can find the text of the Question at: > http://www.coherent.com/itu > > This message is a call for contributions on this important new work. The > goal of > the February meeting is to establish working methods for the Question, > the baseline structure for the Recommendation, a timetable for > completion of the work, and to begin > drafting text. > > The Recommendation being developed in this Question will be of interest > to the following parties: > - GSTN telephony carriers interfacing or planning to interface their > networks to the Internet > - Internet Service Providers carrying or planning to carry telephony > traffic originating or terminating on the GSTN > - Network equipment vendors providing or developing Internet > Telephony interface equipment > > Meeting Registration > ITU and interested non-ITU members may attend this meeting. Details on > registration for the interim meeting may be obtained from the host, Tom > Oshidari [toshidari(a)ditechcorp.com] The venue for the meeting is the > Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one > day long, and will be held during the week of February 15-19. The > specific day will be known by January 15. > > Contributions > If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry > Skene and the host, Mr. Oshidari know. If you plan to submit a > contribution on this topic, please email it to the Rapporteur, and it > will be included in the discussion. > > If you are a non ITU member, you are most welcome to attend and to > submit contributions. Please contact the rapporteur for guidance on > this. > > To ensure proper consideration of a contribution, the title of the > contribution must be received by the rapporteur no later than January 8, > 1999. > > Sincerely; > > Jerry Skene Rapporteur, Q21/15 > > _________________________________________________ > Jerry Skene | Tellabs, Inc. > Director, | 45085 University Drive > International Standards | Ashburn, VA 20147.2745 USA > tel:+1 703 724-7302 | URL: www.tellabs.com > fax: +1 703 724-7202 | email: jerry.skene(a)tellabs.com > >

1 0

Fwd: Notice of Meeting and Call for Contributions on new ITU question on Internet Gateway Equipment
by Joerg Ott 07 Jan '99

07 Jan '99

Just FYI, in case you are not subscribed to the ITU-based e-mail reflectors of SG16. Actually, there was a *very* lucky hand involved in picking the date. Joerg >From: Jerry Skene <Jerry.Skene(a)tellabs.com> >To: sigtran(a)BayNetworks.COM, list iptel > <iptel(a)lists.research.bell-labs.com>, > "'tsg16q13(a)itu.int'" > <tsg16q13(a)itu.int>, > "'stg16q14(a)itu.int'" <stg16q14(a)itu.int>, > "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" <Tom-PT.Taylor.taylor(a)nt.com>, > "'TIPHON_WG6(a)LIST.ETSI.FR'" <TIPHON_WG6(a)LIST.ETSI.FR>, > "'TIPHON_WG2(a)LIST.ETSI.FR'" <TIPHON_WG2(a)LIST.ETSI.FR>, > "'TIPHON_WG5(a)LIST.ETSI.FR'" <TIPHON_WG5(a)LIST.ETSI.FR> >Subject: Notice of Meeting and Call for Contributions on new ITU question > on Internet Gateway Equipment >Date: Thu, 7 Jan 1999 10:40:34 -0500 >X-Mailer: Internet Mail Service (5.5.1960.3) >Sender: owner-iptel(a)lists.research.bell-labs.com > >Notice of Meeting and Call for Contributions on new ITU question on >Internet Gateway Equipment > >In October, the Telecommunications Standardization Bureau of the >International Telecommunications Union, (ITU-T) Study Group 15 >(Transport Networks, Systems and Equipment)approved a new Question >dealing with interconnection equipment between the GSTN and IP Networks. >The first meeting of this new Question (Q21/15)will be held in >conjunction with the Study Group 15/Working Party 2 interim meeting on >16 - 19 February, 1999. > >ITU members can find the full text of the question on the ITU Informal >FTP Area, at: >http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm >Note that this site is password protected, and is accessible to ITU >members only. > >Non-ITU members can find the text of the Question at: >http://www.coherent.com/itu > >This message is a call for contributions on this important new work. The >goal of >the February meeting is to establish working methods for the Question, >the baseline structure for the Recommendation, a timetable for >completion of the work, and to begin >drafting text. > >The Recommendation being developed in this Question will be of interest >to the following parties: >- GSTN telephony carriers interfacing or planning to interface their >networks to the Internet >- Internet Service Providers carrying or planning to carry telephony >traffic originating or terminating on the GSTN >- Network equipment vendors providing or developing Internet >Telephony interface equipment > >Meeting Registration >ITU and interested non-ITU members may attend this meeting. Details on >registration for the interim meeting may be obtained from the host, Tom >Oshidari [toshidari(a)ditechcorp.com] The venue for the meeting is the >Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one >day long, and will be held during the week of February 15-19. The >specific day will be known by January 15. > >Contributions >If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry >Skene and the host, Mr. Oshidari know. If you plan to submit a >contribution on this topic, please email it to the Rapporteur, and it >will be included in the discussion. > >If you are a non ITU member, you are most welcome to attend and to >submit contributions. Please contact the rapporteur for guidance on >this. > >To ensure proper consideration of a contribution, the title of the >contribution must be received by the rapporteur no later than January 8, >1999. > >Sincerely; > >Jerry Skene Rapporteur, Q21/15 > >_________________________________________________ >Jerry Skene | Tellabs, Inc. >Director, | 45085 University Drive >International Standards | Ashburn, VA 20147.2745 USA >tel:+1 703 724-7302 | URL: www.tellabs.com >fax: +1 703 724-7202 | email: jerry.skene(a)tellabs.com > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. >

1 0

New email address for Tom Geary
by tom.geary＠CONEXANT.COM 05 Jan '99

05 Jan '99

Dear colleges: With the formation of the new company by Rockwell known as"Conexant", my email address has changed. Please note it is now "tom.geary(a)conexant.com" (was "tom.geary(a)rss.rockwell.com"). {Jim and Cor, could you do me a favor and correct my email address in the reflector lists? Sorry to trouble you but with my outgoing mail now bearing the new address, I cannot remotely delete myself and I don't want to be duplicated in the data base.} Thank you, Tom Geary

1 0

H.283 white draft
by Mark Duckworth 05 Jan '99

05 Jan '99

I uploaded H283white.zip to ftp://standard.pictel.com/avc-site/Incoming Gary, this is the same as H283draftD which I sent to you a couple of weeks ago. Mark Duckworth PictureTel Corporation

1 0

a problem about telephony gateway and gatekeeper
by Chia-Ming Tu 28 Dec '98

28 Dec '98

Hi I'd like to deploy an environment as follows: a telephony gateway, which converts PSTN phone calls to H.323 calls. a gatekeeper, which is responsible for admission control and address translation, etc. If a user wants to use the gateway, he must pass the authentication, such as an valid ID/password. My problem is: is it possbile for the gatekeeper to do the authentication with RAS channel or other H.323 messages? It seems that admission control by the gatekeeper is for an H.323 endpoint, not for a 'user' of that endpoint. So in the above gateway environment, the gateway is admitted to the H.323 network, while the user might use a wrong ID/password to be rejected to use the gateway. Therefore it's not appropriate for the gatekeeper to do the authentication job. Am I right? Thanks a lot. -- =============================== = Chia-Ming Tu = = Technology Service Division = = III = = Taipei, Taiwan = ===============================

1 0

H.224 Revision
by Gary A. Thom 27 Dec '98

27 Dec '98

I have uploaded H224_wcm.doc to the incomming directory of the FTP site. This document contains changes to H.224 which should be determined at the next SG16 meeting in May 1999. If you have any questions or comments, please contact: Mickey Nasiri <mickey.nasiri(a)ericsson.com> Tel: +46-8-7262638 Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

1 0