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

H.225.0 Annex G discussion
by Glen Freundlich 07 Jul '98

07 Jul '98

There will be a conference call on Thursday, 9 July, at 7:00am Pacific Time (10:am Eastern Time) to discuss H.225.0 Annex G. We've reserved an audio bridge with enough ports to handle the number of people who responded to the first notice of this topic. The bridge number is +1 916 356 9200, passcode 9774794 (conference name is "H.323 Annex G", chair is Jim Toga). This call will be limited to 1 hour. Minutes from the call will be published to the SG16 email list. The goal of this call will be to get work going on Annex G. A tentative agenda is: - review the work that's been done so far - terms of reference - system organization - definitions - APC-1422 - what's up with Diameter - decide what we'd like to see for determination in September (i.e., set the initial scope of work) - enumerate open issues - set some kind of work plan - prioritize open issues - decide who will work specific issues - calls every 2 weeks Good preparation material would be the existing Annex G (APC-1375 from Cannes), APC-1422, APC-1385, APC-1407, APC-1414, TD-27, and the terms of reference from the Yokosuka meeting (TD-17 from Yokosuka). 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

1 0

Next pass of Implementers Guide
by Jim Toga 06 Jul '98

06 Jul '98

Greetings, Attached please find the updated Rev2 Implementers Guide. All of the changes highlighted in gray text are post Cannes meeting. I have not incorporated any of the ICV changes as it doesn't seem like we have reached any clear solution...... Please get feedback to me before Thursday PM, as I need to send the white document into the TSB. Best Regards, jimt. ***************************************************** *** +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

H.225.0 clarifications
by Glen Freundlich 06 Jul '98

06 Jul '98

A couple clarifications may be needed regarding the IRQ message in H.225.0. Item 1: The definition of callReferenceValue currently states "If zero, this message is interpreted as a request for an IRR for each call the terminal is active on." The IRR defines perCallInfo as a SEQUENCE OF SEQUENCE and I seem to recall that the original intent was to be able to pass information about multiple calls within a single IRR message. So, I'd suggest changing the definition to "If zero, this message is interpreted as a request for perCallInfo for every call that is active at the endpoint, and which may be sent in one or more IRRs". Item 2: The callIdentifier field is not currently optional in the IRQ. I see these possibilities for callIdentifier in the case of a request for information about all calls: 1) state that if callReferenceValue is 0, this field is to be ignored but filled with some data 2) state that callIdentifier should be set to some dummy value, such as all zeros 3) change the ASN.1 definition so that callIdentifier is OPTIONAL, and add appropriate text regarding its use in the field definition Since callIdentifier is defined as a SEQUENCE to allow possible future expansion, I'd suggest option 1. Please comment. 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

2 1

Re: ASN.1 accross revisions
by Pete Cordell 03 Jul '98

03 Jul '98

Bancroft and others, I take your point that putting a second piece of ASN.1 into the UUIE may jeopardize backwards compatibility. I have to admit that I have to try quite hard to read H.225 in such a way that it allows me to do this (but it is possible!!!). The basic issue is whether having read and decoded the ASN.1 in the UUIE, implementations check whether all characters in the UUIE have been used. I guess only a poll of vendors would determine whether this is the case. An alternative to adding on an extra piece of ASN.1 in the case of the Q.931 side would be to hi-jack one of the other IEs that we are unlikely to use, and use that for the signature values. For example one that we might use is "Packet Layer Binary Parameters" which has an IE value of 0x44. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@oss.com] >Sent: 30 June 1998 21:21 >To: Pete Cordell >Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' >Subject: RE: ASN.1 accross revisions > >On Tue, 30 Jun 1998, Pete Cordell wrote: > >> I admit that I am only just hanging in there with this debate, but I >> think I have a possible solution 5 to throw in as a contender. >> >> Looking at the problem a bit laterally, we have RasMessage in UDP >> packets that we want to sign, and H323-UserInformation in the UUIE that >> we want to sign. Currently these are the only chunks of ASN.1 in these >> fields. >> >> We could add a second piece of ASN.1 into these fields (UDP packet and >> UUIE) that contains the signatures, such as: >> >> H323Extra ::= CHOICE >> { >> icv ICV, >> ... >> } >> >> This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you >> would get: >> >> RasMessage chunk of ASN.1 >> H323Extra chunk of ASN.1 typically containing signature >> >> Similarly in the UUIE, you would have >> >> H323-UserInformation chunk of ASN.1 >> H323Extra chunk of ASN.1 >> >> Note that all the key ids and time stamps etc., would remain in the >> RasMessage and H323-UserInformation parts (so they get signed). >> >> I agree this is not beautiful, but it does not require multiple ASN.1 >> encodings, and doesn't radically change the format of the message >> depending on whether you want to sign it or not (as solution 4 seems >> to). > >This crossed my mind a couple days ago, but it is not clear how this >would >be backward compatible. That is, how would an older version handle >this >added information that comes after the H323-UserInformation? I like >the >general idea, but if I am not mistaken it is not backward compatible. > >I have an idea as to how to do as you suggest in a backward compatible >manner, but before I go down that path I need to know the answer to >the question: Are the most recent implementations that know of H.323 >required to transmit an ICV with each RasMessage or >H323-UserInformation? > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 > >

1 0

H.225.0 Annex G discussion
by Glen Freundlich 02 Jul '98

02 Jul '98

I'd like to get some traction on Annex G, and so would like to propose holding a brief (no more than 1 hour) conference call on Thursday, July 9 beginning at 7:00 am Pacific Time in the U.S. (10:00 am Eastern Time, is that 16:00 in the U.K.?). I'll send out an agenda on Monday, July 6. If you are interested in joining this call, please let me know by Monday, July 6, 14:00 Mountain Time in the U.S. so that I can arrange for a bridge with a sufficient number of ports. 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

1 0

Test
by Roy, Radhika R, ALTEC 02 Jul '98

02 Jul '98

Please ignore it.

1 0

Re: ASN.1 accross revisions
by Orit Levin 02 Jul '98

02 Jul '98

Hello all! Sorry for joining the discussion just now. We are aware of the mentioned problem and have been listening to the discussion. Since we have an access to our ASN.1 compiler, we were thinking of implementing "Solution 2" (although using a more precise definition). Saying that, we would be glad to find a more correct approach both from academic and efficiency points of view. - The new definition (i.e. the V.2 correction) indeed has to be done very quickly. - Our additional concern is, that the solution should be backward compatible with already deployed V.1 products. Did anybody check "Solution 4" in this light? Across different Compilers? Best Regards, Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 ext. 230 Fax: 201-529-3516

1 0

H.225.0 corrections
by Glen Freundlich 02 Jul '98

02 Jul '98

At the Yokosuka meeting, some corrections were identified in H.225.0 to use the Information message instead of the User Information message (see APC-1362). There were 2 remaining references to User Information that should be changed to Information. The first is in the h323-message-body structure, where "userInformation" should be changed to "information". The second is in the UUIEsRequested structure, where "userInformation" should be changed to "information". These corrections will appear in the Implementors Guide. Please let me know if you see any problems with these changes. 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

1 0

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 01 Jul '98

01 Jul '98

Dear Mr. Cordell: I fully agree with you. This is what heard in the Cannes meeting. I would have been somewhat happier if I would see this viewpoint that has been expressed in your email would have been included in the Cannes meeting report (APC-1425). My question is: Will Mr. OKUBO be pleased to include at least this viewpoint in the final Cannes report? Sincerely, Radhika R. Roy AT&T USA Tel: + 1 732 949 8657 email: rrroy@.att.com > ---------- > From: Pete Cordell[SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, July 01, 1998 12:20 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Report of the Cannes meeting > > My understanding of the meeting was that APC-1422 was considered as good > a place as any to start with a development, but there was acceptance > that the final result may differ radically from what is in APC-1422, and > we didn't want to preclude any other solution that we might find that > was either already written, so somehow fitted our needs better than the > framework that was out lined in APC-1422. It's my recollection that it > was the view of the Intel delegates that this was a satisfactory > situation. > > 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: Jim Toga[SMTP:jim.toga@INTEL.COM] > >Sent: 29 June 1998 21:51 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: Report of the Cannes meeting > > > >Dear Mr Roy, > > > >Although I was unable to attend the meeting in Cannes, I have read all > >the > >previous reports and have spoken to a number of people that attended. > >There were many discussions during the meeting, which are summarized > >in > >the meeting report without re-hashing every detail. My understanding is > >that there were no objections from _anyone_ else at the meeting to > >progressing the work that has been started in APC-1422. The intent > >will be > >to have both telephone and email exchanges to further develop this > >work. > >I would look forward to having your constructive input as we move > >forward. > >In the spirit of this, I would like to elicit your input here. > > > >I would like to point out a couple of misconceptions you might have > >based > >upon the text below and ask you for some concrete proposals in areas > >where > >you feel they're needed... > > > >Best Regards, > >jimt. > > > > > >[SNIP] > > > >> > >>Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > >> > >>APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > >> > >>Mr. Roy also pointed out the following: > > > >If these points were raised in the APC document and covered during the > >meeting why do they need to be called out explicitly in the meeting > >report? > > The list of contributed documents is part of the meeting. > > > >> > >> * H.323 signaling schemes that were developed for > >>H.323v1 in view of the LAN-based single GK model > > > >Both v1 and v2 have never limited GK deployment to one entity (on the > >LAN > >or any other topology) The defined signalling for address resolution > >allows for N gatekeepers. > > > >>(signaling schemes in > >>H.323v2 also remain almost the same so far the inter-GK communication is > >>concerned) may not be good enough to satisfy all needs when it is > applied in > >>the context of multiple gatekeeper environment with different inter-GK > >>architectures: Distributive, Centralized, and Hybrid (Distributive + > >>Centralized). > > > >(I think you mean 'Distributed' above) In any case, these different > >modes > >of operation define models with respect to _media_ distribution, not > >control. In this case they would (and do) affect the operation of an > >MCU. > >(this is not to say that the MCU can't be co-located with the GK). > > > >V1 and V2 (and certainly the intent with V3) allow for many different > >GK > >topologies with hierarchical being one of the more general ones. Flat > >peer-peer models may be accomplished by having a degenerative > >'hiearchy' > >with a depth of 1. > > > >> * Each inter-GK architecture may need different > >>signaling schemes in order to optimize the use of communication > resources > >>especially in the context large networks for both connectionless and > >>connection oriented networks. > > > >Can you eloborate on this? Are you simply saying that we need to allow > >both UDP and TCP signalling (which is in fact specified in section 4 of > >APC-1422). > > > > > >> > >>APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper > >>Communications" > >> > >>During the discussion of Intel's contribution, Mr. Roy also pointed out > that > >>this proposal appears to have the following limitations: > >> > >> * The relationship between the zone (or internal) > and > >>the border (or domain) gatekeeper is not defined: is it hierarchical or > >>what? > > > >As described in section 2 of APC-1422 the only difference (in terms of > >protocol interactions) between a GK acting as 'border GK' and an > >'internal' GK is that fact that the border GKs may communicate with > >border > >GKs from other administrative domains. There are no specific models of > >deployment within an admistrative domain. Some organizaitons will > >choose > >to develop a hierachical model, others may choose to have a star > >topology, > >or perhaps a flat domain. It makes no difference to the signalling > >between > >administrative domains and the current signalling can facilitate all of > >these models. Can you offer any specific topologies that you believe > >will > >not work and cannot exploit this signalling? > > > >> * Does it mandates the use of proprietary > protocols > >>between the zone (or internal) and domain (or border) gatekeeper? > > > >It certainly does not _disallow_ proprietary protocols, but the intent > >would be to support standard messages internal to an adminstrative > >domain > >(which may be made up of a number of zones BTW...) as well as using > >these > >standard messages between administrative domains. > > > > > >> * The relationship between the multiple domain > >>gatekeepers has not been defined: how communications occur in view of > the > >>multiple domain gatekeepers? > > > >The definition of 'relationship' is multi-faceted. Many of the aspects > >of > >a 'relationship' may in fact be business related, and outside this > >realm. > >One of the points of annex G is to provide some signalling which will > >allow > >administrative domains (again an organizational term, not a formal > >H.323 > >topology term) to exchange information so that they can define the > >"relationship between the multiple domain..." > > > > > > > >> * As if it mandates a specific implementation > scheme > >>that may limit its scalability once one starts to use the gatekeeper > >>discovery, address translation, admission control, and/or bandwidth/QOS > >>control signaling messages for this particular architecture while a > large > >>network that may use highly distributive, centralized, and hybrid > inter-GK > >>architecture. > > > >I'm really not sure what you asking/saying here...can you clarify this? > > > >> > >>Therefore, Mr. Roy has the following view: > >> > >> * It requires a fundamental understanding of the > >>logical relationships for inter-GK communications in view of the > >>distributive, centralized, and hybrid inter-GK architecture that might > be > >>scaleable in view of large networks for both connectionless and > connection > >>oriented networking environment. > > > >I think you mixing a number of things here (some of which have no > >relevance). Can you break this up unto a number simple points - so > >that a > >simple person such as I can understand? :-) > > > > > >> * AT&T's contribution (APC-1382) has been the > first > >>step in that direction. > > > >You may note that a number of the definitions and clarificaitons from > >Yokuska to Cannes were a direct result of APC-1382 - thank you. > > > >> > >>------------------------------------------------------------------------ > ---- > >>------------------------------------------------------------------------ > ---- > >>--- > >> > >>I would appreciate a prompt action from your end. > >> > >>Sincerely, > >> > >>Radhika R. Roy > >>AT&T > >>Room 1K-330 > >>101 Crawfords Corner Road > >>Holmdel, NJ 07733 > >>Tel: +1 732 949 8657 > >>Fax: + 1 732 949 8569 > >>e-mail: rrroy(a)att.com > >> > >> > >>> ---------- > >>> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > >>> Reply To: Mailing list for parties associated with ITU-T Study > Group > >>> 16 > >>> Sent: Thursday, June 25, 1998 11:49 PM > >>> To: ITU-SG16(a)MAILBAG.INTEL.COM > >>> Subject: Report of the Cannes meeting > >>> > >>> Dear Q.12-14/16 experts, > >>> > >>> I have uploaded draft report of the Cannes meeting (APC-1425) at the > >>> /Incoming directory. > >>> > >>> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > >>> /APC-1425_w95.zip > >>> > >>> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > >>> with Word 97. w95 is a version converted into Word 6/95; there are > >>> obvious errors in section numbering and figures. > >>> > >>> Please review it in a week time, and give me any comments. I will then > >>> complete it, uploade it at /9806_Can directory and send its copies to > >>> the SG16 management. > >>> > >>> 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-503-264-8816(voice) Intel - Hillsboro, OR. > > *** > >*** mailto:jim.toga@intel.com mailto:james.toga@itu.ch > >*** > >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > >***************************************************** > > >

1 0

Re: Report of the Cannes meeting
by Pete Cordell 01 Jul '98

01 Jul '98

My understanding of the meeting was that APC-1422 was considered as good a place as any to start with a development, but there was acceptance that the final result may differ radically from what is in APC-1422, and we didn't want to preclude any other solution that we might find that was either already written, so somehow fitted our needs better than the framework that was out lined in APC-1422. It's my recollection that it was the view of the Intel delegates that this was a satisfactory situation. 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: Jim Toga[SMTP:jim.toga@INTEL.COM] >Sent: 29 June 1998 21:51 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Report of the Cannes meeting > >Dear Mr Roy, > >Although I was unable to attend the meeting in Cannes, I have read all >the >previous reports and have spoken to a number of people that attended. >There were many discussions during the meeting, which are summarized >in >the meeting report without re-hashing every detail. My understanding is >that there were no objections from _anyone_ else at the meeting to >progressing the work that has been started in APC-1422. The intent >will be >to have both telephone and email exchanges to further develop this >work. >I would look forward to having your constructive input as we move >forward. >In the spirit of this, I would like to elicit your input here. > >I would like to point out a couple of misconceptions you might have >based >upon the text below and ask you for some concrete proposals in areas >where >you feel they're needed... > >Best Regards, >jimt. > > >[SNIP] > >> >>Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) >> >>APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" >> >>Mr. Roy also pointed out the following: > >If these points were raised in the APC document and covered during the >meeting why do they need to be called out explicitly in the meeting >report? > The list of contributed documents is part of the meeting. > >> >> * H.323 signaling schemes that were developed for >>H.323v1 in view of the LAN-based single GK model > >Both v1 and v2 have never limited GK deployment to one entity (on the >LAN >or any other topology) The defined signalling for address resolution >allows for N gatekeepers. > >>(signaling schemes in >>H.323v2 also remain almost the same so far the inter-GK communication is >>concerned) may not be good enough to satisfy all needs when it is applied in >>the context of multiple gatekeeper environment with different inter-GK >>architectures: Distributive, Centralized, and Hybrid (Distributive + >>Centralized). > >(I think you mean 'Distributed' above) In any case, these different >modes >of operation define models with respect to _media_ distribution, not >control. In this case they would (and do) affect the operation of an >MCU. >(this is not to say that the MCU can't be co-located with the GK). > >V1 and V2 (and certainly the intent with V3) allow for many different >GK >topologies with hierarchical being one of the more general ones. Flat >peer-peer models may be accomplished by having a degenerative >'hiearchy' >with a depth of 1. > >> * Each inter-GK architecture may need different >>signaling schemes in order to optimize the use of communication resources >>especially in the context large networks for both connectionless and >>connection oriented networks. > >Can you eloborate on this? Are you simply saying that we need to allow >both UDP and TCP signalling (which is in fact specified in section 4 of >APC-1422). > > >> >>APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper >>Communications" >> >>During the discussion of Intel's contribution, Mr. Roy also pointed out that >>this proposal appears to have the following limitations: >> >> * The relationship between the zone (or internal) and >>the border (or domain) gatekeeper is not defined: is it hierarchical or >>what? > >As described in section 2 of APC-1422 the only difference (in terms of >protocol interactions) between a GK acting as 'border GK' and an >'internal' GK is that fact that the border GKs may communicate with >border >GKs from other administrative domains. There are no specific models of >deployment within an admistrative domain. Some organizaitons will >choose >to develop a hierachical model, others may choose to have a star >topology, >or perhaps a flat domain. It makes no difference to the signalling >between >administrative domains and the current signalling can facilitate all of >these models. Can you offer any specific topologies that you believe >will >not work and cannot exploit this signalling? > >> * Does it mandates the use of proprietary protocols >>between the zone (or internal) and domain (or border) gatekeeper? > >It certainly does not _disallow_ proprietary protocols, but the intent >would be to support standard messages internal to an adminstrative >domain >(which may be made up of a number of zones BTW...) as well as using >these >standard messages between administrative domains. > > >> * The relationship between the multiple domain >>gatekeepers has not been defined: how communications occur in view of the >>multiple domain gatekeepers? > >The definition of 'relationship' is multi-faceted. Many of the aspects >of >a 'relationship' may in fact be business related, and outside this >realm. >One of the points of annex G is to provide some signalling which will >allow >administrative domains (again an organizational term, not a formal >H.323 >topology term) to exchange information so that they can define the >"relationship between the multiple domain..." > > > >> * As if it mandates a specific implementation scheme >>that may limit its scalability once one starts to use the gatekeeper >>discovery, address translation, admission control, and/or bandwidth/QOS >>control signaling messages for this particular architecture while a large >>network that may use highly distributive, centralized, and hybrid inter-GK >>architecture. > >I'm really not sure what you asking/saying here...can you clarify this? > >> >>Therefore, Mr. Roy has the following view: >> >> * It requires a fundamental understanding of the >>logical relationships for inter-GK communications in view of the >>distributive, centralized, and hybrid inter-GK architecture that might be >>scaleable in view of large networks for both connectionless and connection >>oriented networking environment. > >I think you mixing a number of things here (some of which have no >relevance). Can you break this up unto a number simple points - so >that a >simple person such as I can understand? :-) > > >> * AT&T's contribution (APC-1382) has been the first >>step in that direction. > >You may note that a number of the definitions and clarificaitons from >Yokuska to Cannes were a direct result of APC-1382 - thank you. > >> >>---------------------------------------------------------------------------- >>---------------------------------------------------------------------------- >>--- >> >>I would appreciate a prompt action from your end. >> >>Sincerely, >> >>Radhika R. Roy >>AT&T >>Room 1K-330 >>101 Crawfords Corner Road >>Holmdel, NJ 07733 >>Tel: +1 732 949 8657 >>Fax: + 1 732 949 8569 >>e-mail: rrroy(a)att.com >> >> >>> ---------- >>> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] >>> Reply To: Mailing list for parties associated with ITU-T Study Group >>> 16 >>> Sent: Thursday, June 25, 1998 11:49 PM >>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>> Subject: Report of the Cannes meeting >>> >>> Dear Q.12-14/16 experts, >>> >>> I have uploaded draft report of the Cannes meeting (APC-1425) at the >>> /Incoming directory. >>> >>> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip >>> /APC-1425_w95.zip >>> >>> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) >>> with Word 97. w95 is a version converted into Word 6/95; there are >>> obvious errors in section numbering and figures. >>> >>> Please review it in a week time, and give me any comments. I will then >>> complete it, uploade it at /9806_Can directory and send its copies to >>> the SG16 management. >>> >>> 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-503-264-8816(voice) Intel - Hillsboro, OR. > *** >*** mailto:jim.toga@intel.com mailto:james.toga@itu.ch >*** >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** >***************************************************** >

1 0