- sg16-avd - lists.packetizer.com

Re: H.245 v1 and v2 will not interoperate
by Paul E. Jones 13 Oct '97

13 Oct '97

Tom, I think everyone's gone into hibernation... Regards, Paul -----Original Message----- From: Tom Taylor <taylor(a)NORTEL.CA> To: ITU-SG16(a)mailbag.jf.intel.com <ITU-SG16(a)mailbag.jf.intel.com> Date: Friday, October 10, 1997 2:15 PM Subject: Re: H.245 v1 and v2 will not interoperate >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

Clarification of H.245 MTSE
by Paul Long 10 Oct '97

10 Oct '97

(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 the reflector before the next meeting in Geneva. If you have any problem at all with this 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 modifications allow an implementation to use the MultiplexEntrySend message as it was intended-with multiple multiplex entries. 1. Introduction There is a flaw in the H.245 MTSE SDL that precludes sending the MultiplexEntrySend 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 sequenceNumber field, yet each out-going MTSE maintains its own, per-entry sequence number in out_SQ. 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 causes 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 first one. The first MultiplexEntrySend message may or may not contain multiple entries. The downside 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 MultiplexEntrySend message containing a single entry and the associated time loss, e.g., during 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 for determining what sequence number to use for out-going MultiplexEntrySend messages. Each 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 of H.245 because there is no requirement in the in-coming MTSE that the values of MultiplexEntrySend.sequenceNumber be contiguous from one message to another for a given MTSE instance. In effect, sequenceNumber is used as a somewhat unique handle for a brief transaction, not as something that must increase by one each time. The result is that this allows all out-going MultiplexEntrySend messages to contain multiple entries. 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 and their descriptions. out_SQ This state variable is used to indicate the most recently sent MultiplexEntrySend message for this MTSE instance. It is mapped to the MultiplexEntrySend message sequenceNumber field before transmission of a MultiplexEntrySend message. global_out_SQ This state variable is used to indicate the most recently sent MultiplexEntrySend message for any MTSE instance. It is incremented by one and assigned to out_SQ before 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 := out_SQ + 1" with this: global_out_SQ := global_out_SQ + 1 out_SQ := 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

Re: H.245 v1 and v2 will not interoperate
by Tom Taylor 10 Oct '97

10 Oct '97

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?

2 1

Clarification of H.245 MTSE
by Paul Long 30 Sep '97

30 Sep '97

(I just 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 the reflector before the next meeting in Geneva. If you have any problem at all with this 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 modifications allow an implementation to use the MultiplexEntrySend message as it was intended-with multiple multiplex entries. 1. Introduction There is a flaw in the H.245 MTSE SDL that precludes sending the MultiplexEntrySend 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 sequenceNumber field, yet each out-going MTSE maintains its own, per-entry sequence number in out_SQ. 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 causes 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 first one. The first MultiplexEntrySend message may or may not contain multiple entries. The downside 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 MultiplexEntrySend message containing a single entry and the associated time loss, e.g., during 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 for determining what sequence number to use for out-going MultiplexEntrySend messages. Each 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 of H.245 because there is no requirement in the in-coming MTSE that the values of MultiplexEntrySend.sequenceNumber be contiguous from one message to another for a given MTSE instance. In effect, sequenceNumber is used as a somewhat unique handle for a brief transaction, not as something that must increase by one each time. The result is that this allows all out-going MultiplexEntrySend messages to contain multiple entries. 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 and their descriptions. out_SQ This state variable is used to indicate the most recently sent MultiplexEntrySend message for this MTSE instance. It is mapped to the MultiplexEntrySend message sequenceNumber field before transmission of a MultiplexEntrySend message. global_out_SQ This state variable is used to indicate the most recently sent MultiplexEntrySend message for any MTSE instance. It is incremented by one and assigned to out_SQ before 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 := out_SQ + 1" with this: global_out_SQ := global_out_SQ + 1 out_SQ := 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

Re: H.245 v1 and v2 will not interoperate
by Mike Nilsson 30 Sep '97

30 Sep '97

Bancroft, Thanks for looking into these issues. As far as I am aware, all of the name changes between version 1 and version 2 were intentional, and were done to correct the syntax, such as in the case of g-dsvd being changed to g729AnnexA. This will give implementors some cause for complaint in the short term, but is probably best in the long term. It was the intention to make version 2 interoperable with version 1. Looking at your comments, it seems like you are not using the correct syntax for version 1. I have attached these two sets of syntax, and would appreciate it if you could repeat your tests and publicise the results to the group. I am currently finalising version 3, and would appreciate any help you could give with that before I send it to the ITU, in particular, checking the validity of the syntax. Best regards Mike Nilsson Version 1 syntax is file H245ASN5.TXT Version 2 syntax is file H245ASN6.TXT >Hi, > >In trying to use an option of the OSS ASN.1 Compiler that makes it >possible to move from V1 to V2 of a protocol without any name changes >occurring in the generated .h file, the ASN.1 compiler reported a bunch >of >unexpected changes in H.245 V2 relative to H.245 V1. Upon >investigation I >found that its complaints were due to a) changes in the names of >identifiers >in H.245 V2 compared to those in V1, and much more seriously, b) >changes in >the H.245 V2 messages compared to V1 that results in V2 not being a >valid >extension of V1 - meaning that any implementation that conforms to >H.245 V2 >is guaranteed to be non-interoperable with implementations that >conform to H.245 V1. > >I don't follow H.245 closely, so I don't know if it was intentional >that >these two versions are incompatible with each other. If this was the >intent then please ignore this email. > >Some of the changes in H.245 V2 that result in name changes in the >compiler-generated .h file (unless a directive is used to tell the >compiler to use the V1 name) are: > >- All occurrences of the identifier q723 have been changed to q7231 > >- In T84Profile the identifier jbig200x200Progr has been changed to >jbig200x200Prog ("r" at the end has been removed). > >- In AudioMode the identifier g-dsvd has been changed to g729AnnexA > >- In H263VidoeCapability the identifier bppmaxKb has been changed to >bppMaxKb ("m" changed to "M"). > >- In DataProtocolCapability the identifier the identifier >hdlcFrameTunnellingwSAR has been changed to hdlcFrameTunnelingwSAR >("ll" >changed to "l"). > >- In RequestMultiplexEntry the identifier >multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. > >- In RequestMultiplexEntryAck the identifier >multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. > >- In RequestMultiplexEntryRelease the identifier >multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. > >The above is probably only a partial list of the changes that are >merely >minor annoyances for anyone who uses an ASN.1 compiler. Much more >significant are the following which render H.245 V2 inoperable with >H.245 >V1 implementations: > >- In OpenLogicalChannelAck the CHOICE alternative v75Parameters was >removed in H.245 V2. This affects the bits on the wire and guarantees >that a V1 and V2 applications cannot interoperate if they attempt to >exchange an OpenLogicalChannelAck message unless they happen to omit >the >reverseLogicalChannelParameters or multiplexParameters fields. If >multiplexParameters is present they will fail to interoperate. > >- The type of AudioCapability.g729AnnexA changed from being a SEQUENCE >to >being an INTEGER. This changes the bits on the wire because a field >that >was previously mandatory is now no longer being encoded. > >- In H.245 V2 the V76HDLCParameters has the field crcLength as >mandatory, while in H.245 V1 it is OPTIONAL. This affects the >bits on the wire so V1 and V2 cannot exchange the V76HDLCParameters >type. > >- In IndicationMessage the second CHOICE alternative has changed from >FunctionNotSupported in V1 to FunctionNotUnderstood in V2. This >affects >the bits on the wire so that V1 and V2 cannot exchange the second >CHOICE >alternative of this message, for FunctionNotSupported and >FunctionNotUnderstood are syntactically different types. > >- In H.245 V1 NonStandardParameter was extensible, while in V2 it is >not. >This affects the bits on the wire and makes it impossible for >NonStandardParameter to be exchanged between V1 and V2 implementations. > >- In H.245 V1 NonStandardIdentifier was extensible, while in V2 it is >not. >This affects the bits on the wire and makes it impossible for >NonStandardParameter to be exchanged between V1 and V2 implementations. > >- In H.245 V1 the DataProtocolCapability components >segmentationAndReassembly and hdlcFrameTunnellingwSAR were in the >extension root, but in H.245 V2 they have been made extension >additions. >This affects the bits on the wire for all possible encodings of >DataProtocolCapability so it cannot be exchanged between V1 and V2 >implementations. > >- V76LogicalChannelParameters has been changed from a CHOICE to a >SEQUENCE. This affects the bits on the wire so >V76LogicalChannelParameters cannot be exchanged between V1 and V2 >implementations. > >- In UserInputIndication the component alphanumeric has changed types >from >IA5String to GeneralString. This is undoubtedly a mistake, IMHO. >Aside >from the fact that it affects the bits on the wire due to the default >permitted alphabet being altered, GeneralString is a far more difficult >type to work with because the characters in it are of varying width. >That >is, one character can occupy 1 byte, and the next 3 bytes, then next 4 >bytes, the next 2 bytes, and so on. It is due to the difficulty in >writing programs to process such character string types why BMPString >was >introduced into ASN.1. What was the rationale for going from IA5String >to GeneralString? > >I am likely to have missed other changes that make V1 and V2 >incompatible, >for I was not trying to be thorough once I realized that there were >more >than just one or two such errors. > >It occurs to me that maybe the idea is that protocolIdentifier is to >be used to determine the set of messages that can be exchanged, so the >problems with bits on the wire mappings reported above are not >important. However, if this is the case and bits on the wire >compatibility is not important then why bother adding types after the >extension marks ("..."), given that such types require a few more bits >to >encode than if they appeared before the extension mark? > >------------------------------------------------------------------------ >-- >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 > begin 600 SYNTAX.ZIP M4$L#!!0``@`(`"F*/2,N^+K;@QH``""9```6````4T<Q-2](,C0U+T@R-#5! M4TXU+E185.P]77/C.([/ZJK^#WS;Z:JX)Y*=CYZJ?7 [SL1S=I*SG>S=/-R6 M+-&V)K+DE>2D,UOSWP\@*8F42-E)Q\[.[?5#1R8`?H(@" +DZ&XX'8SZ%X-N M:_+?DVE_U.K=7$_'-T-RT;\<7 ^F@YOK">G>36]&W>F@1Z;=GR?DIY_^^O'# MU_[/@^N/'SY^:+5(_]LZ3C+BAB%)GU>S.$P%X*]O_X_E.XW7)*2/-"0CFJ;N M@J;[*^[CA]$FS((5]0-W\IQF=-6+HRR)0U&T!=W1N[H9]/H?/_SSXP<KH?_8 MT#2SQOROP#IBD'0=1RD%$/^08%Z\6KF1;_7X7PD21'[@N5D01]:@^)3@GS]_ M_OCA#]'A7:(62Z!,J'U*@HBX'E(2R)U@'0,`P0\2K%C3,H;+JH5YJ=E4VQC% MT22#C-S$MZ[+[[)6@+-RH:^22>@^T@L*7ZL@XJT8&0"<3"2$/7?MSH(PR)XG M-+.FNE1.$*]I-(P7T#%A;^E&$0VMFUH2Z^(P3FD%LU=/X[F*411I#"T?43E- M-!499!W2;WU@#*@9C..HEJ3DJX(+7E%258+8+RJ WP(8;R)_F@3K"QJZS^.< M\W2I^: $448C-_*@U?$ZIQAIDSE)C;\4WB5!2K)ER3LDBXE+1*7SV<D92J%[ M2X[J>@]&I@+840/IF/Y&O<Q(S<$-C(E%3PV (Q.1*'1JAIDX&XN[T:4>:=%% M03<&@&%28"$];;)Q:B#)6)M\I"<0-1N;(*9YQ89:EWJD1<^'UP!HF))2BVJ M(Q.1VBH=K#:GY7+XSR,5H9)GD:(7`/D"HTW6B@`^>:I)1SI9(::*)E4K*=2E M3%ISV#IT1&:;C$0QH=_68> %F;+\J+2O$Q9*/6_F<Y%GM04EA!.FP![:J6E- M3!!.2",O>5YCV_*2^M44CC@/XR>A0^28E[6D/$]_`JU2\JRDB.8&J4?#T(UH MO$F+EFH2=4,5D9IF@7(]B.9QLF*I(./=C/@Q#%\49_E8YBI%G"B#5\OL->,W MWT0L\^LXFVS6J%]2Z"9-8O/:,*8A=6%&C)KA#2(^SV':`#3):QC2>9"L-!)8 M0(P2-2]U; 291&318A.D0>I52M4":R*L2E0F:5BSY V5.\MT3O1;D,%H2-B_ M5!(XVM)QVI,'^B0A7M62.&I$G[K3T7U/0KVN)7'438HEK3>9=9=_*2CJ])E@ MNT&87&]6,YK@Q/'I/(BH3Y84YPA,I Q3(5>?Z>$DXICQ7-J^J+G@C!E<3_L_ M]\?DA^//GYV3DT][WE/!1"2IF(EYO7A+`FSV7G=8=2& '3#I_^==_UHC-"[< MS)4%QZV;N"N<U>K8Z# :\QWX-,J">0!HU[I4S-['LJV;WK0_)9/I>'#]<[TT M*9^*Y(MG;!&U;K[^TN]-R>"B?ST=7 [ZXR/.S+:4BU76TT):*VN?]&!AAZG8 MP]U E3^.+!@@CR,<D34PV/1S^T00]K_!DI>R3:2.S(4598$LRZ4B[.2?D1 6 MC,T<A/PFH4FMS-.3D_;))S/U'^44V1?/<JG>2E&L`Z]*<OU0G&M:5^I\EB\N MT^>U9NQ0\<C<;),JN0AA(&/;IV=G9X[-24I>;]C_U*OB4R]@O)"S)N<OOH9: MUW?#(69NL6YE/W$T=RM/:(FU(CT7Q)]5*3!@\P061=[.M"R:%;1[F7P!JA5: MDNZ5"TN-`)19#U;JPPE.O:):ZXA475S4M8:O>>LDSF(O#B79I152\ ^:DR[1 MV#>C)*49;OG1!/#HAAM:8/PSR#:M#%CV$^B&:-T"!83/3$Q:DA_./Q&G<T(> M8=SS5/L/5:<I6U5J,U)GW]RB>;([Y WP"L#4G844I"<(Z,&O??*#C7/L]!.Y MN92&BB$QO<:8SP5-/=A#93%PYI;<2M1*;B4+WI^=2.VI#9&[\8/XBKH^=/S7 MFYMAOWNM<K^NZKIY5L<2H]XS@HX40DO3Q;4ZE UNJD.)5:M#%<0D8(!#+[8K M.69 #;W?#4$&H 1XI K[5RMMPI,KOANG\)J:!D.CN=GY*FGJO&9MSV19>OD$ ME_BHP>STBGRU<GT3I6M88D"(^*5(WT1"+2Y[#+1K"<$O>@6KYD'%^M\\2GT9 M)RMH:SA%%7@=K&6P6,)V1!J:VR3V0+M$W,:I8*%.2$MLL0+RY4B_-#5M#IO6 MI?=;E7X"L9T?HI03EN2#`"C[7+<D2;BC<4#6\=G^TZ,PH>]!A8BES"J_F0DV M<:-T%60[H(I,NV@[VY5((D,)+N%6?LMUV0&U7I?M1"49[I"Z:S2LL357HC)" MY/J]DKQ>Y]=EQ/9"[79I/LNSD^BE-5+%'?-*2*C5?13B#^YSJ^@T6!GV4AN8 M*BE9!6$8I*#"1'YJ&07 >T[D0C<J)W)P@!/1BH;V\FF,&UY'RN%*^2D0VBI" M6T5X/#N59Z?\2QT?-6^L+*F8`9CXOYG?]U)+7K]1'V E>0I'35%'N.^9BI,A M&EW/#6VKQI;1)D0#G_<`'!R#6JSPN)4F66J&NKZ[9(a)J.$0-S[R<)+*YQ`O.4 M[5%E>!A'BT$$`P-KUJ.J@UKI,DXR$Y"JF=Y$8:7B6;)A%@1FMF$S>5[)8NTF M68!6@TN8:]3OT3!,%00QY63=&COQI-Z)\SAY0BN2^PUTR=7DXFX2_*XS6T@3 M//8RFJ5(/'.]A]=3ZRK)!"K:J2=90MV5W"C8<"U@+M0![J,;A*B6? VRL9LQ M];=B"$(30E7?28-H4=!8=154JO-IASS,\ .-1%RTL2P2E"TW<UVY>2G )T\T M^:Y2N&;6D,?V+/[8HHZI@D)CB\F'Y6]!MARTYBB32H[#\D4B*3#16GOU&7:L M;'EZ1#T`B;M#6QX[*=TQI+>5L<8U7)./E.X8TI5\T"JIR:9,=O3)<B;L%(4Q M?C=T7L;[!5W[170E)3NGY"9^U=IU[+1-BW%Q`%"L1DR9E\9=W97,W#3PRJT$ MC99X!*B86063BTI=P_8!)M4%76=+A4V%]:U [(=T1:-L&*29VGBGM.X5R)/- M;#=\SMF,UROLK:QSFDW;!K9?>-R3;E92=SQU?3^!'8W,"2;46(.;T-_T^E<Z M[O^BAZR,$"_QSF<FA0Z ]JD>2CBX[1B)-\%2#X 5_F9^,>Q-E/X^M[_8K,.S MI_@&^5*T_#*@H:_/*(SC]5=8*J9X,*<OJG-L2Q"9=SK'7_@``SO\+8C\^ E9 MP(!L.V=<^5!L1XHEZ5]'#65[HX.IH-6=V0O53\+5RU.[FL]5/4V@.AI41X_: MUJ"V-:A!:MOV62WCP4277%WBZG6O28)_>,%\=#M0&?!3J:&4@M7^T?GR^<L9 MN?H=)QBG>BE91E>P4KKA9.VB.@>JGD_1NT(O&MQO.@W _N(<'RMKQ9S8Q\<$ MM8 ?4W9*`DO 8.4NJ-@4,E\(9>W&H_)OY$*LV*=VM=^<K?T&NMD\"'$C.T0# M26MRZV:C845[4S!&@#'<BK$]CZN6W=F*TYC+Y'J\K2H,I;DN8@RW5^AJ:[.N M;G?+16T6TYAJ' (J`;##6?NL8Y^#9J!CR4[!+=3#?&:/7S=SV''4U!("G&!W M])G8I^WS#LL&6<Y=@7:1WM)D&$2T<AK7/M?G((A^#($$UPSX@SE<HOS9,0M& M\R/30]$AABFID,6$J3]J'B>5#!CRWQ/HN[][L<\JL$$#)2@\$U:Q6K=VG"^= M+Z=GSI>3QN;P3E6F4WOK=$IU<JCM;)<HKZ73"; =Z3JO+,\^?0VA60IV5#&H MR,!-!!I*E@2@KOCWL.V.E>VTFX!J#XM<X/5B'_17!>8_,J7W%K;C0<T(L)Y= MJCNAEPKU9>*WOEH*7YTX'>?\3-\3SGD^Q6;K-6RZ_V.FV3=H*8^=8G:6O*A? M-C7G4Z"NP+X.SR*@\]/:!OS_14]%]*P#9L"I]8<J=O8G9-Y3JV56]H-IM9#S M99Q@6 9H+HY#BJ/P(W;$CHZK"YJ@:R9S1Z,L-07V0F4'OR?3"S)C3(>N9H4* MY9R<%KMNM8SV;F6(S:ODNL9,$7RAX?:9[K %NW]VXEHYJ7B%:7AQ9MO=T'TZ M[3QHS;$Y_.34#+_;0G]GIF<8CM,RDP/07#8`.^<-&;<UYE_HX6[82OT-ZSTA MB'796REH3CC'-NMU0A7U-S<5P+^/O*1SRU3%+V9(%Q7HKA8L=BS5$1:B5W.. M!03M<_M<0Z!)1@)2$^@:=M+X3@S=9YK4C6@LV=$G5ZQ?#, D%ZR:;>>A1I3# M.IT'VPP\?U"SY8;9/.)(7EJ?8I&:JA0SC4K0Z9S+^L"#M,XH':;K[(-TF'UJ M[C#'>3@^,4,[9LIW&P8K6R8T1T^=EFV$M5O',FP>;Y*2[+CE-($=$ZBM%CC' MLYVRO%JF"MA1&Q[&3Y<)=]QX[G.C)UH?*Y9?7 2PWS9NN)T9;;M]O)T;WW/9 MQK.F@ZW:YE/N^LPKT2KFZ5U612NSG6-V='XKW/54V6GYZ:KE>4T8Z-O._*<; M<++SCL8J#JDY?A.QP,/MO34M/LL#FZS3[C31+QVG$1Z%ZT!GM&?I.U608;(^ M4-VX\QKZZ:,O@G'*XP(\JV:9XEDE#A_NK!I*D<ZE=)L\51G6;O0JLTE?UFMT MJT>[PU5$R;/JL>.$[GK%?V-M5NXSB>@BSEAH<!:3>ZCP+,!-R=(//::?3#<H M<5!J%/DLV_;QA*Y=-#W<]Z!X[T&%,2E<A?!3-C=!L92G2<Y5)4-5FPN\=B=M MALL,SSOC,K6J:J%903E?QM]J@A<DI\?VA/Y#EPRU47;5T"/98Q47TRJ(F+QH M7[I>.KIRCH^_P5@K)#+,J<(Z##8::PEE8)7RMUFP$.G5.DJ@6IL0U@986T\F M0)H6^L'B=@E\.HR?%*H\?43]:H82J%:/''85+)8F.H1I:B+FX"%\P$5T%_'X M*DPP(,)E4^-0KN"0\U\NN??#7XIP(YBW"<7-(/IH2_9RW!SBMLX/A-L&;.3B M%4O*XQ1 `CQ@]2&-91XGP8*EY\'=<]Q$DK#2<.$,'L-_29'7$;MUX"\)16]O M6J\>*R"G7*_C-,CDNN'>5JK\45Y[STW9QM<%B=DJT*7*B*I^QOZIQ^#55V?A M/:*B"=]77:((5=11%1*W[KZ![@2:R(ZJN8LQ.+K,H+?'A?A@J<6.72JDYOX* MZY6Q1E<-P*.<O-U$WFXF?SP[-2&0>S-,/?BNK*/P![CD3O -]S!^%I</,+XJ MAATYL\(1&)N9LX-PE&0T.P_:ZT<"*LV-.>NR#V"I@]45:D!P"P_+'K)TWHRB MWGL>"6OGD5"-===Q5E0;NYJU3NL!I<,&-:=IKBHKOW8B&AWL[\].I,;57?RD M$(M;7B%Y,1%V!XLO%5S?8@/^&A4+O>UXE&*N7Z%-F:543W6MO&8,JC&(\(C# M1L?;,O2<95(ZPXJK0I1(J*;)7Q>)T%&P+?7HX$+GT\-<2&8BFPI*X5FQ]I(6 MZNPUH"+KA#^<''0CJ^<*+K?9[X2J.H7MWF[F4<FZFED^IHK+W>X;-C>TF:HL MQ3! $LR)>JJ#+EGQ)E.#+-(:2@.\;6DV1A[?RC"'%N;ADJKNSL+=".\],!Q7 M%#&'.K?'/U1E*[]$88$V!O3'N@S=13VBR1)^3+L/".XZ5-EU=3'L*1*+J/Y, MTGBAVY!5.$ 5/5;Z.>DB#S>#*TO9%JPP!+;"!70\TO3Y4^'94_/G(;R[D]Q) MMUPN<A?+A/Y6UL=B[E7R[]6DDB"D=&[ZE9=/8FVN^U!#7?,>%7&I",^:NYG: MU9HCM<0;TFB1+:W>N,>_<C\H2^O1A#Y4,^%#Q2)M_$U"ZSZ_?^32N,BV*HV% M(YE5-#%W'I,3F+N89F>IO4OGK=3"EVH86OSF4EZD2QY :Q2J3ON5JL[NZD:[ MX)"W53A,5R6]"4^\*%@NW01,?(YY3TG#4 ;,"0U%N2)%!^WF'N5R`0]1_!05 M2DZ-K#OLQ:M9'H>N+4'K>FV\ZN1MNE"*A]5<Y_8F17!]IS9,J1P:'WJI*3)> M?W766[=><R_,`8HX3$/>9\IIN=E\_<Y;]\->K5.5@W["),O!KLBHWX[X\CAC M]9XC8V0^\TBY)",#=N4^"0-6O7HK)<) CO8>F2!L6U;Z^5OF2/.R&AR]&K]> MA6O"6=@V5>7Q4,>&0D50-W"X@^N;:RIB$G0US>=+0M?4S=C=-)5:, 8SQ@EQ M.N:@@DW@4S,+V#P+H@7;.>#\9-L.M/O@<AZZ:49$SQ+)O&L<B:K!P.;6`NTU M@M_#F;5R&SE3QR\FUI2N,GQY_1)&B*:!,K1[EUDSUM$UU5)+\&9S:9L@[S&X MYC*!:1R#)H/9;KM>QGB5V@O:\!UCKKUTK5XV+>G3-R]..P7V6J*)K[^OT-V9 MOJ%2C;R_.]U[38$FA49_[=_>1GZORHUH$D'KS $/VZ3K#O$\RR4A+)[L:"I. M?'219!M>/&4'<7R$:QQ6,.4W:;KE,=M3O E]('Z@^2G8$F\SRZ]BR/AQ1\ / ML:1"7[44,&KJ(WW:I)(`7&)A/0N)VVM?4PUQ3:W*R4]!&.87/8QB- MA[R6\ MMI+-3D(;TC0UH#5R?WFO[AO=>(-#>Q>Y]7TVG^IQ$(%Z)+S.2T-4/B 7--IY M*R+?N/D^%\N8YMM/C&T.=8-,A45Y7TSUK%RHJYQ,TJ/)=D5Z)S,_.]YA#'B? M?W&3/![GL/1N_E5865CRA?@0(<GRN8WF&$<ULK/89X!4S@/5I(;#D KMO^41 MR/83D#T=@" 6>;>9RF-UV8*T]R!=QLNONQY&A+BR'*[D7TI(;@YVJN"V`FXK M8#GTEF'(T4/U8U.E=/TI:;C1>'4R5[."/9F?F6PVG.T2`ON2^%=]K*N^TI4@ MS$K-#3&P15L,$;"-\&WT+$RT&:,AASSRM1FAJ0YJU*L1[6I+4ZYN=\E!;HI\ M+*>)/N-786R+/=L6>L9DW9; L\:XL^\/.WN#@-?OCW=]BW#7%XJ!M)0#5H-8 MR']UE%_VJ9917BX[#ADWJ@_+U'?;:P(R_RVGA"80LS8=]L;[[Z*H\/#+O2LJ MA7;^O;&*^425XQ/EM#L-WIV*)\<>EF@BWE!)P!@GA>C<DA&^2+]:&-1@J=@8 MA5C5YR>UV,)A_,08J!!!.B1TP%:QTNT9I<W9E,JT''0HZVK*GDH.-,R1E(3J MA<S53)K"Y"K]),?/E7L/*7I.D]BN-$J)5M/E+X? J?DI`7 &D&"-LCQFB1"^ M#YJMG!H>5UZX6P3'38#;::R#7&#,F%I84P1C&3+6&+_XKSPD]JEI2'BDHP'6 M,5']>8:8IU=#(_40#(PL(+JP2 /0T0/:<D&Z@$@#T*GTTC[C(1MX^UV63Q8& MN??5,S=B67_B>,<F\+]=Q.+L^\,5WX7=2XOI_IE>M<Z^SKXEWUNM<4_=;R_B M&X$$'PDD[/;-0QV=:5\G_:X7#?2O'7Y7EGM]LZAX?I#@^X.'>ZE(^_3K3LY$ M*7OW&,FDDRU\-9@E&9V351^D9ES#BS^UMRK_3/4UG3&^?Y6UAYB>BXZ^MS3! M9Q_5FNS26NF)S7=[B8F7?^CGZP[8HI\(.B:1_+T1^2*,"<WVV4CCZZ?5I4_X MHWBYA*E==*1Y/$"-VS8_8E3Q0LG#')J>ZZD\R-3P.M$+7GFJ9ZW,D06-:%+V M0'UE/RC'E#K&8?0A20K(?%&>;D_ZBA[+U$F\0>SJ,VA$Y</ ^+ `P7?)BA"1 M,(a)M\OT/J7.Y-RA)2$M$G,KA7T+OA(F;F[<&%]CF0$EX^?U;7#RPW36,/+\3P M"P*M=G?8]T%J`XZO"1.Q']CGD-=?+=8H75Z\HW.R<=W:&H)J/2WCD!:^:,H) M:W[BH7OND%UII[N:I7QDL;[3D=XB('P?.Y:*T,>$''3T>_PZ))@[?4@7CT7O M=^97'ZE^U9-.?@"\`D/O9;*9.LVB&^%'J0Y?1D.Z7L;1L^KW]7@^"R2'D,=V MYV)R?Z$F;)!++KO_I:1>M9V.3N%YOX%4'DAFPO&XA7Z"Q..H^]TNZ!X4K\WN M%TUDG=H+,M;%%QW8UJV4Y2F^O>&*1I,NMYK\3I-X"]ZOJL\=LD9>]_)$%176 M<-2,Q(X<+Q-*?Z>W_-"M"G/3[&[M@^2HP#48/]]\U9A_YD&29@A2),^9<$;* MWR,"!/4:2/O\D^QUQ(J:ZB_I57)NV_D+P9QYT <5\5KQ?)Z_W5EDB,K>Y#GR M^ABBC'54&U\%]UB7RCU@F#][G4'E&]W_AS8`FD;!`K^)^,TX49R1-(_,W',+ MI\L@56_N`;;'Y\P]%EZ1T5P#.R*YAR\N0H+?N-\SD&.5,?A]$<&T]YD:(5JC M1)E6EA"1=?'(/.\*Q9LX-_Q(,%&V)::W@.Q?EFL'S2C.@P+[8 *]K. >9'I8 M"7[%A\F,(GO097=#W0^Z==)!Y&XA'@GB"9<ZBK>U<+V7O&ZJDE^#I.;R*ZPX MR#NF"HP&O^KRW4;&\3FU6B!W=7*3YPE[#-Q<[D17[H[41?$32>(+CJ!CZOK/ MTYB-6G%:7\_C?C!^Y?J37RN=$F^3X(U_Y3)473H.HWAI)RM_BTJ"[7-J\L*: MYN1[[Z+P):P5[GO%ZYH^K_+(A<TR=)DZT)\:*/K?0$;C::M,P76>]"%8KZG/ MG*-X+*GQKGGFD>8'_$*'"XHN?PEW[E*OMM%Y=O%$7(F<_['/28O8[\IH/#2[ M>HM>^D"?]LEQZ/X_@3)>N@[81O[283OF.Q:@;/6="/XNENFEMW<<H&OZ1+K3 M$7D,DFPC#=%A5FTH'0J_[S4-5'UFJQ.[<IK[@L<:!>4P]AZH/XUO>^/_'?B" M4>2UF6A*_%)+RO.+LC&4)2;F<**77^!K4+%LUD"YPQ3S>"3,>U*1#TO"N"85 M21+[+:FX3U)"N]H4AUO0;U5%,(a)_]4E5DAZ+?J8HDA^U*5=RN).*"5<(WK*(> MN(a)B^6Q5+CY62RU4IO%T5UZF0B.D$C/4EJ%499"D'VGVLR OTD6YCQ3_O1>\2 M"+2$!5C<%)32='XGM!C4! %:@EK4D+JH(3&G`%A EN:"YC\XW4'S(,!F84E1 M9EXZ^MH&5S\77JYX5 `2-^$$YRA%!;]\A9+4"O#-J_ ]S@K%)94YH"Z30DI^ M<BEHW1;D#"@2]7 :@X_J<?8,"8EQ]O>-"(L)<@P(B D"5D*N>B[^SK!CQP!0 M2P,$% `"``@``%P[(O^_<FN\)@``?-X``!8```!31S$U+T@R-#4O2#(T-4%3 M3C8N5%A4[#W9<N,XDL^LB/H'QNS#5&W(;HF29;LCYD$ERVWU2+9;DCV[^S)! MD9#%-D6J>?CHB?[WR<1!`B1 R6[;%1.Q]5(6\D "2"0R$P<_?YK>3!;CZ>AL M/#B8_^]\,9H>#*\N%[.KB7TV.A]?CA?CJ\NY/;A97$T'B_'07@Q^FML__OBW MSY^^C7X:7W[^]/G3P8$]>MK&26:[86BGSYME'*8<\+>W_T?Y+N*M'9('$MI3 MDJ;N'4G?K[K/GZ9YF 4;X@?N_#G-R&881UD2A[QJ"[IC>'$U'HX^?_K7YT]6 M0G[+29I9,_8_QVI12+J-HY0`B/TAP;QXLW$CWQJR_R5($/F!YV9!'%GCXD\) M?GAX^/G3'[S#![9:K0UU@O2I'42VZR&E#=QME#$`$/RP@PUM6D9QJ5C(2V53 M;6,41_,,&+F);UV6?Y=2`<[&A;Y*YJ'[0,X(_+4)(M:*J0' R'A!.'2W[C(( M@^QY3C)KH2ME!/&61)/X#CHF'*[=*"*A=54KHET<QBFI8 [K98PK'T5>1M'$ MB,IEO*FH(-N0/(U ,4 R&,=IK4CAJX(+75%*58+8+P3 OSDPSB-_D03;,Q*Z MSS.A>;I2,2A!E)'(C3QH=;P5%%-M,2,!_1(*FD="_4 "03LT`!A1M"()`;8E M=J4$T>@_^'_M.-T!].W38$:0-+C+$Z8S%R8(BB@KOS*Q[""ULW6IV'86VZ[- M>U28#J;M"MU;JOO NS=J/,!:#:0S\BOQ,B,U`S?,&JQZ80"T3$2\TH499IIV M6-V5KK2E1><571D`AAF+E0RUQ<9YBR0S;7%+3\ EFYD@IDE/AUI7VM*BB^$U M`!KLA=2B&J!E(E);I8/5#(Y<#_O94A$J/(L2O742JY^V6&N?V.2I%K5TAHQ/ M%4WI+C/&Q1J:((Q>-F4%1;6H,&:-U@Q;==$`;#41\Y9>-,-19-DPJFZ%M/Y3 MGZ!E+_/,CF*;/&W#P LRQ150:5]G&Y5AN5JM.,_J@)401IC";-!:(FMN@C!" M&)3D>8MM$S6-JB4,<17&C]R?$YCGM2+!TY]#JQ2>E1+>W"#U2!BZ$8GSM&BI MIK!9,X>22Z@#5/6RQ*^4**H0V34O$I?)(%K%R8:6PI+I9K8?@WI$<29T1;B/ M<:(H1XW9:_1CE4>4^66<W40^2=(LCF$<=*4M&_ ;U\R0N# WI\WPAE53<%@T M`$U+('9]D&PTBQJ'&!<I4>O,"#*M.D6+39"&A:12JQ986Q6J1&611OU+_5!G M0%G.B'X-,A@-"?OG2@%#0[,XOR>/$N)%K8BA1N1QL)C>#B74RUH10\U3K&F; M9]:-^$M!$5,4:C]J3]VG8)-OZE(80+Q3O$G,?LL],JP75F>UA#[4%#+T!QCM M.!G[),J"E4"_U12VV.R1)MP\WV+P3I3Y5A3*IF..XPV57^:;)4G0:/AD%43$ MM]<$[0,8D0Q+H3=]&F_:$<.,5U*8KG)!:S&^7(Q^&LWL+^W#0^?HZ.L[YP[ M"-DIMT)"+M:2`%O_KIF$N@'$#IB/?KD976H,YIF;N;+1O'83=X/63(W[=1B- M?(5.`-JEKA39^UBW=35<C!;V?#$;7_Y4KTWB4['Z\9)Z*=;5MY]'PX4]/AM= M+L;GX]&,3Z..Q,4JY;20ULJZ1T/P$<$$#3'JK>I'RX(!\AA"R]Z"@BT.NT>< M</0$[D1*DR4Z,A=6ZSM46;8:N&'XC(2P2N8K6.#RA"2U.OM'1]VCKV;J/\HI M\EXZRU:S@Q27,]!5:3W[*,TUK:=U/1.+ZN)YJQD[=.HR-\M3A0LW!C)VIW]\ M?.QT&$FIZPVA=%T4GW@!U06AFDR_F.]@7=Y,)M1AI]U*?^)H[E<?=\-K57HN MF#^K4F% YPDX`ZR=:5DUK6C_.MG"6ZNT)'U7+2P](0@4//!0/LYPZH. 6D>D MZN*BKC5LJ=PF<19[<2C9+JV1@G_0G'2-2>TEL5.28?8(LTD/;IB3`N-?098? M9*"R7\$O1A\>5ETV,[%H;7\Y^6H[O2/[`<9=E#I_,'+5HRO;5OIR4I=?76,R M?C#A#D(!6+C+D( -!3,]_K^1_:6#,ZW_U;XZEP:,(E&OSLCGC*0>!.59#/JY M@UN)6N%6*N+M\9'4GMI N;D?Q!?$!;?>^G9U-1D-+M4YH!-=-]OJ6'SLAT90 M2R&T-%U<DZ%L<),,)59-ABJ(VL$`AYX'A (S((;>'X1@"= ./!!E$E2%-N') M@N^G*4Q2TV!H_+>.6"M-G=?L\YE2E2^?YI(>->0Q7\%7:]WS*-W"0@.FQ"\- M>QYQY[CL,8@M) 2_Z!44S0/!1D\>(;Z,DQ6T-9Q"!":#M0[NUA",24-SG<0> M^)B(VS@5+/0,28G-UT&V*.D7J*;0N&EU^GYKTX]@O,6683EA;3$(="/A_58O MR1+NF1Z1/7T:?7L$)O0M.!*QQ*SRF^;T$S=*-T&V!RIG.L!D[+Y$$AE:< FW M\EN690_4NBR[B4HRC),&6TQ=TI57HC)"9/E>25Z7^76,:$34[98)2L%.HI?6 M2!5WQH204*O1%.*/;T6&>A%L#!%5#E,EM3=!& 8III3]U*H;`'533ZIUJ"F4 MDP??;=X7KE0Y[X,/."Y0<>A>/NLQ2G8D#A?*3[%%H")T582'X[X\F>5?U:26 MRD?^+;8TE#V)2K6U0@Q98_B;2-TOZP75"K5%V$5V)6-!UZBKU>TPM60G`YT6 MVCY/4?L%.C*WPUHCA4<Z;'1(W;!CU>9.E(>8@_7N<9,%/'AE(EIIDJ5FJ.N[ M6^J%&3&0^RA)P .($S F-)R6X6$<W8TC4 =86!]41]E*UW&2F8!$97H5A17! MLR2GR0Z:8:+F9E5AL763+, $QSD8!.(/21BF"@*W"W(`(a))UX5._$59P\8L*+ M)T?/;N;![[H,BV2%8B\C68K$2]>[?SVU3DAJ]3&[.<\2XF[D1D%L> <SL YP M']P@1-_I6Y#-W(SZZ)6<%68[JDY9&D1W!8U5]Y,EF?L]^WX99#]0L:T$[=C5 M2E>;X W:\4B25_!FKF(#I8GPCQU>H6J -(DAT?'_"++U^&"%MJ[4*:R5%]H% M)J:.+PXA?&99;G1'D'@PZ<BC(Y4[AO*N,IKH2FCX2.6.H5SA@RE2#9NRV-$7 MRTSH5A95[4'HO$R["[KNB^A*2KK_SO99U-1;V^F:?()B%Z8P[#2FD#T!)3A: MNFG@E1$-B=:XUZOD?+E"<Z$N(8J!:7-&MME:44Z>"BP01R'9D"B;!&FF-MXI M4XT%\CQ?[H?/-)OJ>D6]E?53$SOF$ 7BGEN:;Z3N>!SX?@*!E:P))M18@YN0 M7_5N8#H;_:R';(P0+_%.EB:_$H"=OAYJ,W#7,1+GP5H/@#7\:G4V&<Z5_C[I MG'9HAV>/\17J)6_Y>4!"7\\HC./M-U@,%K@[JJ^JU^Y($%EW>NU3-L"@#O\( M(C]^1!4P('><8^9>*"DL):%5,WR*!U73#3%3T8YH)IUNS@519=J)<(/-NSB( MLEJ^4"V4(YP7$=7CFA>1;[R&8,2#&9BX(72^7T8,TZ'B6?AD'RQI"4HR;\M" M57YJHZX>V+'GXQD]_'HY&/X=Y<13K]>@420+?J_&:],&8"59W\2FI@EKI]]Q MJ:P*B3X'JNWVNG(AEN=J9X4EX#=1,$24HC=5%&S#&1C&)%CFE284.4-PKJ=F M/$VG&!C6$ZC*:.,`*LNFX%*'XJ""<VFO\B0#C\9.L]Q_QIES<=AUNBIG.O<, M?&LPB8Z.E8&N!I/HZ-:MW'?&#(#BG$K<7\/!$N?/=O6,ZK75XC>][P:JHW?= M7NB[34W.FPG0G9K<-Q/ ,0%45I('9RAW#.4*'UNR\4#Q.C<.6+Z(T-8Z<O8+ M/#F;&7OY]*!V955"_QU^']6%8K\3M\Q !ZC*_4>[@^:HY_MFMZ@)^K#,5C4_ M_,*LEMWB*V"5ST6]C*,Z&E1'C]K5H'8UJ$':Z72.:XS'<UUQU=&KRUXSE;]Y MP6IZ/5;]SZ^2C2YF8^<'Y_3P]-B^^!W7#D;U4K*,;,#8NN%\ZV*^!CPVG^ I M6GUDX#[IPO[.J=-N*R9F97?:;5N$_C #PW"\<>\(=PCID5=E&<;3BD_V&;?Y M_4ZUVYR=W;9-XE40HM<YP5V:@_FUFTTGE>R,@C$%C,E.C-T\+@XZO9TXC5SF ME[-=HE"49EGX$.X6Z&)GLRZN]^.B-HNNN#4%(a)64$M.&X>]SKG,!JHM/(GJ0L M#\N';_D*7(7:2F:#&G1Z>@Z=?O>DASRHOKD;6&#2:Y),@HA43@5U3_0<.-$/ M(9!@N C_(8=SM#U[LJ T/U W!L](4B<'6,SI>JGR.*HPH,C_A#64_-.+?2I MCENDL+C-J6"U/NTYI[W3_K%S>M38'%BLJW.INW,NI3H;U'5V6Y/7TNF,UYYT MO5?6U^F_AM!L`7NJ"93M7QXE!-UR#WU^XN$I$-FY3, AA/4M\(:Q#ZZ*`O,? MJ']SG4! 5$OP;Y?GJB/]4GN^3OR#;Y:B5D=.SSDYUG>$<R)FV'*[G;I/?U]J M/$TM9=LI)B??->);0FD8/\ZU6M.'_M0J-O,^BVF&''[9S< ^.##3#_\T>>]/ MTFNT<4\&?*]FLR51JN0"^(37^R6:*!K\08B]\,@):'A:V\+X?^,N&_=M0/>_ M:IVA&O;W,^/?,V:@Z8X/BQDP\18G>-$<`T''+HX[MNAA2KS^=4<23'C2*PV$ MEJ:@7NA+XM_SQ9F]I$J'"8S"076.^D4HK-;1W:\.'@I*EQ1HFH MY2D]5SZ8 M'$!(7N5_=-A^LQJV- M(S^U5SKN\XL3 W7&G,PC=QW[O7KM?+N!'?3/\9@?] MC9F>8CC.@9D<@.:Z`=@[:6#<U>S/0P\/PH/4SVGO\=54Q]Y*P?7%69QOMPE1 MXA<1TN."QFHZL4PBGIHA+#NB!?.(LSK"W+)K3D,!0?>D<Z(AT!0C@<U7Y5*0 MQWF]P6*[@8NF+C :_=,<V9VXSR2I;YK28D=?7-GMI !J3,%7ZCKW-2(!Z_7N M.V;@R;W*EFVUBV<=9(?J,>:EJ4JQU/B!O=Z)[ 06F]^EX=:/P<?T5J=O[BW' MN6\?F:$],^5W&P,K6R=$H*?.0<<(ZQZT9=(a)JSI.2K'W@-($=$ZBK5KC"HSIE M?36F"MA1&PX^X'G"#(a)L_CUA*$W.+E6U^7#*PWW(WW*V)G4ZWO4,5OZ</@7L1 M'^9"F(]5UJ==B58YB+#/`FIE':=-SVI>\ULBE7-P?KHY\+PF#+Q*2G=N&G"R MDYXFX0VE`K^)F.-A*L=:%'^62>JLU^TUT:\=IQ$>A=M EX^GY7L)2#%I'ZBW M!X6$?OI0;.45.P%XVI$RQ7-G.'P823?4(N7B=3&]ZID;XOIR*NDK>HT/]M#I M,6=5.L?_T'-"=[MAOU&4C?ML1^0NSNBS2UELWX*TRP!E6ONA1_V818ZV!NU% MP6?=[;3G9.MBFNEV"-5[]RJ,VM\JA&W(N0D:)%'&W864W*&=8A?H\$"*FZ9D MLPR?2[:J.%#!XWPP*UN&\Z5LEYNR/4:GVZ;<F:B3P64I47$FN-3=VIEXT/ ; M*>52MN2D-RM+J[X@9B&4$P+X6RWP@J3?[LS);[IBD$;)W4#;LX<J+I95$+'X MKGON>NGTPFFWGT##%!(9YE1A/0J;SK2$,K!*^>LRN./E51DE4*U-".L"K*LG MXR!-"_W@[GH-$V02/ZJ'-7CYE/A5AA*H)H> 701W:Q,=PC22\)G_H8O@2"R" M9_(B6)ZF>#\Y=.?J=]\9EX\-:'?BY#,'T+0@,1^=^;C=3OYBANTQ/\O&R]8N M-8$?=<T4./_UG!U7_FOQE '8YX1@^@'O?TH;8&CK,,SW`W[.&@+[>$.+Q!UH ML/3W*#Z44>9Q$MS1<O$&&1[2<.VPTG!^T32F9S<$KQ8]O/37A.!-4E(7CU8@ M*+?;. TR63;,IDC"MX3TGIO25(L+R^)!@2X)PT4]Q/ZIOVM2UT5^W%M%XS?J M=(7\"1@=5:&O]?/6>,)$<VN\FL.F](a)3/N./Q[#/^!RTM,CA2);5+=>"4&"6Z M: "V!'FWB;S;3/YPW#<AV+=F6'%PH1#BJ&WD<]$$E9_FLZ0C($W<=J#H#E/ M?Z"Y-UR7V5W*9_YN']7U0A5QME2T%-_@$2K*KX11FKT5Z?7:`4*SE.:V[ %P ML\"S>\#,'C@PX%OA-!/-*.1^9^VP_G.U@^J'FDB_C+.B,U$!:)]K+W?HL,'K M;[)JLB_,O%7NJI+L,4[N!QY>BI7:(.JRB_O_6,D54T*\8>>S=0)8N\LP2-<L MG8T\"\]7:QF-]Z@-DF@>NY".6]9N*-,#HF6T59P9+7UW3'"?\^."<W%<<'$( M#K[A((a)U]8HG)QH^MJY7^YIQV.P+TB_2#G?SJ]'L".!X<S4'TZ.X+WDMG1[!/ MOGZUOYS/KJ;VE[^T.TZW=]0_/CG]K_]N_>7K5WXY"OIPD!!7<%F(@X=R-5*8 M"+%-[&' I3D$B_MP3_3>?#@C`BA'KX5D>#1,75]*YTANI"8UH>TEW#E(Q',R M7!?@/P)!3K5/^KSE4>IN12VRC'8I9)NC2LU/\Z6[D\C0L-OC(U7S;.-K#M=L M[LD]:S-&%O,?A9E]S4UH>F../8HD`E#<U:0EU8-;EI"+0C4Y<_; 4>,-W_(5 M0<JDO'7+7^!5'.,F?Z"N#=!-<9YX9'RF.^W)QHNSJ: 4=R>V7G* N9H:4!E% M?J=-?MU#&7\9E^T:[X6J'B#>O]WT5B3M:IKN7BC7YO9/U+EAAZ8EI,<2H B, M?[W4P0.[<9ZIKSFD-90&>-?2),0\%C'1*ROT#DNJWJOF)TCQ"4O#GGGQQ)'N MZN(?:K@KWL-D"9ME2,Y#]ZX>HUG\IM+^`X(9'M5UN#B;#)5EWE9O+$GC19?! MXHI3T6/E32;=0T?Y^,)2$C,;?'&KH@5D-M7T^6-Q=Z=V8\=FW9V(B[:EMR8N M3";DUU(>BUZ@DG]OYI4"?O97[ [*1X%M*[\<@82ZYCTHQE(QG56308=*[6[- MP8[$FY#H+EM;P]F0_25N.UG:>TMX4VK);TK19SW\/"'UNS-<AH)IU1[SRV)6 MT4AQ04PNH%?"Y+2B?"5J?R6,-*_![96[2-G69FDBY8?&BA5?O-(JH?&E7&%& MK\&(N+;J3M0Q?\I!)%B^B7]&PD"^W:WARM,K.YG;-M@"$3#,%L-KX;%6..U9 MN7G;6[UV0D_9LVT3\;C+Q%V"GRQC(>)SY&X";[:XOG:?P]CUY5?>OISV^5RL MM5^][:1.==.=J.KD,JP_GS]5>[.JR=S]%= ;Y6=+OD(E4*:5`K5&E4&UMN!: M`&JO"3!W6>=_];C#EH%O)[U,)BEUZ1G(QB:X_A]C;6A5-545;B3)HGSS`F$T MF,Y7C43]5[2_<&YW=H!=J0^8?@OBM(EI<#VGOM8,O !B$BX!(&ZVU.[PT_T& M:5T`\YJ2RBM);S6R* 11+& #1_W;@555_K[:^;&ZH+O5]FK7-'N]:SJU\$)9 M)54";N94VBJ#7YC"?63.J91#XBXG\NA6><CQW"Y74)^OU;ZG]KJ4[4LS;5K\ MYEI>E.?]@(PN3_EU7YGR>XNTV]XYLFZA,-\M2];2ILDHRX8T6?%@C!A/T%G= MD-(1W3L)BQ4,*/O]1U&AN3T\[K^$0C/&2D-TPZP@:'V?(HMH^F[*F\SN%SUT MF.8!-4,SIO/24)6/'?*DC_+>N XZ$ _MR!7<1_%C5.2-:F2#R3#>+,5+PMH: MQ,0K[\KS!D.-(3ZD(^$&T*#5*O "&-)O8. ?`Q^"H_*Q8'D&C(3^HBD^!]%5 M1@]N&$BQAZU_8MCXL8"W&<K&H$R=6N\9E[U!P+5_$,4,#G95-89Z:0"#K.@V M:QR%S_;RF1_LI@9,NFP/UFTZK$7WF@\5O<V8LMQA;7ZF\JO6H9>:'K76?T#I MK=5-\RF+#ZCB8QKR?6RMUM4U?S'DK?OA70]_5&YNV'1)^;#7[>L?\'OYX\#J MIUF,SVG3*T;G]M2 K7L"IHYE> :F>)=!?J)Y:H+0+8[R&03+_#QT*09#KSXZ M785K'A"A6SZJCH<Z-=0'E:GR8$-54D>L+75)BS>"R):X&?VL1$4*JF#&%_08 M';UQA$U@4S,+Z#P+HCL:>N'\M,0Z@8YN".N#S7O6E@ZK&4>BNOW;87N_VH_) M_1G-K-7;J)DZ?3&IIO1!NY?+EU!"W&8KWV/>9];,='1-4FH)WFPN[3+D0PK7 MO "^B&.\`0IL=WT9POCUIQ>TX4^,N?8[4?6Z24F?OGEUVBGPKC6:]/K/5;J_ MTC<(U:C[^]-]KRG0Y-#HOU3V;B/_KLX-;Y*-.YT?>)95^D(;YAI=&T+5C)[\ MC!,\J!33W 4_[]+"-0X%3-D'`-WR%.MCG(<^$-\3<<ATC1\B$J\+9NSD7L#. MB$J5OFHI8.DA'^G3)I<$X)(*ZU6(?\/T-6*(;WPJFOP8A&'Q*&*,VZO8>PF3 M5MK_EM FF!K3HS5J?_EUU3?Z3 4.[4WDUA,LF_*90?&&@+3?P0?DC$1[AR+R M1P*_S]<@3//M1ZHV_R[OZI[;MI'XLV[F_@<\QC-Q&TF.Z_2A,S)MU^I%L4>2 M-7=YN!E*@FV.:5(E*3MJY_[WP^*+6!"@)#NBFL9/,K# @OA<8'=_VU38!VN* MBKX8NZ>R%E=%,4..)NL%Z8WT$MQ4BD_ B?HE]!)@&L73>^J7?E[CR6?RAT1L M,VV@'"91V&"%(P6S',NT%2?9BEV)76^5F]@I^/6?_Q$,55=E[,HHC3K5-537 MQQ*XU3U/%66)F0EOP/3++%[FT1/E&G*M?;*8?Y>&4.OMH'9D!@54Q#?>.]+\ M-:+[(_+O?P)U4OWK[Q!%4?8+;EZMO1'N@BAN&<B-T=U]`9 NQLMX]*6@-,&) MQ7W$^K-X3G&R<7P4879'"XBZ6''A[!R)2_@PN X(X&H1>'GGF$N_.Q=,+_O= M8,TH^M44G&1:$LAP$T-J.LKD:YX+^ 0^D _^,M-5^R9V@'@"XSFPW4!]C^/D M&)+M.[URRM@&%,@4LF+ZB',K9I![OFXHO% NY>\<*)0+""^+?"-A-GD-E^9_ M"!9497?L["[*[J)L$_Z34Y@`6U6[;L3=;<8=NUPNN#>RGKW<%=G4Q4PW@>'< M`H/3C;?I;K,%!&DUW(/#J3_%@\)9F[^N/(>JK*>HJ4&A;]83U+4!(V]ZR2[7 M?,KE]28UF)]BF@T[\-D$A/,Z=+9:<#:^/:^!9JM%9GL],-M7`-U\/>;FUX#< MW'(+R,L]H%6S):C_CM!_[6/G+-EZWV@2N]* AA1N@378A@YT0W?WO@37\/M; M-PX\P\J:V=D"V8LD(U ,=R[)Z#>1UP+RJ=5L@O"9:3<.NAM,9P+LE6025 \E M`#07*G32,@D^X/\D=!TJ`&A[MM1>A93[F#[S.:2W*A<1X'A@JGQ]17E]->5; M@ FN9\ISZ#'+!-131"A!AZ]>CZ*'4&QL9G5 <%9_F@AQY1.+@0_G2.Q:'X_P MV%SUFR!ON#X$\>;).GFP^ G[.:&O=USL, !<>9W3\&\CMC!HZLHY`U0TS*P. MH&\C?+Z_\H"TCWT#(I#\/'E'OE+?S(a)#+YP8+^L^=`\!_.L<%^^?)[+@SNB8C M%^"?)[-C]=(N\?[V`??G/V4YSM_.#UFE86A]PX!^==G?'23?])5X?'N9ZZ4N M:_<S'NO-7O9(9H8!;_R%,5TF<S+.H@7AP:>:,FK@?($MYRK'\@4:<D-G;=4H M]?ZOJ7*'_3X`Y3SE5SCR,4T7C1G(EGR!K;?C7=KI?)47]!&*&38'8,_/D[R> M7]@ZM)[6;2R'V^PT!/D+M]=G_;'_)CO-2V8A^-Y<T^PVS:R6;/*U$.,D?7P, M79;7S4 >,^[<49P?`(/&#+407V#K[8:93<D-VK3-FVE1$CA)N>V;Y0EB$WI7 M=FV9<M-$"!)--+@D;,)]Z06P$CRHCP&IX -8`.N3Z)8DI6NF<I_D(14+@?*8 M@Z5=&,=@-,!N:M$B3)@49=!)5$<#FE1]C6F*=#JX%O!2Q,+<XLTXA2B-I#^Z M^K%_'C 1[?CH^+!-W@#N`>OQ`R+1DQP71#\>D[Y\^O"8!"!3+1X30GW^^X%U M-+3/J9FA1>&&9(B2L[')F/N%N5*BO%!4_!PACC_6U!Q"SH:YP)PFX^"&O($J M#G\9! <RU/T#'<!5/LJVJ"@(>J@B.-UF-!Z\K++^R&[5/$L7:AO ^\%;?Y/. MK$JD9:8JSG:ANIIRJ JFJ%4+!0"ZR\Y1]YKM:\]I-M^JOT?M-X/@\!>H\L"L MS&C45M5U?AP'?<.ODKBK+Z?2M@RZN,9RR:&^JQXEK<?94AG JU_B<B_+R<PQ M^M="6](E#7\?KJ;YT#DH6U!#TMS.($[TID2@<F-P2Q*/03FA-(T^T:TQ5[;; M<%*R"?]&S8%Q_QJ&_$\YM;C+_G1%!@'W[37'TG%.H[$VEEK_K&KT6OC;VJJT M;]0!,WPQZW739(O[_=&Z9@$YVJDV;>3,6$*;-+/[M=IG,FZ9"[G:QH7<DC9I M7_MKM4\Q;:D-T3_ XI32;7.8=MMS2"FLI9 O[WC:,A1O5Y-@:# [R_2=T$,? M](?VF3?$?(a)R.,IP'W^'NN(PRY^7&Z0--_'S&PG\-7 (V(.<LW+? <H826/-N M9%(NF<KX$A T30:80(> MW"W<\"&51]NZPAWZ^-<6I$/<=SU9F6QLAU6,QS/ M7JMD=@\VQ4Y3TY@GM@UUE4CIMIVW_RB!QP'.B5N+;Q[LOG7/T67[( #$-'R" MFXO5EFE4X&S=@NFJH)ZL)/5D&*T6K"_.`XLA6!Z]GZ[,KX>DX^G*_'Q(^FFZ M.NY6DNR"[7=5LG:[6AND5<H>.\HZ6M(^P73&9[;TIP;#H,ZDF&OHL)FPP\JX MTH'<]YKUHX @P+:X1P=-(@T`T "?_L2U#IN4?+P+T?E8J?J'U!3TO1HVU+?R M7",#=D\.[YKT=6SJBWXFX':M#W8S2LP((GGN[B.!KV);<F5,*R;JPMMVIB[0 ME:B9RB/6&>U%/.:J#-MIUO*Q53AL%T8_V$6LQS"C\A+/PEFY?AST%L N8,:6 M<T<3@%!'3PA-OB3C&5/JZ9K1*1I/R.:\*'WW1N=($<P/7"59==^2Z;(@24JX M^2999&FA,>S**OH3U+E"(N<).4GH,^E/$'DOODNYL2F3U>SY"*K,,K\$?*SJ MV(RW5UW J2&M2IJ-#OA%G#X3^?BWRR$'/NJUTJ<VR&?IAM K7MW/6K#ZUO-] M&E/M:8]<'93]<=6"0\9'=@7O*[US'*8"1$AN0Z-B-\Y5HV,>B AA;,6<LW2I M&MCM>E<*",]ZW\QI<1ZQ&<(&O 2YA?TS+Y(KB0V!!ZV@,5W<I\D*^[(_G4PC M0_I[ZAZ=C29G.&$)<^.B]V^4>MGM'+FDQCT.9/D.)C,;>A;W#.,T2\,Y@!8. M5A:6G'/!\@MX]!C%(8?8%'?P03#1K]BGV]5'7/4%O*9#7JU\<5"BB:[>> TM MWUKL%XY3]+CNJL/WJB!:(&IH25^_\7V4"ZSG#5B/-.L1+NKA*&A%0?F&;X22 M\3Y^_&M_TO?/9, 6-XWC,*'I4C;I$' \R*R!F8V8>\^GK8XBE_$#DQ+".,HI M-^#QC4-/&,[]0;-T#=UGC(EAJN1+!QTQ8^N)^$/?!;LK_T&OA7N&G<<F^,UB MSLX^*]]!\>O5J<,"\#;*\@*RT-GYDW2Y5XZRC"#'QJ8G!Z9O/6<UIH^+- MC MZ0LWSMB=_>KV%M7<;8OS6$T>P(@!NL/T]I8\A?&2&A7"HAJMDMDYZ#NAC?CC M[6RQGLT>4.Y$5D\,-NX(K(EOE82#4]0=)Z!<L= D5-\-K*[CM#@@B !8MH^L MG2[T?C+7EBI_FYNVXZ.8)+U,1/Q*L(M80GBUO$C3^8X_$0X#'&"3+<^$37=Y MQ7E;:A^8O">7(a)X!-8J7LIC(Y77[%I[2XT1GV.2_K;BD4'=$'"(U(O4X9>9)Y M2VX_,F?W<M/ZT=(XS/L:K!G'U"OHYJ,&T8/N$G:6V*-68DI7S;)<UG#Y*BG" M+^=P@3:AHQG#(II9R1+@6G%S/J&*;Z)S3;1!8*ZF![^)<,A(ZZ,;47D`FRHS M770>?#AP'/BCTW,BB*4<B17ZO1RB$+?6BI/C?@^I!G]+P6/5D \WJ.$35B[2 MVV*[\F<2'(<FIZM>\9&R(_,JH5<0TK'EDW<&_8DA!F]34HK#O(*2;1P;!;BD MZ>532VITQ'_292^CK!#X'VS<C7+-7Z3919RFWFO$N'^QYX.[1DB/-'5C8CI> M5%]94H\MR/$B>O)>G'K]'H?>FL#"LHOVDW!-X8$L+.YJ&.,.7]E<\KR#"-?R MF=TCX,3U+ZO/KGK7%=-KZK/-4. AA-EJ5(3%,O?S';GX;EA:LQ\9<KR<$71( MP_EJG/)1TZZZCGNU-$+8_E8A9SO-R6R996"=HR\7^$*@@@YS#NQP/J-@ECH' M4=VX&0A[H#_U+_AS2?_'W:X`"RK)?,*_@[20'UB&C;5O(.9E08)WZ1O#'D_K MWP"W,S/R=KG%"&9U>\N^7ZDA`-XCZ!6&=$;9SC(731Z P,:Z#$_8@YH2YU^8 MA G.H&8)<2//'Z+%@LEP\/PJD,C1M=W":@CG\TB$XQ'S.Q,@%7A^N1 J1"*( MM)W_MD_((6GO=:()8'\YE#JR4/Y GW<YXT!!/F(\MCW/VM[YY:+N^"-T,-Y8 M^CQZAST?'Z,87JU@8\[W/D#O?WA'I#IF'T/U_MU ,-_GD#V63?@V!FX0D(^I M3&UF'Q\$BF'M7LYN3&'LC<L."H5"WMG!5^7RAR[;( )P:AGQDN T7WJTR*CE M/ (#HP;M<+$BS_?1[+XD`@S2,$I$A58DGJ:'94*3><I.5JG(WOVHM 1'S-#R MI9?N.9P0^LS0!Y8:=X59-E_.5- ]7[#X]\=FM'AN=PT&!$1P$+PRT$V^K![4 M".,M9#\7M$_TF?3&`_(49<72V!F;N9\Q[HSY)*A;<E79!XL^ED.^%>1$[&O' M1R7LA*1GJ_V!SL?I=3 ,8O;;!-ZR2&0LP I9&+)KOHV$$L9M%Y PE!WZ`W@G MRS@.$(T9SCLK<F\F!_@%2 \?@17K6P*793(BHJ<MYQ:545^<)G?:LM2,RL4: M>L_V0D^>Q?<JB>M:F1?9DNN-.+0#WV=!0#0C?;>XFR#;4E<7[-2B\X!=]'-, M8<8UAY%Y[U*OR(B,\H0\N]G"<K?5@F#DKRB.&FAZ`&I!W@8&P2*^,%I5I]!( M(,B9$(UW3""WDYW6ZDWO.X ]PC:9Q7*G=H4W.5S-&!/_@^HF@!1AO&#;XO(1 M[.Y:OX+]';OV<Q]3V[;W_-/9/__Q?U!+`0(4`!0``@`(`"F*/2,N^+K;@QH` M`""9```6``````````$`( ````````!31S$U+T@R-#4O2#(T-4%33C4N5%A4 M4$L!`A0`% `"``@``%P[(O^_<FN\)@``?-X``!8``````````0``````MQH` M`%-',34O2#(T-2](,C0U05-.-BY46%102P4&``````(``@"(````IT$````` ` end

2 1

Re: H.245 v1 and v2 will not interoperate
by Paul Long 30 Sep '97

30 Sep '97

Mike Nilsson wrote: > Version 1 syntax is file H245ASN5.TXT > Version 2 syntax is file H245ASN6.TXT I thought that the Decided version 1 is 5 and the Decided version 2 is 9, not 6. What gives? BTW, there has been enough confusion (mostly on my part, granted) about what's Determined and what's Decided that perhaps we should have some short document available online somewhere that describes the status of each iteration. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Discard unexpected RTP packets?
by Paul Long 29 Sep '97

29 Sep '97

At the H.323 interop in Jerusalem, I learned that some implementations discard RTP packets whose payload type is incorrect, either implied by the dataType or specified in the dynamicRTPPayloadType field. However, some implementations completely ignore the payload type and accept all packets in the stream. We, Smith Micro, used to be strict about this, then we stopped checking when we found that some vendors were using the wrong payload type. Now I'm thinking that we should go back to being strict about it. I exchanged email with Henning Schulzrinne, and he said that endpoints must discard packets with unexpected payload types in order to ensure backward-compatibility with future encodings. (I CC'ed him in case I have misrepresented his thoughts on this subject in some way.) Let's take a concrete example. An incoming channel is established for G.723.1 audio, and the endpoint starts receiving RTP packets with PT=4--the expected payload type for G.723.1. Everything's fine. Then the endpoint receives an RTP packet with an unexpected payload type, PT=80. It doesn't matter here, but let's say that this is an RTP DTMF packet. What happens next? Apparently, H.323 and H.225.0 are silent about whether the packet is discarded or passed (with unintended results) to the G.723.1 codec, so the behavior is undefined. I agree with Henning that endpoints should be required to discard packets with unexpected payload types, but most of all, I believe that we need to come to a concensus about what to do in this situation and then document it. Any comments? -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

3 2

H.245 v1 and v2 will not interoperate
by Bancroft Scott 28 Sep '97

28 Sep '97

Hi, In trying to use an option of the OSS ASN.1 Compiler that makes it possible to move from V1 to V2 of a protocol without any name changes occurring in the generated .h file, the ASN.1 compiler reported a bunch of unexpected changes in H.245 V2 relative to H.245 V1. Upon investigation I found that its complaints were due to a) changes in the names of identifiers in H.245 V2 compared to those in V1, and much more seriously, b) changes in the H.245 V2 messages compared to V1 that results in V2 not being a valid extension of V1 - meaning that any implementation that conforms to H.245 V2 is guaranteed to be non-interoperable with implementations that conform to H.245 V1. I don't follow H.245 closely, so I don't know if it was intentional that these two versions are incompatible with each other. If this was the intent then please ignore this email. Some of the changes in H.245 V2 that result in name changes in the compiler-generated .h file (unless a directive is used to tell the compiler to use the V1 name) are: - All occurrences of the identifier q723 have been changed to q7231 - In T84Profile the identifier jbig200x200Progr has been changed to jbig200x200Prog ("r" at the end has been removed). - In AudioMode the identifier g-dsvd has been changed to g729AnnexA - In H263VidoeCapability the identifier bppmaxKb has been changed to bppMaxKb ("m" changed to "M"). - In DataProtocolCapability the identifier the identifier hdlcFrameTunnellingwSAR has been changed to hdlcFrameTunnelingwSAR ("ll" changed to "l"). - In RequestMultiplexEntry the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. - In RequestMultiplexEntryAck the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. - In RequestMultiplexEntryRelease the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. The above is probably only a partial list of the changes that are merely minor annoyances for anyone who uses an ASN.1 compiler. Much more significant are the following which render H.245 V2 inoperable with H.245 V1 implementations: - In OpenLogicalChannelAck the CHOICE alternative v75Parameters was removed in H.245 V2. This affects the bits on the wire and guarantees that a V1 and V2 applications cannot interoperate if they attempt to exchange an OpenLogicalChannelAck message unless they happen to omit the reverseLogicalChannelParameters or multiplexParameters fields. If multiplexParameters is present they will fail to interoperate. - The type of AudioCapability.g729AnnexA changed from being a SEQUENCE to being an INTEGER. This changes the bits on the wire because a field that was previously mandatory is now no longer being encoded. - In H.245 V2 the V76HDLCParameters has the field crcLength as mandatory, while in H.245 V1 it is OPTIONAL. This affects the bits on the wire so V1 and V2 cannot exchange the V76HDLCParameters type. - In IndicationMessage the second CHOICE alternative has changed from FunctionNotSupported in V1 to FunctionNotUnderstood in V2. This affects the bits on the wire so that V1 and V2 cannot exchange the second CHOICE alternative of this message, for FunctionNotSupported and FunctionNotUnderstood are syntactically different types. - In H.245 V1 NonStandardParameter was extensible, while in V2 it is not. This affects the bits on the wire and makes it impossible for NonStandardParameter to be exchanged between V1 and V2 implementations. - In H.245 V1 NonStandardIdentifier was extensible, while in V2 it is not. This affects the bits on the wire and makes it impossible for NonStandardParameter to be exchanged between V1 and V2 implementations. - In H.245 V1 the DataProtocolCapability components segmentationAndReassembly and hdlcFrameTunnellingwSAR were in the extension root, but in H.245 V2 they have been made extension additions. This affects the bits on the wire for all possible encodings of DataProtocolCapability so it cannot be exchanged between V1 and V2 implementations. - V76LogicalChannelParameters has been changed from a CHOICE to a SEQUENCE. This affects the bits on the wire so V76LogicalChannelParameters cannot be exchanged between V1 and V2 implementations. - In UserInputIndication the component alphanumeric has changed types from IA5String to GeneralString. This is undoubtedly a mistake, IMHO. Aside from the fact that it affects the bits on the wire due to the default permitted alphabet being altered, GeneralString is a far more difficult type to work with because the characters in it are of varying width. That is, one character can occupy 1 byte, and the next 3 bytes, then next 4 bytes, the next 2 bytes, and so on. It is due to the difficulty in writing programs to process such character string types why BMPString was introduced into ASN.1. What was the rationale for going from IA5String to GeneralString? I am likely to have missed other changes that make V1 and V2 incompatible, for I was not trying to be thorough once I realized that there were more than just one or two such errors. It occurs to me that maybe the idea is that protocolIdentifier is to be used to determine the set of messages that can be exchanged, so the problems with bits on the wire mappings reported above are not important. However, if this is the case and bits on the wire compatibility is not important then why bother adding types after the extension marks ("..."), given that such types require a few more bits to encode than if they appeared before the extension mark? -------------------------------------------------------------------------- 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

Q9 Sunriver meeting and White contributions available
by Gunnar Hellstrom 28 Sep '97

28 Sep '97

The report from the ITU-T Q9/16 - Accessability - activities in Sunriver is now available for download from http://www.pi.se/~omnitor/standd.htm There you can also find the white contributions for T.140 - Text cconversation protocol for general multimedia application T.134 - Text chat application entity in the T.120 environment V.18 - Revised Recommendation for text telephone modems. These draft recommendations, together with work decided to apply T.140 to the H.324 and H.323 environments form an important opportunity to establish conversation services that give equal opportunities for people who need to use text, video and voice in any combination for their basic communication needs. I want contact with organisations willing to implement the draft recommendations, in order to assure compatibility. 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

H.225.0vX => H.323vY
by Paul Long 26 Sep '97

26 Sep '97

Here is something that I finally came to understand on this reflector a few weeks ago through the kind patience of Jim Toga, Mark Reid, and Joerg Ott. Does the following need to be documented, or is everyone else comfortable with this just being understood by all present and future contributors, editors, and implementors? Given that 1. only the version of H.225.0 in use is present in the bit stream (as a protocol identifier), and 2. some H.323 semantics may depend on knowing the version of H.323 in use by the remote endpoint, then implementing H.323-version-dependent semantics requires that there is always a one-to-one relationship between H.323 and H.225.0 versions. For example, an H.323v4 terminal cannot use H.225.0v4 _or_ H.225.0v5 and, conversely, H.323v2 and H.323v3 terminals cannot both use H.225.0v3. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 1