- sg16-avd - lists.packetizer.com

Re: H.320
by Toby Nixon 31 Oct '97

31 Oct '97

These standards are available from the ITU, either in paper or electronic form. Ordering information is available on http://www.itu.int/publications/bookshop.htm and http://www.itu.int/publications/online.htm. Pre-publication drafts of SOME documents are available on ftp://standards.pictel.com/avc-site, but these are not indexed for easy reference but those not actively participating in SG16 work, and may be different in technically significant ways from the published text. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com > -----Original Message----- > From: Abdur Rafay Badar [SMTP:rafay@THEOFFICE.NET] > Sent: Friday, October 31, 1997 3:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.320 > > Hello, > > Can you plase send me all technical information about H.320 and other > including the G. standerds for voice. > > I will really appreciate you help on this. > > Regards. > Rafay Badar

1 0

H.320
by Abdur Rafay Badar 31 Oct '97

31 Oct '97

Hello, Can you plase send me all technical information about H.320 and other including the G. standerds for voice. I will really appreciate you help on this. Regards. Rafay Badar

1 0

Re: H.Chat vs. T.Chat
by Gunnar Hellstrom 30 Oct '97

30 Oct '97

Toby Nixon asks if there really is a need for a simple logical channel approach for text chatting with T.140 in H.323, or if we could do with the T.120-based T.134 solution for all H.323 implementations. If you remember how this started in March in Geneva, I came in with the view that the T.120 solution for text conversation would mean maximum compatibility for least work. However, first recations came from the H.324 side, asking for a simple solution in a logical channel. Then, in the Herliza meeting, apparently text chatting was discussed in a group that was aiming at the simple Internet Phone applications, who said that there should be a similar solution in H.323 if I wanted full coverage in H.323 products. I agree that it complicates the implementations to have T.120 as the solution to invoke if we turn out to enter a multipoint situation, and otherwise use plain H.323 data channel for point-to-point. It is easy for Toby to say that T.120 should be the base. He usually has enough power and memory around. I would like to get the view from Internet Phone people as well. If this is the text telephone of the future, it should be suiable to attach to any implementation of voice and video telephony. On H.320 dedicated simple videophones, it seems to be common to have a connector that can be used for T.120 application attachment. Can that be the way to add T.120 to Internet phones also? A summary of Sunriver activities in the text chat area: -A general purpose character by character text chat protocol based on Unicode was determined, named T.140. -A way to carry T.140 in a simple T.120 APE was determined, named T.134. -A way to carry T.140 in a simlpe H.324 logical channel was edited into H.324 and H.245. -V.18 - the PSTN text telephone modem - was changed to point at T.140 instead of having its own presentation layer. -Work was initiated to define a way to carry T.140 in a simple data channel in H.323 - H.245 - H.225.0 If you want to take a look at T.140 and T.134, they are available in http://www.pi.se/~omnitor/standd.htm Can all H.323 producers have room for T.120LITE and T.134 ? Best regards Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------

1 0

None
by Steve Auer 30 Oct '97

30 Oct '97

My name is Steve Auer and I work at VTEL Corporation in San Jose, CA. My email ID is "sauer(a)vtel.com." A predecessor of mine, Charlie Sauer, who no longer works at VTEL, used the same email ID - - "sauer(a)vtel.com." I continue to receive mountains of unsolicited email of all types on a daily basis, which are meant for Mr. Sauer. He's told me that he has already resubscribed to his areas of interest under his new email accounts. Please remove me from your mail lists. Thank you, Steve Auer (a.k.a. "sauer(a)vtel.com")

1 0

Re: Minor H.225.0 Corrections
by Lior Moscovici 30 Oct '97

30 Oct '97

Some more corrections: The needResponse field in IRR should be OPTIONAL. The reason is that the field is completely irrelevant to IRR that is a response to IRQ. We propose to say that the field shall (may?) be included only in unsolicited IRRs, and thus its presence can indicate it is an unsolicited IRR. After a closer look we found that the altGkIspermanent is mandatory also in ARJ, BRJ, DRJ and LRJ, but optional in GRJ, RRJ and URJ. We think it should be optional in all, and appear only if the alternateGatekeeper field is also present, but in any case, the optionality has to be consistent throughout. The integrity field in GCF is defined to be a SEQUENCE OF IntegrityMechanism. It seems the intent was a single IntegrityMechanism, not a SEQUENCE, namely the one chosen by the gatekeeper. Is it so? Lior -------- On 10/28/97 02:28 PM MST ggf(a)lucent.com wrote: Lior, Thanks for the note. In addition, I have the following corrections: TimeToLive should be INTEGER(1..4294967295) instead of 4294967296. With the addition in V2 of supplementary services, fast call setup, and other items, the length of the User-user IE specified in the tables for each of the various Q.931 messages should be extended from 2-131 to something larger (any suggestions?). The callReferenceValue definition (at least in ARQ) should be modified to remove the statement that the CRV comes from the Q.931 message. If you find other needed corrections, please let me know. Glen Lior Moscovici wrote: > > There are two corrections we would like to suggest in H.225.0: > In the Endpoint structure: "destinationInfo" field should be > "remoteExtensionInfo". This was our original intent in the Sunriver > contribution, but we had a typo, we ourselves overlooked. We apologize > for the incovenience. The change has to be reflected in the ASN.1 > section. > In the INAK PDU the field altGkIsPermanent should be OPTIONAL, as it is > in all other reject PDUs. > > Sincerely, > > Lior Moscovici -- 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: Minor H.225.0 Corrections
by Karl Klaghofer 30 Oct '97

30 Oct '97

Glen, I can not even imagine that the 131 as a max. size for UUIE was suitable for H.225.0V1 - was it ? (thinking on the various arguments with its sequences of alias addresses, etc.) The number 131 comes from the max. length definition of UUIE out of ISDN UU Service 2 and 3. I agree that we have to extend it in H.225.0V2. Karl ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ================================================== Lior, Thanks for the note. In addition, I have the following corrections: TimeToLive should be INTEGER(1..4294967295) instead of 4294967296. With the addition in V2 of supplementary services, fast call setup, and other items, the length of the User-user IE specified in the tables for each of the various Q.931 messages should be extended from 2-131 to something larger (any suggestions?). The callReferenceValue definition (at least in ARQ) should be modified to remove the statement that the CRV comes from the Q.931 message. If you find other needed corrections, please let me know. Glen Lior Moscovici wrote: > > There are two corrections we would like to suggest in H.225.0: > In the Endpoint structure: "destinationInfo" field should be > "remoteExtensionInfo". This was our original intent in the Sunriver > contribution, but we had a typo, we ourselves overlooked. We apologize > for the incovenience. The change has to be reflected in the ASN.1 > section. > In the INAK PDU the field altGkIsPermanent should be OPTIONAL, as it is > in all other reject PDUs. > > Sincerely, > > Lior Moscovici -- 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

H.Chat vs. T.Chat: what is best for H.323?
by Toby Nixon 29 Oct '97

29 Oct '97

Many of you will recall that at the Sunriver meeting I volunteered as editor for "H.chat", the carrying of T.140 text chat over H.323. I've recently found the bandwidth to do some thinking on this, and would like to raise some issues with the group. "H.chat", as I understand it, would describe protocols and procedures for running T.140 "raw" on its own logical channel (negotiated via H.245), rather than over T.120 using the application protocol entity described in draft T.134. At first glance, it can appear that running T.140 directly on a TCP channel is simple and easy to implement, and that's probably true in the trivial point-to-point case. However, as soon as you start expanding to multipoint chat (which should be a requirement for T.140 over H.323), quite a lot of complexity is introduced, and before long you find that you're duplicating most of the functionality already provided by T.125 MCS. > Our primary concern is that if there are two (or more) ways to > implement T.140 text chatting in H.323 terminals, some implementers > will do one, and some will do the other. The result will be that at > least some portion of the users will not be able to engage in T.140 > chats with some other portion of the users. This would not be a > desirable outcome of our efforts, the goal of which is to replace > (over time) the variety of incompatible text telephone conventions > around the would with a single worldwide interoperable standard that > works over a variety of transports. Furthermore, we fear that if ITU > defines a "simpler" protocol for one data application, we'll set a > precedent that could result in demands for similar accommodation of > other data applications (such as file transfer), further dividing the > market and reducing interoperability. Why do we want to torpedo T.120 > after putting so much effort into it? Shouldn't we endeavor to > specify a single T.140 chat architecture in each H-series system, so > as to maximize interoperability and minimize the complexity of > gateways between various H-series systems? T.140 is about the purest > "data conferencing" application there is; why not use ITU's standard > data conferencing architecture as a transport? > There have been arguments against mandating T.120 by some H.323 implementers in the past, particularly in the context of T.130 discussions. However, the issue there was that some H.323 products, such as standalone phones, would need NO data capability, and they didn't want to have to implement T.120 just to participate in T.130 conference control. However, Microsoft believes that H.323 terminals that implement T.140 will be more capable devices with adequate resources to implement T.120 and fully participate in multipoint data conferences; the resource issue is not compelling. > It probably makes some sense to be able to carry T.140 directly on an > H.223 channel in H.324, since H.324 devices are fundamentally > point-to-point. But this doesn't carry over to H.323 systems, which > live in a fundamentally multipoint environment. Gateways from H.324 to > H.323 are going to have to be relatively complex anyway, and a > commercially successful gateway will require T.120 support. Adapting > T.140 on H.223 into T.140 on T.120 should not be a significant burden > to such a system. > So what are the compelling motivations for developing a standard for carrying T.140 directly on an H.323 logical channel opened using H.245, rather than within the context of T.120? In other words, why do we need H.chat when we have T.chat? -- Toby > ___________________________________________________________ > Toby Nixon, Program Manager - NetMeeting > http://www.microsoft.com/netmeeting > Microsoft Corporation, Applications and Internet Client Group, Redmond > WA USA > +1 (425) 936-2792 Fax: +1 (425) 936-7329 > mailto:tnixon@microsoft.com >

1 0

Minor H.225.0 Corrections
by Lior Moscovici 28 Oct '97

28 Oct '97

There are two corrections we would like to suggest in H.225.0: In the Endpoint structure: "destinationInfo" field should be "remoteExtensionInfo". This was our original intent in the Sunriver contribution, but we had a typo, we ourselves overlooked. We apologize for the incovenience. The change has to be reflected in the ASN.1 section. In the INAK PDU the field altGkIsPermanent should be OPTIONAL, as it is in all other reject PDUs. Sincerely, Lior Moscovici

2 1

List hiccup....
by Jim Toga 28 Oct '97

28 Oct '97

Greetings, I'm aware that there is something strange going on with the listserver - I'm checking into it. I will post again when it is identified and/or resolved..... Regards, jimt. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 1

Fellow MS Outlook users.
by Ryan Holmqvist 28 Oct '97

28 Oct '97

Fellow MS Outlook users, When posting to reflectors with MS Outlook, *please* make sure that you turn off Tools:Options:Sending:TrackingOptions. When these are turned on, my MS Outlook *automatically* replies to the reflector when I read your email. This explains the unreadable attachments some of you have been indirectly getting from me. If anyone knows how I can make my MS Outlook not respond to people's email, please let me know. I feel guilty wasting valuable internet bandwidth that could be used to read the Dilbert Web Site ;-) Thanks, Ryan -------------------------------------------- Ryan Holmqvist Lucent Technologies (Bell Labs Innovations) Voice: (610)709-1161 Fax: (610)709-1076 Lab: (610)709-1083 email: ryanh(a)lucent.com --------------------------------------------

1 0

Read: H.245 v1 and v2 will not interoperate
by Ryan Holmqvist 27 Oct '97

27 Oct '97

1 0

Delivered: cc:Mail SMTPLINK Undeliverable Message
by Postmaster 27 Oct '97

27 Oct '97

Your message To: ITU-SG16(a)mailbag.jf.intel.com Subject: cc:Mail SMTPLINK Undeliverable Message Sent: 10/13/97 15:12:16 PM was delivered to the following recipient(s): Phillippy, John D. on 10/27/97 13:28:44 PM

1 0

Re: Registering gateway resources
by Mark Reid 24 Oct '97

24 Oct '97

Hi, The original proposal for that capability set had a "number of calls" field per data rate. During one of the evening sessions it was argued that given the complexity of gateway resources (e.g. DSP's for transcoding and the varying call capacity based on 384 or 128 calls), that the number of calls would not be included because the number of calls would be changing dynamically and no matter what structure was chosen to represent the caps, the race condition between the GK and the GW could not be fixed. Instead, the capabilities simply notify the GK that the GW is willing to accept calls of that rate. The GK is not told how many. When a GW runs out of capacity (for whatever reason) for a particular call type it can send a ResourcesAvailable 225 RAS message which no longer has that data rate included. When the GW is again available for calls of that rate, it sends the message again with that rate included. So for your questions, a gateway which can do calls at 384K or 128K would register with 64K and a multiplier of 2 and 384K with a multiplier of 1 assuming it is bonding itself. If at some point the number 2B calls rendered it without the capability to accept a 384K call, it would send a resourceAvailable message to the GK with only the 64K-2 capability (assuming it could still accept that type of call) Mark >10 instances of H.320 dataRatesSupported indicating channel rates of 64K and channel multipliers of 2,1 instance of H.320 dataRatesSupported with channel rates of 128K and channel multiplier of 10? channelrate=64, multiplier 2 (No information on max number of calls) channel rate=384, multiplier 1 The former isn't that scaleable for large systems with 100s of ports, but does allow a gatekeeper to know that it might need two E.164 numbers to make the connections. As a side question, how do you signal that you have 10 384k channels that can also be used as 30 128k channels? 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

Registering gateway resources
by Pete Cordell 24 Oct '97

24 Oct '97

Dear All, When I register a gateway I have the opportunity to register a list of base channel rates and a channel multiplier. If I have a gateway that has 10 2B H.320 interfaces, assuming I want to register the ports in the same message, do I register it as: 10 instances of H.320 dataRatesSupported indicating channel rates of 64K and channel multipliers of 2, 1 instance of H.320 dataRatesSupported with channel rates of 128K and channel multiplier of 10? The former isn't that scaleable for large systems with 100s of ports, but does allow a gatekeeper to know that it might need two E.164 numbers to make the connections. As a side question, how do you signal that you have 10 384k channels that can also be used as 30 128k channels? 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

Revision of APC-1327
by Sakae Okubo 24 Oct '97

24 Oct '97

Dear Q.12-14/16 experts, To send the Sunriver meeting report to Mr. Tosco and others, I have reviewed APC-1327 and found some editorial errors. The refined version is now available at the ftp site as /9709_Sun/APC-1327.zip which has change marks against the previous version. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

GCL ftp site is working again
by Sakae Okubo 21 Oct '97

21 Oct '97

Dear Q.12-14/16 experts, Please be advise that the GCL ftp site ftp://itu-t:sg15!avc@ftp.gctech.co.jp/ has resumed its operation after the maitenance. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Temporary shut-down of the GCL ftp site
by Sakae Okubo 17 Oct '97

17 Oct '97

Dear SG16 colleagues, GCL ftp site (ftp.gctech.co.jp) for Q.12-14/16 activities will be closed from around 20 o'clock of Friday 17 October to the evening of Tuesday 21 October (Tokyo time) due to loss of electric power and maintenance of the server machine. In the meantime, please access to the mirror site: ftp://standard.pictel.com/avc-site/ Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

White contribution for correcting H.310
by Sakae Okubo 15 Oct '97

15 Oct '97

Dear Q.12-14/16 experts, Attached please find the draft white contribution for correcting H.320/H.321 stack of H.310 RAST-5 terminals (zipped Mac Word 6 file). The same file is also available at the Incoming directory of the GCL ftp site. I have modified APC-1300 of the Sunriver Q.12-14/16 Rapporteur meeting and subsequently TD-23 of WP1&2/16 meeting based on the comments from Mr. Sakai, Editor of H.310 Version 2, which are only comments I have received in response to my request dated 25 September. As agreed in Sunriver, this correction is to H.310 Version 1, hence forward referencing to H.321 Version 2 (Annexes A and B) is not appropriate. The listed changes are kept minimum. Other useful clarifications and enhancements contained in the Sunriver documents will be covered by H.310 Version 2 which is to be determined at the next SG16 meeting in January - February 1997. Since I intend to send this white contribution to Geneva by 17:00 Friday (Tokyo time), please review this draft and return your advice, if any, by that time. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** begin 664 H310_cor.zip M4$L#!!0 ( !NS3R,$(!FN:30 "Z , ! 2#,Q,%]C;W(N9&]C55@, M ";$1#0FQ$0TKA%X .Q::VP;5W:^PY$\EN,1'3_B<%>KF;X2.Y%HD7I85A73 MLDS;2BS)D:BDN^V/'9$C:6**9/FPZ5W#8AJT 19HTZ#]D6"W:Q=8V\WNHD51 M8($B!3K&_DC_I3^*!;8HNG03P$5_;.(a)$J.E8XO0[]\Z0%"7YL4&!76#'..;P M^^[CW'///>>,AO_ZX9/EO_[[+]UB+=?O,IG5G ZVK0F37.'7+L9\[O>:XS@> M[/SZ^I6ZUB!1=P]/XK,=0GNN0+9#.B [($] =D)42"?$+UR /0G9#=D#V0O9 M!WD*LA_R-"0 ^1+DRY NR%<@W1 -HD-^ _*;D-^"_#;D=R#/0)Z%'( <A#P' M>1[2 ^F%!"&'('V0$"0,Z8<,0 8A0Y##D&'($<@(]V?&1B$O0(Y"(I!CD#'( M<<@XY 3DE&L+DM.XGX"\"'D)<@8R"9F"3$/.0EZ&S$!F(3'('.05R*N0WX-\ M%?(UR.^[X_ZR76SFB_7WP6.\>YD"0(>/QP%;A(.3S3&!?>7;?_FCG_Z31.UL MG\ E6#[-EED&%IUGKSUV!-G-?-+#VK!-KC]P9WH5LV=9 GN?9G%6@"8F2['\ M(^OQ)7?^M@?T:)V;VG;_0+07JS8Q=Q[^E,:_Y&/9X"DF212#?6ZOS=9:^A,? MM[OWV=S?B]^RJ]=6Y_^7T7=_?7WQ2\+.^I#%Z;[U[%*\GK3BV70NO9#77TUG M$_I0L$\_D8X7ELU4GOO$U/&A5RD/$!OTF."0& %%A%-CZXN(=67$+HS!F+Q# M8JT7(9]>^>/R]+U=2S]X>SM[_ME_^"G%^XHD<@_YYSNNW]]R?7=2$CYK2*)_ M01(YZYN2R%]O2B)__84[QA5)Y+ ;DO#QOY-$+GM?$CGN)Y+P__^41'[[;ZE% M^::32CF-<DGT](G>P9$SXX.'!X^?*V1&QC*9I!4W\E8ZE1O9:,R1F+F<21IY M,S<RE<XN&TF>'!.0\24CM6CF])09-W,Y(WM17TAG]7@ZFS7C>2NUJ.>73/UT ML#_<=XC^#^E6*F]FTQDSRR?3<WDC?H[W<1N&^O29L=E8[Z".=LM62LSU']>6 MV)C=T4:6,SW+2_B'@/#U@(A3K=?[2/)O,V&3+:_O,795:GQ>O29L_/UK8D]V M7A?-FC^I?CCO?G_0)_7_H^NBSGCGNLBS'O]O[S&^CKTWQ'?ZI';/N=\W^R1? M"MT0X[YP0_C0#]\3OO6W[XEVC_))=<N1[PM]WL;GG[KZ;'9YZX[>\) QY" 9 M?M>J8>OE]? ^O1F\[ZV6W6J<RG51<;6.U_K9.D[K]Q]NL4+]NJCPCET7%=F/ MKHGO/[DFOK?J&6T9C[XO^IHM]/]QJ1-3L>C,U%AL8GIJ[(P>BYZ)CD]/3LY- M38QS3,?=])2":P/UQ&QL;.K$V,R)B:^)IK/1\=CTC#H;FSOQ5?UL=&9B^H0> M.G+DL-X;[NOK4]!9#PWUZN[5&U6GX_GTO)GEC=3IK+5(IW)$CZ86DU9N25$D M%=?+!3/'3W0H?"@TI+K#GYJ9GCN+X?1>?7QZ*C8S<7R.= ]/3<S'GU.OSJB MS!B93#J;-PM9'@=>#O(1L)*)V)DH^+,STV>G9Z,G,,+,#'2G-4R?U&?X,J-8 M&D?<T!$]12N=.J7'3D?7Q1UNP&DL5S2?G#X1U6&9\9?X6"+BH,7D!.P[JRAJ M[V:7JH:"'1.Y7,%4U8D4#UGQ="&;,_7T D)9(7'1"WE6*IXLY,@>8,;&S@SJ MF6QZP4H2HPN-7C&SO$&X1[?R^I*1T^=-,Z4C<*874]8WS 0&,O)\-%@HFS;B M2WH^_;" NIQ.\#EF,,PRLEQ"P,(\5HX40XRW<GDD0$R8OT!S\O6'=".5: V^ M.0[6%8D7$-C1T6W5'+WYV)NHDL/2D$6@.:<OI+/G] M6?FG=(NK3!?48C90P M%Y _]-Q2NI!,0$TOHYB)H*J&@QVSZ62!YH#?P5UZ0P/P&+W)D99-D[)/CEO; MS.:_D;0,_<"+A93)O?@@7Q6XV4(J:YV';Q^8-3-Y<]ES\X-ZPLK%"[D<=B%G MHH&1U(TDM$QA:>>1[["<!:LHENTJ2T-F3>P2WSE2N>X#=?L];..$0>$RFV;" M)GL8?&DGK<5"UM3G#$J*HZA^[WWH?-L-8.J]L.X&3-N+5AQ/>XF]X;7H4?> M+.95]2Q&3)-UO#8&YEV$:5*DUU@J919%-]@'ALAGK7F^8:0HSJRZDS?!E\:@ M]:$:M01&<#?^T>H(+(O:;5@4'=L9$Q5,W/1L%A9.2,T7TLED^@+<980;D?L7 M52\8=B@8ZM%3Z;PP@M=556/-W=P&\+[D1<]626/>3,(\F304;=ZK,"P0Y)>J M#AWL.!T,TV)R$P_+%A9DWME2RD$%=P5U0]HZ)GF(TH'L'ZX2*$'G*_&[+35 M+4;IW](H)R=.S<U$]?Y#7"_:_GPZGDX*NPL-Q-%P%2=-'[!=%)L**;?BY"Z9 M@T(#S88/!Q$8X3^('4DCE]<S1M98S!J9I<8*8EN5C'JNP$-!CH?>H#Z!.U>] MC3/K;D#,B5,1#H>#(6&'4\'#(1@?V!!T$4L*#PS2X>-1N9"PTCWZ>2MAICG+ M'1U&R;C6R8F9'W88"SDS5Y]8.(2[@309_1^N#RV"#'<5>)R^B)K\@B&*;BR5 MFIT7:24HM/>T'@H)=?EW5V-LN&LGD\=GXWS:PDW62.7BZ03YD1NUW%F">I/S M# 8[8L8\\MD ]F'L^)FH/N#ZQA22"@7YL821R8MECAL98]Y*6GG+S#5B3\QS M2E51'M))\2ZOCQZ[F#$59;*0S%O+9L(R5'Z;29I%12%+P"+J&*WXO)4KH/T) M(V]@F@(/\>D%=2PVJ;\RCH%CM-X%@#-8I7K@W+R5/Y0[R">;-"A]IK,7E>D, MJ60D?W&H^1+>JBKJE/!)\@+%<X#8;/WV["PMI7>0_Q]2PLI1/:P,A08&U"-A MU%A*ZKFA 0RG"@<+M8ZC<E]J&DWM=<?K=<<ZKH:/JZ?[,%+QN)HJXNYT* 0) MNSHBS&RII=JJ9DCE@ZOUT>N:/IJBZD9--PSY (4[IJ9C4:2^DXUGR:U.'3QP MLX!*B8LJ-=*NAX^1]WP#'<UZM<09SP]%>50_(R+5BV.8YTE#'&@O>%#:228I M8U 6-XM&/(^D8>C+KO>2;D,#NO!"/5$P:8B$M0 EJ.Y*8]@ETTB(PL8UESMV M.$3%$]1$-4GZYKQ4DN?GU'W&1JT:-RC@9$U:F)NNT">71_&R+):\;.4I)J1% M_TQA/HEJ("6.*!W^H>9 W1\<H"RY59 >PW+GK=Z$E14]8#,OYWOYRRS&47UM M+#US2T:R'LOUB=A<;VQC74O6?4 "K&>B=44F.4GK=#U;I=<+2]CT=2.3F_0T MA5_7T"@8\^EE6#63-9<M6-HUF;N0>1[J>:A=-%,F]RGAJ;0&SP.*3;[B1?UE MJH=0&L&<GIO/I1YL4XKNY&7UN@*S>I;<9%):6MP+N!=ICP^W[C%2(+E703SM M4(S-(P;K,,1K6+=N+.1-<?+R5CYIBNR\H;&J/KB46;_E/,LV,H*;GYO4QKJ, MIB /IS#($=(ZA7?4WN[3&(\B^NS8#)]V_.SXK+Y02/'%T?9:>+(B>Z&0MU*B M!)L(]@_U!P?=QQ%^9LT4/T?BZ:[)U[RPL+[P65]SS4QCS2CCIOEZ>_19\7W6 M^RZ,LJ4'/HI5*!(TVZ5^I'.M%FGL1G,U..PE]$$OH0^Z"7W66H062>KZ\$2^ M1>-UR5OAR7LN9V9[\^E>^FR:0ZD3;DVPCGODK+P^URHM.6Q@4#DQ.]D[/J[/ MS2DO!\-'^D-U@/Z,TIJH!@95?B)AD7!_']*1VZ>WD2B_\!3NX*KHVSR%JAY9 M?QC#0?A*#I$0[O*+A=R'A]:<&X/<:-3?]ZL?91\<43?]R\=C*,KQQ[!/3\LF MB')?_/F\^1FE_DCVB':@PQSJ:SA,B#])S6[N+7"61,(23I*\V/,XCY+8&FA/ M!FI40Q16-@M7C6=E_JP7?%BN%X5*(T9CR0_U@UR3 0[$W4?K0WS;>\7).I X MV!$ZWJ.'CXO]Z&L4>.(1](!YL"-V0<1*/!SH!\@<KDY>+D'G39XA&V8ZV!13 MZ2\=SXW#Y5#FC73,&N<,4Y]^:>[X=$?,3 9'].>'0WCF'NP?#.E]H>&0VG&* MML:*Y_3Q=5.<,>;360IPB*0=)XUB:\\!M2.6/G<1#Z,O(N:F.J*]RX:5'-'3 MYPKSZ6.+\;P97PK&T\'7,E"J5]?WZ&?'3D7UO8/[=+V7_GK;Q?Z,O;O].[=\ M?W7+][U+P6O_,G;]6^TWOM7^-_\HO_?MMDOTLH%>O9YF]&,#)@=](\ZGSJ?R MJ"\JGVK_IESF+R%<UO?OO@/\Y1.]'Y+XBU^'2<_Z^?N:INOKVUE ^O.6/W1O M>,66, [LIM]&;&>[MKVRK97-R._(_]7V=/OF?S67Z+V8/,OO]];_?V:;GW7S M-V)M_#N]Y.IL>8/8Z;;;S5G'H7<M]/KOXUWBW?,3_!4DW>WT76V_VD[O9K[< M1G<>OK?>8@]O(3#B!<;8U7;ZU4EXQS%VC+_A0-JKOW"+ZW \>N'&*_3&)7J4 M)-'CO&5>T">-..7WW)*>L>+Y0M8,ZLT7_[4#V_4Q_PBR'O:DS]FY_AU\#Q,_ M5J&K&T;;46_[#O]Q#+UJ?7_=)W%2V_\P%J#_M.TU[,3/FVX"=%/TD-'F&TYU M>XA&-YVX\=^G7RB4[Z+!DS4F^4MKC"DUAU6K:$"(4D(K:=5A]CT@>PBQ:VR; MXI28Y-2 !?8"D\OX3ZO4F$]S2I^[#3GH8$1,0-CN&FN7*IBSMHJ9:H ">PC" M5"O55>93'/L^-5MC;6C@5 #)MRL-2%XC2"I7 04(NLS\-\O4JG*96NWA4$2V MT52K1/#!M+W 5EA5MO$I.XZ,$5A@WQJ3(V]4L,YM-O,[SJVJVU36WK3]:TY[ M*<(BU4MU\)/2"D TTAR-^C^UQCK]CNS8](*WROS:AQB>:32LLKI26V/;L,N* M\E&YCJXYA,)H"JM4UEP5%*<Z"E1VJG+I4M%KZW=*'+WIR"7MJ(=J#N-H2;ME M^]]:$TK(*PX;7F.*7)+OV?('M%,:P8X',Z<L?603O+_&VJ2J4^*XS2)E=@>[ MPP*$RY45V\6U"G;>:Z^4(QR7;+@$<U;KN*V5@<L<=]BJ-XZ_I%6:\!JUAW.T M:<Q?Q?*P<\JJXPURE"FK )^0'&=5*_L_*+F#7&)R3> UII7E-VRW/7E$E>.D MI7P3?J0]C>,/[Q&$'P?+7Y5L>%. "!DWG%@A-^^6RHBF6@"$4B%_J[&=4NTH MOBFL/-K$1(A1*GY&]BMW8S!B_!ZCV4J)*:_;E4ZWCT:*P 0[:PSV0Y<,@8'] MC&P,5^>*(%#+I6(&&Q(@Y@4P"M15R(a)SG02Z-9LCTQ%SD3(GY80XLS.[,2,3L M$ QY7*3&.BZ!42I2&:.!N0,&)XSVH2,"1JZP"OK(3+J%K9>=BHQSV>&W-S K M53K*'="B#*8(L\E,O@G(M[+J7V,=,"T1P]@ $*\3$7&.KK+M*Z6R4F6C'%<X M[G=P.K9KE0K.1S<V4B:OJ=&1QH';#AV<[P+7GI*9W\7+][%0I];).CG<S6$T M!!QQJG[FAX=W "XS!6O D5?@@PK.C[:OG74!]I/K?<ZVK1):(G3411%9MA6Q M&W(IL*>=%6F(-0?8,)/*LDTMBPP;LN:PTGU"65GB: :H!-06*$P? $HV8T#+ M L5PVCZ)T2'6,%=%H*.LK.U1,%/$<7Y6JG*LC54"^SWLGU>='3;6.ZPY_\LR MV@:\JXYCOQWG+1=?!7Z793".S".5G^,K3K5+<7Y<*FH<5YR:P#6GTB4!'R:\ M!+.M-N-OV*,81VG!F?.Z/:IYN!9IPLL-_&@37BIWT3CDCJO%9KS2I3V]7>"( MOFL-(M,-Y_83L5:.?'?%*?L;3,!C[$ADQ?GDML<4C];[E(ZN@/G,8X;KS"H[ MZH"Y[S&CEP-U9I28>Q[3=1E]-,&\ .9VG>FNK6?(%P3C=P)U1B(&.^XR=[6M MF-L-AJUCE \"ZYB?-S%-?6BE#>;-*V!*@H%U;I-O5$9IGC??;3#:BO-1A9AA M,%IS'S"W5CTFTLSXH=N*QZQ\@-$B+J. T6S!O/[9!U<:C 1&J0CFC5M@VB,V M,376"4:N">:MF[??7<\PYV><N2+=;NG#-# 9YGQ',.4F1A9,2;J+T5YH9DAK M8MC=*X_#W''N$8/1NBKD50WFKK,F^NP7#%+..L8A)L.]M\[<J4C$P&Y=1>[P MQ'S,-2@3LZ)Y3)$8OMMW&LPP,:/$\-V^8W,&'M(U2DPW9VS.R&#(>[N[^,'E M3-EE&&<ZNXG!006#:L2Y5Z+D0F=!, @18%;!5 5#??S$( B!J8%!LJTU,PAZ M8.""J"4B-3&:7RD14^0,9G=L\HK+VM.=?IDSHV!N(]^L.4C7[!((A"<B-$Y4 M$5S;D)4O!4 @@V%2?PF^BP8@*M0CX$=@1)Q#]':P8PY;J3EM99<IE1$92Q+@ MZ@K<&8S-!P-302RUV6<(F!%X;PTC2T4ML%LN93AQ&!%60U9QR"$$8Q<YLQ^, M'R9R'"I6BX'=/MD>K;)VJJ$T5 ]2!4E.LKO[UMAV*E11KMC'J):I(&M)Y>X, M%EJC7.I4RQP.$.RG,A-FDR/.*DI#GURF',=A1:.*!J, 5CA<40A6J%J %H#] M-@;!(Q;!-"=@I!L?#N4^P!*EG,L<A7Z^B*WME9&5@,HXW+ *0*<40--ARDX^ M% IK5.=B5TLTP"BK4LV/#.]LHV+\$Q3.,NNB7,H0S;>1YA^BOD9.%MA]!T]. M#K+W;OK]&97M*X!*TJJ _)*#XEO^W&FW-<2FP)XV:'V[1)&$,,=&G4#8ZS^F M@IS:?5B##VF[VU!34/G.I'NT^Z@_"+II4\6_\CG]9+K">Z)8*=X7>M@<VPOJ MECT*S+_*5T:5T#Z =^QN@ JE\!HO0S6!^N^+AQK4X#)56GO_C[UK@8ZB2M/_ M3:<?(2\") 8D(72"=-(AD" (R$ "$F$61B"@J AB0$"1=S0@2"*S"CJ*CAX= M4$(a)B.K.CL[YQ]< R"@(N(HHH B(/\0FHD6<(D.SWWZI.OZI)=77I'L].]_ER M;]V^[_L_J^ZM8$!WPY [Q_M+Z]@2AV$&54_]W[9 S6,Q><(MB22-#:3R1&(M M><(M'=14K".Z96&:0FH_4FI(?)O0,0O(AQMCD[,54NUHM)YX:2SE;*/#GV:] M7:&T!;L=9A;L'9L<"G>A!1H[**_06 /;C]R%%DP)LJB2BGA?)1548F<+FE/1 M J;!AM0&Q0#MD +[&<(FD1>E V_HI71/<CI;H>?)ELXD27W9E$^1ICSL3R3W MLG,_RCVY[2P:D0SAAR9K.3D5'AQW+Q&CL$MY JDB/0)X7+5L4S<H'D=C@UWQ M1& Y<84+D(YFT$"5=%S@Y5 _I$';\/$/P;,EO1R63-&)!^6O48MX7J67X^ ^ M,GOTDE[G>3596'CM4<%,:98V2&<+XT:?+(FUW#6D-LK,YV5'L%9*$4R [ >+ MK@MD7<3N'9N3<C2<V@$V,60%AG*B4?&&VIQ7W&%VD"V+ZQJERX-ZA<"HXP6$ M46,MO*5&N30@0A2*MQQ4)*)%*I(VY\C*([;#3;:S_J]3$J-9'B1@E+S(B>QT M<B)[SZD\=";Z1B:N>K+@QVX\=^SX58!CD 3:9'%FE_3Z-GBRGCU3'J;H?Y"9 M /D2SK*;6L&"A#U[ONPOG?I:=NKCSBI>?P7_%E>G\$\%=\Y[^T'^H<8%#N4^ MD>62/DD!-X(H+O[=F.\LWUD"TY6/^?>)>ME_F_>)[+UDL)#^IG&?Z&_R%^53 M0Q/),7'X[!ER^JKI7N!/2'T" _6=VFKZB\R;*O,FRH-7[<GW/I]RQXDW(\^A M07*3,Q^U&B^WP.=2'"7'#)XT[<Y)<Z>63B +RL<C3QY%-W(5[OCQ<3[WIN.Y MO>4ZVDS>?)!<-!G.^A"_G0'Q>LNO>AEM.Z*'S9@XR=/FD\KH_6Y@:M7D\JN) MQQX%\KN,^F'4<>KAM1;(A7B<LC3*\Z?08_.O,?G%FRDG-D8IU_-B<Z)5SBIW M#44^ICRHZ+[4&V/J)0_?N:TIGNT=/G6_ >=T&E4TW7.\A_X#J\OWB?D0A96R MJ;^:B],\M-%+'J'SEO:4<*%$H4:)3,W<_9'[NI"YC8UZ(+6F$=0=?1PFM_.[ MK<G1_' H8#[#Y!"%/VX$?SPC.>-V22-V<H]N98SZ1YR2U#_5*/5G;S*5^B># M^I^2U'\;>:G_-A_J+]!/Q;W+C%&_+&<>]<\ ]2^3M#J;Z<"18I6/HW33?BEH M?Z4F[3^D2<TNE"C4*!&*]DM!^Z%R&Z7]6:#]1R7M\\%$=Y0F[3=;<U90S;/D M[ Q"S?/E<Z9XR$L7QUM.R,X8J.Y(EQM1S6CK!KD2W-9-2,N^L=4M:,2S^UQM MQM-*-5:CFA93X^Y<Q?88U?N'7 KX5&24M_TU;8_'W;]-V\/]N)R/8E$=;'L@ M#;^H%Z%L#P^5-SW#$E>+&LJ@+'&_B!;WZ^*-#)I':T4TK=65VTFOBHXT4F?- M630,-0_3G;L=<K?3S-U..<TGC_TIGWSDM8@.HLJGIG;J;TJ-,9XS@) A.NND M@6(6C3.YSM?I.6H4UYM:YP@ZAI4P7B?3CU:]!S#^>I/'OQ%U[H^@3GT61 8% M2K;#XBZJ$ZQGCXI[*)1M[6BRK5V<S\9[YGIDA-:B_NTDOU"-<B?%_!B7NH$N M.TS+)[C?F]'OSV6_MXN[B?N%T"[W\/4(;;$$].OYE2CWF6:_6(9[ULE7;OBN MV0,BEIX3O0VMF1/M_B4$+8P'+\RGG:;25V>:2@/\+(S(ZSP ZJA':&:=?T6= M[YA<YP.H\SF3ZQR/.N='4*<^2R2# NF^)16@I7+03ZI\78B+P\2!O$MJV(3I M$R9/DH?;P[-W@EMQT,LP(+:AE9;TFFP%H54>G B3<U,U1E #R_XSU'T)+"JV MVVRH'_%$EWJR!D%!06Y&2"[VKS/Y[V^16]@2N%2OW(S\_/PK"G(O8N$'E*[8 M0^X8FSTCOWNO_%[9$<]<#'T);Z\!HTNBK^7H'!@=XM9K^7A-F/4'SUXR[:$T M84/][6E?T^PA'N^2KDVN/)84N7R-%ZW(*7J@G61Q2=,X$'<,GSWU3CX3HUOZ M]VE'[NB8:#YJ$[G'FP!YVQ&ZDOM52(K'R_TJC"N9-[UTRNP9TV>4S='O\_;8 M16Z;HX5W+W&XOD+P"I$H);N8CA[:Q*U-*X2X*(B8NI+$ KH4>L-);<4B=57< M;5M;1^7E%W0SH>=/H.<ULN?+?7J^7.1'3$_+("^?A>QRH@Y'$STA'E-2,K D M;_0?ANC6VGW>([<EQN$:D5>0W[U;=K(a)T%=RW%S#.MR'+G9!U[#ZY+:UMZ-4U MP_73^*#V&,TZBE-ZE6]&K[["#)VEKNC5,?FV#G=T-\7NTM^KXS^C5Z<H+I3= M%3X%B@1:)U+I1\B&%/HG]^JUCK&\+U:VD!^Y_!R%T8X3+3'JL?03L>9!&'2/ ML#G+;#PLL_F&+;.Q@E^X8G0$DR$Y9XF>J&>&X!SNRUJK_>\6,4T,%N5TDUB! MNH=+_G=Q:!N#VB_73Q5#-Z'<]6*!?>"T"7/F9$0N-ZZ#=3E>\O8X^;HS16X@ M+JXPH>[_0=V?R+JW(2W[&4QMQ+4.$=?0"'&#G,>1ZCR.%-TCIMXI]"+-IO=1 M[TQZA3Q2#O&(a)^WS&ZL^A.=0?99V8[3MEOQ':FKL7&K#^;\ZFG!BKW/ON.Y,! M=QXE3WGN##)G9#7E\N65*^$C&_<^)^'O?+H<]=PA;RZY.(R7UNQ Y4B&;JUP M97MRQ\+**"DI(-UR8B.TTGZ#5KP3*]")C,N)+:"-?9A;)WTH7_#DXC!<#_;P M%JRECW@/6,\UFNOI1&I4%PH:4<C[/=03W#?19'^T)_Q1<^M\ '4^9W*=XU'G M?)/KW(@Z]T=0IU&*ZTI%U!LKZ:0KY.LB71Q:Y7/$B#73U=0'FOH6U'V-K#LG MU:.6=%)R42WZ,X:*@K12<SQ\ +-9;W VG?()6@1WSR#_ZN2HC\J7<+JC'@O7 M1AO)XSY)A>;9:) L?2%9)DC)TI\4R=(_7,GRYLR0DL6H!W %/(!2Z0'TE;U" MZ"@>V84= /WS]=]789;5CO7("[0X#?1K(GHSCVY&OZ:I7('0.K1H>+'NN7KM M*I0JHT([K/_>!7[>]\6E<(\\;2D<_&S.#LF6U71/L/G<NRE+V/3FAKV;U60M M-Y^['W)/TYU[%G)7723W&I_G)A7T; B]9'1U'\;85@O><?"$X%?^N7=V='A. M$.NFN7MY?:M$8@OO>TB\_-"TP\6 ';H6GM1&>'E.VD _D\=R1EQ<KLLR<])_ MT4%0;5A/+V@KY&6=R1IM*S2:\3J-R]\/T>I)*7]WD<?>1EQ*X8L]YP]8X3NR MI!3>Z1%X)LB5S>C;Y[)OVVD/R2<4M,<*&9RO6ZY,Z\C/)S1[I3QC?B(a)RZA.Y MM!$^&JA/=/52G^@J>NBE/M$^7.H35JJ'IV7NLS,K[8^@3N//SF*I3G23S\Y: M>:E/M KW^=C)?/E\+,'4YV.Q]+GLVW:1J%"?2 S7!CB1)Y^/:?7+0W_-WXF9 M1?,-/M?D9V2Y$:Q/J;B+RN4SPMO5NR4(P]/LZY]&J;GB[B#-WORSP5GTG.%Q MSQ5/Z!YW\#WR9:*,GI'C?D+,(\\]<L1U6%L!]\>GKX*UY="TMBYJV8B9(?2X M_YX,)?_--)264 DL1'[=O!Z[8@KR:>?TRL3 -@;26_1[^7KH7[*-=]'&^R:U M$;RO) L60P==-3MI"/*FZ,Q;3&L_TF>)<KU;PJAW?8S>>HMIZY5Z\_Z!7J8D MW7D?=NJM=P$-ZZ<W;R'B";KR9L;JGX,'29_5[J01R.O6F?<ZT1&Z25_>><BK M=VY7(V^,SKQ=Y5U]?7ES1 %UUIDW2W2F+GKG%Y9";!AR*9>^H>[TPR_&SP/! M2_4Z^UY WX?H>W#>W]$6W32?A7KUTD86O:.S#YDNO>UWI6-9^OMZ4B=_Z&T_ M4S>=@2;USZD8I9^/11&=TM=7G?.423WUY0LQGFI\:^A9BK*+8/M??CQ]_T2> M_,ALKY3+I M*:',H87V,?_I7GGRG9-ABB5/YTA]]ZJZFU>1G537EJH1\WH$6 M#U$5PN6T8E$C?4PKZ"F$.^DI>AHA]V@YPD_I:5J)<!>MI%4(/Z-55(5PKQI^ MKJ9_H>;;KY8_H)8_J-9[2&D',>],>&TW9>07E!'+T5Y01WE*SF%H2:#'LN,= MW_Y/7W-@2U\M\N3.##YW$T]QY.)XHOHFW@+UY6PA[3O_.I/?G(7R VAANO(F ML*87^(Z<)%\M63HI(a)[?S3_.]V[&8&K>F*_N:.[IGY5# 9TYJR]1?<U_S?6F_ MS7W-:??)^;A<]-;8U]R;?U$OM/<U-_&H=;@/9:9+"NL(5*B<5J:$%1[.>U"E MP=4:GGT/T:>I;)E:YL&0=*SOKD,0#5,Y?)$EQ,]>%ZO_&$MKQVF<]S27>[%- M>=]:Y"<P'$ N]4?;K>1),N54">+&SE1-&.1SJB2,TRBRG%FG2@KP2R'8T4E] MY3^ <5O;-'^F2JZUYQZM#=^NJ"/8#^TK]Q@&W]7-0XEBC1+:]X"O0NZQ(7,; M&_5@"(IKY9/CD?+?M;FM*7RN)' ^#7C/?+ZC'*-S(F<">;QGQ#UO/&Y&P@9X MT$,NET\46B3XO;M-OP>^^UER)VJ>JC(TMMX86Z4<VQ YKPB-G1:#QN5Q#39Z M6FSW:G+'F75:S$&#P-?S)5\/)B]?#S9V6NR[$F.GQ60YL_BZ.SS7(IHIK7G^ M1WWNF.3F3HL%<'41N/IN#:[^G?PW;5I<702Z#RX1BJN+P-6A<AOEZFO U3,D M5_.^'+=(#N!J;;VG99L2O<6]643^FK!2KR942I:I)7X)/7B0EO N6^C!PZ38 M<NY'\Q5=%_;Y."V>V ">."-Y8A-Y>6*3,5U7L\F8KI/ES--U[T&/G)":B>^R MN6WAZ[KUX(HZ#:[H2S]JTGD>2A1KE C%%>O!%:%R&^6*;>"*8Y(K/N111Z>8 M='[X)O2R7.Y6GTB;R:OK-AO3=4M?ESIA@U%=US:+W"W-TW4_4[E\\CM11,EY M16A,UQ65\+@$&=5U;3--/!GMP'KE"MYMV4K^\TR5KX4PINM<.XWI.EG.-%TG M8JA(9+-N$ORN W=LN+JNGKK"8]+0=:(S:7-U/15KE C%U?4T-F1N@UPM''2M M<#%7"V7_'\( OM:O[9;+)U<=:;EHZZ?O.HH$_*+7]U-*ES65,EWK0=\M%$[( M2*=(0^N>.QB(.SSOU(Z<FFHPPDVT&[/R OV5/!R"N#'--V>J,<TGRYG%(=OH M[[17[H/>1?\@UGS)86J^*GS?HST:/+)+:I5@JM^"$@<T2FCSR'[D/ATRM[%1 M'Z+_I)_H [F_XV4>=;19;\XX34^*)(S.21?4.VFL^1 WIOEN' ,JMM)JHYKO MR'LF>GFGZ6.1)-K)L1V6\XK0F.9K=4:.ZY!1S7=DBXE>7@UH;)-H+?GZ$'GY M^I QS5=_ES'-)\N9Q]??TEYAEUQXA,+W\JH@%=X3;;2X&NNFS=5[Z8!&B5!< MO9=.A\QME*N_HY^@_9BKCU*3EV>*Y,^&Y!\G*217YD!H3.HOJS$F]64YLZCC M??@J>^2]TD_A^QCQ=ZJH$Z3^> WZ^)1&AZ"/3I"+P25"T4<GR)M0N8W21W=( M_1))'_S/=E5_QX1[>Z<I#5)_DI2,7<@K];L8D_IW/2*E8[91J8^I,L_?.4UC M,+9J.;:II$C]J<:D?M>N<ER3C4I]6Z.)_DX-UFL3ZF">GD)>J3_%F-1/><F8 MU)?ES)/Z=T"N+I-2?R;QFZ#"E?H3P-5/:=IR#Y(V5T\ 5P>7",75$T!/H7(; MY>H9X.IEDJOEVZ^B0M[;LS?G[:P0.;(WAQ7/QJ+>TSMS3@GKK/[IE*:$L:3S MN3//M>]SYS%4+M+1:B["+-%I42/-$YD<$YT1GR\ZXJJS<"%^M^B *Y?(07R! M2,=5CLA%?*%/? 7'0C]3YE%9U-'P2"SJ"&(II#>F^XF]Z ZIX#-S4>H,U:DS M=R;$S,4IU[KG"Y*H%FTU(#Q#=8L:X?>=XAB=1;PUG<3563J'>!LZCJMS= 'Q M9*K%U05J0#P%\9_5>'>.77R^HM0QG/&9K[B+S9?ZAJZ//DPZ6/-*NT,4^+F2 M+(T-%$/^_UM&>*F:CV3+]XZ)1ODJ6^73^*_/K_BQPD@H@RB] ^)J-LVC(32= M;H68F2U3YD(-SD!*Z%5Q80&;:R.0,'C),Z+,6>G_:XKYK;<OWXOJ\_^S*!W7 M@6F\8$F="[FM3R[]]S?VK!,R7G'GSN/;OA6^Z9X]*YZPT&?9N68^/^2_*84W MAC1E3U>IHZ II3D98M8\_G_]\$1W!K*!$N!V8 'P / 8\#2P$E@%O I\!'P& M[ ;V /N 'X&?@./ 2> \,".::!8P&U@*_!F(QRJV!;*@13H!MP&/ !\#GP%[ M@=\Y0#3 9& J<!MP![ ,: !L,42]@?[ :& !< ^P"'@$^!KX!HB'5OT2. +4 M J> <_Q^%I@ '8 "X,_ 2N ?@ 4T;P/L0 QP@>KK3L. J__QR-=?'J0O]^W= M]^4^VK>7=N.[$]@A8]N S?CNIG?D]=HUM/8E>DG&=\-,&E Y*(J*RQ:VN]43 MGROC1=ZXHTQ<%5T^@93<@HJ/W)):K*16\P:FJ&LKE:LL=L>C1E=2U(V59+NQ M<@BS@&5X&XJ6,<?HRILL5)J*<:AA I<ZWY9(O8X:)RCJADJ*'EV)OY9)6(I! M/-8YP%S@3F #L!'X -@.7 KSOGT\OQ":B%W_GL"50%^@&!@,? +L![X!:H'C M0&8"T4.)6#?@56 ]\$]@/W *& [E[TA"V\!KP.O 5N!]8'TKH@&0% .!4F Z ML!!X!]@$=&\#&@#Z -.!&<!"X%[@86 %\!2P _@8. ;\##3PQCA8UIV ?* M> .X(85H+-! #>=(a)4^%[_.A79[\X>O:+LU_L.OL1I]-6>E>&ZVF=#!O.\G?- MBTIP5J;QJ[AX9;&&]Y5B#>.5]5R,>&E+BB_RO>)55==[(N=5RUWO$Q_C$\^= MZ*UOE%]])>J5\MM(OZL2OYSJ;Q; .KJ2^S"Z<@"/N\LE1-V $F 'D =:60NL M ]X%?@\2&@I< PP'K@6N \8 UP-CF<2 \<#-P( *DL<CCU/M#T?IZ.$#_#U* M]$6@(?"O3P2?J#)!MN&MJ+2-RNF<J%Y;\,<Z3N ORP>5A@XS/;'\4*_OQW4R MRW^AZ@"7J@=R?'3!0E47>/1 %5 -U #/ *_XZ(4=JCXXH>J!$TI'3Y!8E5+K M";XFL<Y62]N58(.298,GBZ< _Z8&;RC!\R2&1K\<7:5DJ2(Q,3-7/*E</<E7 MM9[@827XDQ(L5;(L)3$[K9;N40+E W60*MJ*-Z?1>@=%/=[X@/633&E_I II M7CB2R2J2GJ=$N_@V35R?!NV03'[7+9+)E>3(7T/=UOBDQB936F$;;J7=R<9+ MSS<JOQ._HD1M[RW!+;:TW9?6KI-,3RM,?AX_(G_[09=Y\J?XYD\G"^?G$MZ; M K[WN.+)TVIP57%-OP7\D.+1US-]]/42'YW]&!!G\^KN=H 3>CK3KNCQRX#. MP%0???XH\#ZP#?@ V 'L!O:H.KX?]'A_5<]/4?7\[< T'UW_"/ !L-W!NEBD M6VLAERV\=C\JP3%E>;]7@F^T ^M%?K,$)\K*WHWY7D_5H8-CRGH<\URIE47Y M7&D&LKWRMA?+H@8'E(#8+&ZY-"II>G3KK1<D-5@M\J]"O]KT;>%<H'!)YRZ> MWT^!7<"_P6X:"I0 HU3[:J%J7U4 E:J-]56 G94 ) ,IP!(0\U+@$>!1'QMK ME6IG'0 . H< WJ<0%:?87M' _[9W[K%Q''4<G]U[Y,Z.7W?VU6=L9V.Y42,1 M&UM-<"S^L(-K.]1VTCS4-'%)+\[:/N*[<\Z7/D1:!5PAM4*0*JF*$)4L:%.H MF]9Q+R$-B!APDT CB JT"%6"BI3Z#PIMB()"G![?W\SLWFY\=L[8H*ABK<]] M9_9F=L?SFYF=Q^Z>R]('\X"KXM\T1;7YK/+/3'*9I+#TLO#]W1#5XLL8[T9Q M91TR?5JS]%P4A>$B4[I5\BGG4';E7,F[PO>.\+UC^&00+F\)$9N++%O80,T3 M0[64+K6 Q%G 2A[F?AZJY*LL\#D>RJ4L43R*I538RLP*C^SOW@9*EXIIJE6@ M!JP!;: =; +;P0X0!G%+OW&?[#L> *=$@H^CM4:C/2X$OHO"9Q'LO"!\%IEM MYX^%SR(#IJ_4P87R%R&K'2.45W=9V\[]+.=PZJ3[I#N1G\@O#Y0')BLF*[;= MOHVWI%Y;2QID_/D*X.4_'R+^%-,U_WTS+30S;8\[3KHI/=8_)F,S,XV9T[80 M%_.3S9X A\!WP!'P"GC-,A:8!*^#,^ L. =^ 7X)W@#GY7CA&E.FU!&2!@>7 MB4R^ZK3ON)!C9$,NW?"-BB"CXF"C(OJH"&GW'3-#DN]6VD0=%-:F]E:!([/5 MDSF)_,=]Y8%/ETU63"PGJY-]@^:1@MSMY2[#]@MWF6719XSS?@?> F^#/X._ M4?L+4M0NHVNQ!.2"0E " GGIL6$%J,SC=9\,D13F'#.%K#K&U&[Q'9DL*8R; M%.9,FO'LOFH1W2+RNR\)L9\AO66;TUZ9KTS6!B.GO>;GPEV&]:TE8CXE(?U" MA'2I,/9Z%^[R5<JQ_1HYIF\#Z\$&< ^@%QW<"^X#W6 G> #L!F$0 7M!''P9 M[ >/@B? 8? T+0^"(^ E<!2\ HZ!XV!:E(LKPKY<DB138N>4RGT-XKL)L=/N MHWC3F40&F<XD8V;T4A%!2C</8DU2^F!3Z;-/VR1CRN99%HW:^=\LBQE:I65D M@U/@-)@$KX,SX*R<U_DC>$_.[7P$_@&N@A0]^Y6/:QMP @_( 7F@$!2!$E & M*D%5/LT)I(T\0KZ9EK@B3'!%F, >(1UO2I62))&9;A%YZ'_=Z)MY,'M:KF22 MA6VW>%M41G8QYNJ^89FO>Q6< C\"WB+8%NP%\5GF[$[[&)L ]_G13P0AL,LR M?Q>3<WC?!S_PF]>*$\Q)O>2DZ"QG(3+""<.GWCR"71SSBVZ78T)&A1QARF'G MAVE;9^Z#IWO>#MYGOZ7:A JRQ8O@9^#G8%+.L9X!OP:_!>^"OX(/P'7@*<81 M0 [(!4M!H)A^UI*QE:"^F/<%*6\N,>7WQ1^R#VPB=YX6\IH(^:J0H[0@SF=[ M+))QYW[31_&D7)M#;-LJJPTZF%MU1KU_R!\/C@>?K'ZRFC&CSVULV8\+C/Z^ MBY<&/H=#;I=9-N!6I3MS*B@%(A7IZ_]\1P#6$:*'CQO7\N2(\YHEM81L1?/I M=X+58 WX+&BPS+$W@TZP&=P/=EOFW0?EW/LPS;6+?/X5R8@AY^:0;PLY=/.0 M4G1;!+MDSLO6XO%@Y;*T18/,6J\,MZ&SN=RRQ139=[,S!<WXHL;.YTR91@[9 M_&?_X8C!1W;[)G@*?,NR=O(<& ,GP 0X:UE/^0WXDUQ7N00N4WT'UXOYG,UA M9U+(R WR1J:=<\FSF78^(^2I.>(MZL8M$K"VZW/5W<4I;]D<V[L89=E_7:Z+ MI2QK8RO *E #=LBUL9K;&*NUK!-M =O!#MI?BOV@%?2!H^!E<!R< #^4ZTGO M@^5!L9YTMUQ3>E-8[(*XHF8AYT4'X+SA<V09SQ1KA'-SR"S1^?83FXP+&1-R MP59ZZ(VIN>@./^_V[[A:D,L<W_-TE%9]2EJ$%1UQ^[=?+? PE?8S7N>+9-WG M?05E7J5AWOV$91UR[>Z+EO6[ZR+IUS+)_[=/PD:E2BU".X"A6P#] X7=S>@5 MEPZZ#;GIHY0*=7?%XI'0 )\9=;.0UTFW$+ FIC;1;'(3\[;KH=WA:)]63P_- MJ<SEH(GFHC*'_R_3)6N5@GSF+'.\X+S3_5-QTZ"+;?U*3^#&E%2QYJ9+*?K! MG$"+WAO:-Y#0-H;BH;YX:+!?:XU%$Y:PU>SC#0IZC]7,VQ,:I-NIM3JZ+;- M--!(/:U]:FP9I5#1F)M2J,?94E;(J(JM+8QK]!RKQC2$\%&(UE@LP4,4V4*4 MLI5-WV7+E5*6NS'4IVM=^R*[]+A(;P7BUBM5+(_B1A%=VZ(_G*!^OM],P0K$ M;L;Q?688\VU "->OW,$^CBEL$]1)::37M_#S/^]^OX)JY_U.9+B'<NMMG/,! M,]<.@D,\+^F>207_5PJVHD\'_W3R3Y<9ULHAF_6-&6]QGY73_([.Y>"M@(,] M%J0S.?F9Z'PJ=SNXVXDR89SI341_#)>5\AST'8J,]+KYF=19ST0O6BF17] * M!%UEZ,Z!9K:.7@0OUY!I?<HCUQ9HKK)2SAO1N)7&+O6R[TG7L0[9?K5@A-7* MVE@[6\^^@)+=P3I9%]O -K)[4':6;(WNB<8>BJ+DA/:$AH#"<BUWNSEY2NFF MW*4RA?[EQ:FG#RS!A2>Z+T*_$1V2!GE6NOM4XU"UZ1<7M;<T;M$C@[%X*/Z( MMCZA1X8:^?UN^-BCM88'=*U9JS?BK;/%:]&']B1B@RC_ RB_C3Q&KW3WAU&: M>F-Q\9R%UB-^0!=UP?H_K+ZKO655?>W&=8UK&W9^IDYKTZ/Z@R%M<UO=FBR/ M,-]_9''/_C]/_^K%BKOPE <W-7=JP[W#ZX:W#7<UMB/@3@2LV1WK234Y#BBL M%B6=$+>CUXI7@+$:N@L$_A['>ZK.RGT'E<["+>&(/J1UZ0]IFV*14)1Q/RWG M'T0;M_F1R*[8 /-5(:2[.1Y&2R^^+\O%]YW2$]0.*BQO:S3\H!X?TNZXMVZE M_&)O%:IRG>?KN"9<0/WNYVW*UQXMZR5$\V)[P$%6_N'"&3O-+<G;!OH5[I[/ M]X>B?4A[5._1AX8H[RG7C/S"-2?1SQ\T,I[+T<*VIVS$CTGS.#(@<EN\%$1# MN$@X&J+7MUASW>I.)^F3?V_[OP%02P$"%0,4 " ;LT\C!" 9KFDT MN@ # , ! M($ 2#,Q,%]C;W(N9&]C55@( ";$1#0FQ$0T 64$L%!@ ! $ 1@ *,T #,Q end

1 0

White for H.245 V3 is now available
by Sakae Okubo 15 Oct '97

15 Oct '97

Dear Q.12-14/16 experts, Mr. Nilsson's laborious work for the subject matter has been placed at /9801_Gen directory as three files; no change marks, with change marks, delta. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

White contributions for decision
by Sakae Okubo 14 Oct '97

14 Oct '97

Dear Q.12-14/16 experts, We have still several things to do before hibernation ... Attached please find the current list of white contributions for decision at the next meeting of SG16 starting on 26 January 1998. Those files listed have been sent to Geneva by respective Rapporteurs and are available at /9801_Gen directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Documents for the SG16 meeting Geneva, 26 Janaury - 6 Febraury 1998 White contributions Document# Drat Rec. File Note COM 16-29 H.222.0 AMD 3,4 H222AM34.zip COM 16-49 H.225.0 Version2 H2250v2w.zip Word 97 H2250v2c.zip Word 97, with change marks H2250v2d.zip Word 97, delta COM 16-40 H.235 H235wht1.zip H.245 Version 3 COM 16-38 H.246 H246whte.zip COM 16-?? H.262 AMD 3,4 H262AM34.zip under Q.15/16 COM 16-39 H.321 Version 2 H321v2wh.zip H321v2wc.zip with change marks H321v2dl.zip delta COM 16-41 H.323 Version 2 H323v2nc.zip Word 97 H323v2wc.zip Word 97, with change marks H323v2dl.zip Word 97, delta COM 16-?? H.332 H332whte.zip Word 97 COM 16-42 H.450.1 H4501wht.zip Word 97 COM 16-43 H.450.2 H4502wht.zip Word 97 COM 16-44 H.450.3 H4503wht.zip Word 97

1 0

cc:Mail SMTPLINK Undeliverable Message
by Bob_Bean＠MULTILINK.COM 14 Oct '97

14 Oct '97

Message undeliverable at this time Original text follows ----------------------------------------- Received: by ccmail from woody.multilink.com >From ITU-SG16(a)mailbag.jf.intel.com X-Envelope-From: ITU-SG16(a)mailbag.jf.intel.com Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id HAA00741; Tue, 14 Oct 1997 07:10:42 -0400 Received: from mx4.smtp.psi.net(38.8.138.2) by woody via smap (V1.3) id sma000739; Tue Oct 14 07:10:21 1997 Received: from mailbag.jf.intel.com by mx4.smtp.psi.net (8.8.5/SMI-5.4-PSI) id EAA25419; Tue, 14 Oct 1997 04:36:36 -0400 (EDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id BAA07681; Tue, 14 Oct 1997 01:30:54 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 144555 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, 14 Oct 1997 01:30:06 -0700 Received: from gclgw.gctech.co.jp (gclgw.gctech.co.jp [202.33.9.18]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id BAA07326 for <itu-sg16(a)mailbag.jf.intel.com>; Tue, 14 Oct 1997 01:29:54 -0700 (PDT) Received: from sparc0-1.gctech.co.jp (from [202.33.8.134] [202.33.8.134]) by gclgw.gctech.co.jp (8.8.6/3.5Wpl7) with SMTP id RAA22665 for <itu-sg16(a)mailbag.jf.intel.com>; Tue, 14 Oct 1997 17:27:37 +0900 (JST) Received: by sparc0-1.gctech.co.jp (4.1/SMI-4.1) id AA05108; Tue, 14 Oct 97 17:26:31 JST Message-ID: <9710140826.AA05108(a)sparc0-1.gctech.co.jp> Date: Tue, 14 Oct 1997 17:26:31 JST Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> From: Sakae Okubo <okubo(a)GCTECH.CO.JP> Subject: White contributions for decision To: ITU-SG16(a)mailbag.jf.intel.com Dear Q.12-14/16 experts, We have still several things to do before hibernation ... Attached please find the current list of white contributions for decision at the next meeting of SG16 starting on 26 January 1998. Those files listed have been sent to Geneva by respective Rapporteurs and are available at /9801_Gen directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Documents for the SG16 meeting Geneva, 26 Janaury - 6 Febraury 1998 White contributions Document# Drat Rec. File Note COM 16-29 H.222.0 AMD 3,4 H222AM34.zip COM 16-49 H.225.0 Version2 H2250v2w.zip Word 97 H2250v2c.zip Word 97, with change marks H2250v2d.zip Word 97, delta COM 16-40 H.235 H235wht1.zip H.245 Version 3 COM 16-38 H.246 H246whte.zip COM 16-?? H.262 AMD 3,4 H262AM34.zip under Q.15/16 COM 16-39 H.321 Version 2 H321v2wh.zip H321v2wc.zip with change marks H321v2dl.zip delta COM 16-41 H.323 Version 2 H323v2nc.zip Word 97 H323v2wc.zip Word 97, with change marks H323v2dl.zip Word 97, delta COM 16-?? H.332 H332whte.zip Word 97 COM 16-42 H.450.1 H4501wht.zip Word 97 COM 16-43 H.450.2 H4502wht.zip Word 97 COM 16-44 H.450.3 H4503wht.zip Word 97

1 0

Read: H.245 v1 and v2 will not interoperate
by Ryan Holmqvist 14 Oct '97

14 Oct '97

1 0

cc:Mail SMTPLINK Undeliverable Message
by Bob_Bean＠MULTILINK.COM 13 Oct '97

13 Oct '97

Message undeliverable at this time Original text follows ----------------------------------------- >From ITU-SG16(a)mailbag.jf.intel.com X-Envelope-From: ITU-SG16(a)mailbag.jf.intel.com Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id NAA06681; Fri, 10 Oct 1997 13:24:20 -0400 Received: from mailbag.jf.intel.com(134.134.248.7) by woody via smap (V1.3) id sma006677; Fri Oct 10 13:23:55 1997 Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id LAA10513; Fri, 10 Oct 1997 11:16:22 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 141970 for ITU-SG16(a)MAILBAG.INTEL.COM; Fri, 10 Oct 1997 11:15:41 -0700 Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id LAA10471 for <ITU-SG16(a)mailbag.jf.intel.com>; Fri, 10 Oct 1997 11:15:39 -0700 (PDT) Received: from bcars735.ca.nortel.com (actually 47.128.2.191) by bcarsde4.localhost; Fri, 10 Oct 1997 14:12:55 -0400 Received: from bnr.ca by bcars735.bnr.ca id <07393-0(a)bcars735.bnr.ca>; Fri, 10 Oct 1997 14:12:21 -0400 Message-ID: <199710101815.LAA10471(a)mailbag.jf.intel.com> Date: Fri, 10 Oct 1997 13:54:00 EDT Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> From: Tom Taylor <taylor(a)NORTEL.CA> Subject: Re: H.245 v1 and v2 will not interoperate To: ITU-SG16(a)mailbag.jf.intel.com This is the subject of the last message I have received from the SG 16 reflector, dated September 30. Has everyone gone into hibernation or have I accidently become unsubscribed?

1 0

cc:Mail SMTPLINK Undeliverable Message
by Bob_Bean＠MULTILINK.COM 13 Oct '97

13 Oct '97

Message undeliverable at this time Original text follows ----------------------------------------- >From ITU-SG16(a)mailbag.jf.intel.com X-Envelope-From: ITU-SG16(a)mailbag.jf.intel.com Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id QAA09586; Fri, 10 Oct 1997 16:11:29 -0400 Received: from mailbag.jf.intel.com(134.134.248.7) by woody via smap (V1.3) id sma009584; Fri Oct 10 16:11:11 1997 Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id OAA13919; Fri, 10 Oct 1997 14:03:18 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 142404 for ITU-SG16(a)MAILBAG.INTEL.COM; Fri, 10 Oct 1997 14:03:15 -0700 Received: from axp.cmpu.net (axp.cmpu.net [204.96.11.17]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id OAA13897 for <ITU-SG16(a)mailbag.jf.intel.com>; Fri, 10 Oct 1997 14:03:13 -0700 (PDT) Received: from smithmicro.com (C1123-111.dialup.autonet.net [206.88.153.111]) by axp.cmpu.net (8.8.6/8.8.5) with ESMTP id PAA19922 for <ITU-SG16(a)mailbag.jf.intel.com>; Fri, 10 Oct 1997 15:59:52 -0500 X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <343E9787.2C343992(a)smithmicro.com> Date: Fri, 10 Oct 1997 14:00:55 -0700 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> From: Paul Long <plong(a)SMITHMICRO.COM> Organization: Smith Micro Software, Inc. Subject: Clarification of H.245 MTSE To: ITU-SG16(a)mailbag.jf.intel.com Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailbag.jf.intel.com id OAA13919 (I posted this to the sg16.lbc reflector, but Tom Geary suggested that I = also post it here. Sorry for the cross-posting. I believe this only affects H.324, so = all you H.323, et al., people can continue with whatever you were doing. :-) ) Here is the text for a proposal I submitted back in Portland and that was= supposed to have been discussed in Sunriver. Since it wasn't, we need to discuss this on t= he reflector before the next meeting in Geneva. If you have any problem at all with th= is proposed "fix" to the MTSE, please speak up now. This contribution proposes backward-compatible modifications to the H.245= Multiplex Table Signaling Entity (MTSE) in order to fix an apparent oversight. These modi= fications allow an implementation to use the MultiplexEntrySend message as it was intende= d=97-with multiple multiplex entries. 1. Introduction There is a flaw in the H.245 MTSE SDL that precludes sending the Multiple= xEntrySend message with multiple entries if there are any entries in common between = it and any of the preceeding MultiplexEntrySend messages. When multiple entries are sent in= a MultiplexEntrySend message, they all share the same value in the sequence= Number field, yet each out-going MTSE maintains its own, per-entry sequence number in out_S= Q. Therefore, only those entries whose MTSE coincidentally have the same value for out_= SQ can be combined in a subsequent MultiplexEntrySend message. The trouble this cau= ses during implementation has resulted in some vendors deciding to not send multiple= entries in a MultiplexEntrySend message. 2. Solutions There are two solutions to this problem. 2.1 Avoid multiple entries Never send multiple entries in a MultiplexEntrySend message after the fir= st one. The first MultiplexEntrySend message may or may not contain multiple entries. The d= ownside is that one is not using the MultiplexEntrySend message as it was intended to be = used, thus wasting a small amount of bandwidth due to duplicated overhead for each M= ultiplexEntrySend message containing a single entry and the associated time loss, e.g., dur= ing session startup, as the sender waits for responses to each request. 2.2 Use a common sequence-number variable Have all of the out-going MTSEs share a single sequence-number variable f= or determining what sequence number to use for out-going MultiplexEntrySend messages. Ea= ch MTSE continues to use its existing, MTSE-specific sequence-number variable for recording= the sequence number used in the MultiplexEntrySend message. This is so that responses = can be identified as belonging to the same dialogue as the MultiplexEntrySend request. This is backwards compatible with the MTSE defined in previous versions o= f H.245 because there is no requirement in the in-coming MTSE that the values of MultiplexEntrySend.sequenceNumber be contiguous from one message to anoth= er for a given MTSE instance. In effect, sequenceNumber is used as a somewhat unique han= dle for a brief transaction, not as something that must increase by one each time. The re= sult is that this allows all out-going MultiplexEntrySend messages to contain multiple entr= ies. 2. Text Modifications Here are the required text modifications for the second, common-sequence-= number-variable solution. Replace the out_SQ definition in 8.7.3.2/H.245 with these two variables a= nd their descriptions. out_SQ This state variable is used to indicate the most recently sent MultiplexE= ntrySend message for this MTSE instance. It is mapped to the MultiplexEntrySend message se= quenceNumber field before transmission of a MultiplexEntrySend message. global_out_SQ This state variable is used to indicate the most recently sent MultiplexE= ntrySend message for any MTSE instance. It is incremented by one and assigned to out_SQ be= fore out_SQ is mapped to the MultiplexEntrySend message sequenceNumber field. Arithmetic= performed on global_out_SQ is module 256. Replace the contents of the task symbol in Figure 28(i)/H.245 containing = "out_SQ :=3D out_SQ + 1" with this: global_out_SQ :=3D global_out_SQ + 1 out_SQ :=3D global_out_SQ 3. Proposal That the text modifications described above be applied to H.245 version 3= to allow all MultiplexEntrySend messages to contain multiple multiplex entries. [end] -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

cc:Mail SMTPLINK Undeliverable Message
by Bob_Bean＠MULTILINK.COM 13 Oct '97

13 Oct '97

Message undeliverable at this time Original text follows ----------------------------------------- >From ITU-SG16(a)mailbag.jf.intel.com X-Envelope-From: ITU-SG16(a)mailbag.jf.intel.com Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id QAA09525; Fri, 10 Oct 1997 16:05:56 -0400 Received: from mailbag.jf.intel.com(134.134.248.7) by woody via smap (V1.3) id sma009517; Fri Oct 10 16:05:25 1997 Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id NAA13745; Fri, 10 Oct 1997 13:59:35 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 142374 for ITU-SG16(a)MAILBAG.INTEL.COM; Fri, 10 Oct 1997 13:59:22 -0700 Received: from axp.cmpu.net (axp.cmpu.net [204.96.11.17]) by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id NAA13723 for <ITU-SG16(a)mailbag.jf.intel.com>; Fri, 10 Oct 1997 13:59:21 -0700 (PDT) Received: from smithmicro.com (C1123-111.dialup.autonet.net [206.88.153.111]) by axp.cmpu.net (8.8.6/8.8.5) with ESMTP id PAA19081 for <ITU-SG16(a)mailbag.jf.intel.com>; Fri, 10 Oct 1997 15:55:59 -0500 X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 References: <199710101815.LAA10471(a)mailbag.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <343E969B.5B508E8A(a)smithmicro.com> Date: Fri, 10 Oct 1997 13:56:59 -0700 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.jf.intel.com> From: Paul Long <plong(a)SMITHMICRO.COM> Organization: Smith Micro Software, Inc. Subject: Re: H.245 v1 and v2 will not interoperate To: ITU-SG16(a)mailbag.jf.intel.com Tom Taylor wrote: > This is the subject of the last message I have received from the SG 16 > reflector, dated September 30. Has everyone gone into hibernation or have > I accidently become unsubscribed? That's what I was wondering. Apparently everyone's gone into hibernation. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0