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

Re: Annex G
by Roy, Radhika R, ALTEC 07 Sep '98

07 Sep '98

Dear Mr. Clowes: The "abstraction of routing" between the GKs is an option. Whether the "abstraction of this routing option" to be used through a chain of zones or not is left up to the implementation schemes. If one does not feel the advantage of this option, then one may not use it. I hope that this will clarify the things. Regards, Radhika R. Roy PS When we see references in H.323 that a message is to be sent from one GK to another GK, it implies that the message has to be "routed" from one GK to another. (In another scenario, when in H.323 it is assumed that messages are to be sent between the GKs via "multicasting", it is also a kind of "routing" through a tree architecture that has a "chain of branches" where GKs are located.) > ---------- > From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Sunday, September 06, 1998 6:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > At 19:38 05/09/98 -0400, you wrote: > > >3.2 Routing > > > >Like inter-zone, the communications between the domains also need > >the abstraction of routing to facilitate inter-GK communications > >since the inter-domain communication is nothing but the communications > >through a chain of zones. > > It would appear to me that "the communications through a chain of zones" > is > prone to introducing problems. > > Douglas > > >Hi Editor/SG16 Members: > > > >A proposal on Annex G is enclosed. Your comments will be highly > appreciated. > > > > <<m_G.doc>> > >Sincerely, > > > >Radhika R. Roy > >AT&T > >Tel: + 1 732 949 8657 > >Email: rrroy(a)att.com > > > >Attachment Converted: "c:\eudora\attach\m_G.doc" > > >

1 0

TD indicating typographical errors in COM 16-68-E
by Sakae OKUBO 07 Sep '98

07 Sep '98

Dear Q.12-14 experts, The following TD has been placed at PictureTel ftp site: ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/TDb_for_16-68.zip This points out some printing errors contained in COM 16-68-E Draft H.310 V2 for Decision. 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

Q14 status report and index file
by Sakae OKUBO 06 Sep '98

06 Sep '98

Dear Mr. Thom and other Q.12-14/16 experts, G Thom> I have uploaded q14stat.doc to the incoming directory. This has been zipped and moved to /9809_Gen/Input_TD directory. Please also be advised that I have updated /9809_Gen/9809_Gen.html (index of the documents). 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

Re: No root node
by Santo Wiryaman 04 Sep '98

04 Sep '98

Pete, Thanks. I like that. -santo ---------- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Friday, September 04, 1998 2:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: No root node Santo, In general, to a first order approximation, I would expect a fully meshed arrangement of 'country' border elements. However I would see the fine detail of the structure being down to who people have arrangements for resolving addresses with. For example, BT might go to AT+T to resolve all North and South American numbers, and AT+T might come to BT for all European numbers. I could also see that opportunistic companies could set up global clearing houses that would handle address translation for outfits that haven't been able to establish their own knowledge of all the borders such as ISPs, or corporates. This would look like a root node to the people that used it, but it would be used purely as a commercial expedient and not mandated by the way the standard works. On the issue of France moving its entry point to Lyon for the week, I think we have to allow France to have more than one entry point. After all, Paris could all of a sudden slide into the Seine, and the press, if nobody else, would still want to make calls into France to find out what's going on. By having multiple entry points, the French can turn off their Paris BE for a while and switch on their Lyon one, and if the data didn't propagate around the system for a while it wouldn't really matter too much. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Sent: 04 September 1998 17:29 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: No root node > >Hi All, > >I am not at all opposed to eliminating the root domain. A couple of >questions for Pete and the group: > >1. Are you suggesting that at the national level the border elements >are fully meshed together, or alternatively arranged in a big ring as >Radhika is suggesting? >2. If so, when a new country "goes on-line" endpoints in the new >country would not be reachable until the information is propagated in >this fully meshed database (or inserted in the ring). >3. Same if, say France, had to switch its National H.323 Border Element >from Paris to Lyons for one week. >4. Are you open to the idea of a global clearing house to resolve the >address of border elements of countries which are currently not listed >in the fully-meshed database. > >Regards, > >Santo Wiryaman >Videoserver > > >---------- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, September 03, 1998 10:20 AM >To: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: No root node > >Dear All, > >Apologies for not being on the last call, but... > >I feel one really important issue with Santo's contribution is that we >must remove the root domain. Having such a concept would give >politicians and lawyers far too much work!!! I believe the notes that >I >put forward would allow the root node to be removed, and based on >comments I heard from Jim, I believe what he is proposing would allow >this too. > >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: No root node
by Pete Cordell 04 Sep '98

04 Sep '98

Santo, In general, to a first order approximation, I would expect a fully meshed arrangement of 'country' border elements. However I would see the fine detail of the structure being down to who people have arrangements for resolving addresses with. For example, BT might go to AT+T to resolve all North and South American numbers, and AT+T might come to BT for all European numbers. I could also see that opportunistic companies could set up global clearing houses that would handle address translation for outfits that haven't been able to establish their own knowledge of all the borders such as ISPs, or corporates. This would look like a root node to the people that used it, but it would be used purely as a commercial expedient and not mandated by the way the standard works. On the issue of France moving its entry point to Lyon for the week, I think we have to allow France to have more than one entry point. After all, Paris could all of a sudden slide into the Seine, and the press, if nobody else, would still want to make calls into France to find out what's going on. By having multiple entry points, the French can turn off their Paris BE for a while and switch on their Lyon one, and if the data didn't propagate around the system for a while it wouldn't really matter too much. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Sent: 04 September 1998 17:29 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: No root node > >Hi All, > >I am not at all opposed to eliminating the root domain. A couple of >questions for Pete and the group: > >1. Are you suggesting that at the national level the border elements >are fully meshed together, or alternatively arranged in a big ring as >Radhika is suggesting? >2. If so, when a new country "goes on-line" endpoints in the new >country would not be reachable until the information is propagated in >this fully meshed database (or inserted in the ring). >3. Same if, say France, had to switch its National H.323 Border Element >from Paris to Lyons for one week. >4. Are you open to the idea of a global clearing house to resolve the >address of border elements of countries which are currently not listed >in the fully-meshed database. > >Regards, > >Santo Wiryaman >Videoserver > > >---------- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, September 03, 1998 10:20 AM >To: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: No root node > >Dear All, > >Apologies for not being on the last call, but... > >I feel one really important issue with Santo's contribution is that we >must remove the root domain. Having such a concept would give >politicians and lawyers far too much work!!! I believe the notes that >I >put forward would allow the root node to be removed, and based on >comments I heard from Jim, I believe what he is proposing would allow >this too. > >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: No root node
by Santo Wiryaman 04 Sep '98

04 Sep '98

Hi All, I am not at all opposed to eliminating the root domain. A couple of questions for Pete and the group: 1. Are you suggesting that at the national level the border elements are fully meshed together, or alternatively arranged in a big ring as Radhika is suggesting? 2. If so, when a new country "goes on-line" endpoints in the new country would not be reachable until the information is propagated in this fully meshed database (or inserted in the ring). 3. Same if, say France, had to switch its National H.323 Border Element from Paris to Lyons for one week. 4. Are you open to the idea of a global clearing house to resolve the address of border elements of countries which are currently not listed in the fully-meshed database. Regards, Santo Wiryaman Videoserver ---------- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Thursday, September 03, 1998 10:20 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: No root node Dear All, Apologies for not being on the last call, but... I feel one really important issue with Santo's contribution is that we must remove the root domain. Having such a concept would give politicians and lawyers far too much work!!! I believe the notes that I put forward would allow the root node to be removed, and based on comments I heard from Jim, I believe what he is proposing would allow this too. 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

latest RDC docs posted to ftp site
by Charles M Grandgent 04 Sep '98

04 Sep '98

Andy's latest RDC doc revisions are now posted to the IMTC ftp site. The files are: TrdcRevC.zip and VrdcRevB.zip and are at: ftp://ftp.imtc-files.org/imtc-site/T120-top/geneva98-2/ Chuck Forwarded message:

1 0

RDC documents - version submitted to Geneva
by Andy Woollett 04 Sep '98

04 Sep '98

------ =_NextPart_001_01BDD801.3DDD4480 Content-Type: text/plain Hi Chuck, I have another version of RDC. Could you please place these documents into the Geneva98-2 directory at the IMTC site directory and then forward the following message to the Q3 reflector. Thanks Andy Woollett --------------------------------------------- All: The following draft documents have been placed in the Geneva98-2 directory at the IMTC site. /pub/imtc-site/T.120-top/Geneva98-2/VRDCrevB.zip /pub/imtc-site/T.120-top/Geneva98-2/TRDCrevC.zip VRDVrevB.zip contains VRDCrevB.doc - submitted to Geneva as a delayed contribution VRDCrevB_CB.doc - as above but with revision marks TRDVrevC.zip contains TRDCrevC.doc - submitted to Geneva as a delayed contribution TRDCrevC_CB.doc - as above but with revision marks Main Changes * The detailed description of the device list how been moved from T.RDC into V.RDC. The ASN.1 describing the device list has moved into V.RDC. * An optional flag has been added to the RDC-Device-Control primitive to allow the User Application to send the request via a low latency data channel. * Explicit references to H.RDC have been removed since it will not be determined until April 1999. * The optional Stream Identifier flag in the RDC-Source-Select request primitive has been made mandatory. * The ASN.1 in V.RDC has been completed. * The Pan View, Tilt View and Zoom Magnification attributes must be supported if the Pan Position, Tilt Position and Zoom Position attributes are supported. * Added a section describing the allocation of camera device IDs for interoperability with H.281. Andy Woollett ImageCom Limited UK -- ---------------------------------------------------------- Chuck Grandgent, Nexus Systems Inc., Salem, NH 603-894-6110 x1017 chuck(a)nexussystems.com chuck(a)k1om.com http://www.nexussystems.com http://www.k1om.com *** "PCs - Automobiles for the mind." *** ----------------------------------------------------------

1 0

Delayed Contributions and Input TDs
by Sakae OKUBO 04 Sep '98

04 Sep '98

Dear Q.12-14/16 experts, The following documents have been moved to /Delayed or /Input_TD directories: Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H323DTCP_rev.rtf Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H323anxD.rtf Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H450Comm.rtf Kajos> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/HMMIB01.ZIP Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/H220AM6.zip Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/Interim.zip Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/Q12status.zip 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.225 Annex G
by Glen Freundlich 04 Sep '98

04 Sep '98

Has anybody looked at any of the iptel work to see if it's applicable to H.225.0 Annex G? I've not yet reviewed any of the material so can't comment. There is a framework document and some others to be found at http://www.bell-labs.com/mailing-lists/iptel. Additionally, there are some viewgraphs at http://www.cs.columbia.edu/~jdrosen/papers/ietf_iptel_aug98.ppt. Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

3 2