- sg16-avd - lists.packetizer.com

H.323 Mobility: Re: H.246 Annex E
by Edgar Martinez [1] 24 Nov '99

24 Nov '99

Dear All, Although I have some interest in H.246 Annex-E and H.323 Annex-I. I strongly recommend that the work be handled in separate meetings. I will like for us the H.323 Mobile Ad-Hoc group to focus 100%, on the H.323 Annex-H Contributions which where left over from our last meeting. In the context of Annex-H. If Intel is submitting figure 1 of MTD-13 to be considered for H.323 Annex-H for the highlevel interworking sections of H.323 Annex-H we may look at it. I also propose that H.323 Annex-I should start doing some work, and provide the H.323 mobility ad-hoc group an outline and work plan. Before they start to attack on what (should or should not) be included. >From an highlevel point of view H.323 Annex-H, could address e.g., mobile ip, IP transport, IPv6 etc.. interworking issues with H.323 mobility applications. If we can not come to an agreement to focus only H.323 Annex-H, for the pure H.323 Mobility solution and the Highlevel (non-H.323) mobile networks and terminals interworking requirements, " Then I propose we cancel the meeting." Best Regards, Edgar Martinez "Reddy, Paul K" wrote: > Hi Everyone, > > I had submitted the MTD-13 contribution as the H.246 Annex E's Goal and > workplan to be discussed during H.323 Mobility Ad Hoc's conference call on > November 17, 1999. Since we could not cover all the contribution in the > first conference call, we planned another conference call on November 29, > 1999 to continue reviewing rest of the contributions and further make > progress on H.323 Annex H work and related mobility work like H.246 Annex E. > > I really appreciate AT&T to start discussion on H.246 Annex E and the > initiation to make progress on this work. Please review the enclosed MTD-13 > document and send your comments. I am also working on the H.246 Annex E > document outline with inclusion of APC-1671, APC-1672 content as part of the > H.246 Annex E document. > > Contributions are welcome on this subject from any interested parties. > > regards, > Paul > > Paul K. Reddy > Intel Corporation > Mailto:paul.k.reddy@intel.com > Office Phone: +1.503.264.9896 > Mobile Phone:+1.503.807.9564 > > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Wednesday, November 24, 1999 12:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.246 Annex E > > Hi, Everyone: > > Now I am providing some inputs related to H.246 Annex E - Interworking > between Existing (Fixed) H.323 Systems and Existing Mobile Networks. > > This work item has not been discussed completely in the last Red Bank > Q.12-14/16 meeting. However, a separate annex for this work item has been > proposed. This annex has been proposed as a result of APC-1671 and APC-1672. > An editor is yet to be assigned for this annex. > > In the last H.323 Mobility Ad Hoc conference call held on November 17, Paul > Reddy of Intel has been assigned as an Ad Hoc editor to continue this work. > > * First, this work can only proceed independent of H.323 Annex H if it > is considered that H.323 terminals are fixed. > * Second, what should be the scope of this annex? > > I have couple of suggestions: > > * Let the ad hoc editor define the scope of the work. > * Let the ad hoc editor formulate a work plan. > > Once the editor has some thoughts along the line, let us discuss this in the > SG16 reflector initially. Depending on the responses, we may even consider > let the editor and all other interested companies bring contributions along > this line for developing this annex. If needed, we may even plan separate Ad > Hoc meetings completely focusing on this H.246 Annex E. > > Our main aim is to make progress in all areas as much as possible with clear > goals. > > I would request that all SG16 members provide their comments how the work of > H.246 Annex E should proceed. > > It appears that almost all contributions and interests have primarily been > focused on H.323 Mobility work (e.g., H.323 Annex H). Keeping this in mind, > we must be responsive to the interest of our SG16 members. That is, our > upcoming Ad Hoc conference call on November 29, 1999 should primarily focus > on H.323 Annex H: H.323 User, Terminal, and Service Mobility. > > Best regards, > > Radhika R. Roy > H.323 Ad Hoc Mobility Group > AT&T > +1 732 420 1580 > rrroy(a)att.com > > Name: MTD-13.zip > MTD-13.zip Type: Winzip32 File (application/x-winzip) > Encoding: x-uuencode -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.246 Annex E
by Reddy, Paul K 24 Nov '99

24 Nov '99

Hi Everyone, I had submitted the MTD-13 contribution as the H.246 Annex E's Goal and workplan to be discussed during H.323 Mobility Ad Hoc's conference call on November 17, 1999. Since we could not cover all the contribution in the first conference call, we planned another conference call on November 29, 1999 to continue reviewing rest of the contributions and further make progress on H.323 Annex H work and related mobility work like H.246 Annex E. I really appreciate AT&T to start discussion on H.246 Annex E and the initiation to make progress on this work. Please review the enclosed MTD-13 document and send your comments. I am also working on the H.246 Annex E document outline with inclusion of APC-1671, APC-1672 content as part of the H.246 Annex E document. Contributions are welcome on this subject from any interested parties. regards, Paul Paul K. Reddy Intel Corporation Mailto:paul.k.reddy@intel.com Office Phone: +1.503.264.9896 Mobile Phone:+1.503.807.9564 -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Wednesday, November 24, 1999 12:49 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.246 Annex E Hi, Everyone: Now I am providing some inputs related to H.246 Annex E - Interworking between Existing (Fixed) H.323 Systems and Existing Mobile Networks. This work item has not been discussed completely in the last Red Bank Q.12-14/16 meeting. However, a separate annex for this work item has been proposed. This annex has been proposed as a result of APC-1671 and APC-1672. An editor is yet to be assigned for this annex. In the last H.323 Mobility Ad Hoc conference call held on November 17, Paul Reddy of Intel has been assigned as an Ad Hoc editor to continue this work. * First, this work can only proceed independent of H.323 Annex H if it is considered that H.323 terminals are fixed. * Second, what should be the scope of this annex? I have couple of suggestions: * Let the ad hoc editor define the scope of the work. * Let the ad hoc editor formulate a work plan. Once the editor has some thoughts along the line, let us discuss this in the SG16 reflector initially. Depending on the responses, we may even consider let the editor and all other interested companies bring contributions along this line for developing this annex. If needed, we may even plan separate Ad Hoc meetings completely focusing on this H.246 Annex E. Our main aim is to make progress in all areas as much as possible with clear goals. I would request that all SG16 members provide their comments how the work of H.246 Annex E should proceed. It appears that almost all contributions and interests have primarily been focused on H.323 Mobility work (e.g., H.323 Annex H). Keeping this in mind, we must be responsive to the interest of our SG16 members. That is, our upcoming Ad Hoc conference call on November 29, 1999 should primarily focus on H.323 Annex H: H.323 User, Terminal, and Service Mobility. Best regards, Radhika R. Roy H.323 Ad Hoc Mobility Group AT&T +1 732 420 1580 rrroy(a)att.com begin 600 MTD-13.zip M4$L#!!0````(`&>9<">\0*2;,3,```"8```*````351$+3$S+F1O8^R:"SR4 M6]?`]YC)C&H2T9T>MZ*008647$)*9T(a)Y=!TS$^,RHYE1=%&ZEQ#=HU12WM.= M4!25B"ZD5.2XA71!TTU)>-<S,RXI[_G>]WR_<[[O_;7Z_:V]]K/WVGNOM??V MS.A^@4+ET0O#JU`/F8J(J*U=#LEVJR,`=AW&0(1F2.O:VMO;\2I;H/VG_+^2 M^OCKR`W)D1"B*&9V9A8$:M[+(30`>7A[>+]W?>^*OA,YTF`4I(-0Y!2"F&E] M)/4K>K2;+-7M[?*==;V5.V2A^.<Q$NK4W<NX-/7_7BMU\]"7VKLV`6T%&N\Z M&[1NM^=EV@BE@`X'&XHH!?1@T'>ESWOJ6/D?ZWNC$9(!73!:8G?7>J"_@BX" M?7^,1!^'P31![X*(?H!CM64<0@O`SH5Z9?2]=*P[]OO@B64-U*NCWN>'^\5E MGR3?W\6W8WT=@ML7")*X=._74^/^3R.)'QG9+C\=\^VP[TGCT5-ZYJOGO'KJ M[O'&!9\'B]PUGY8A"-V`>6MK(;06]/&^"#G+=,WG/Y6.\3K6LY(JV7]'8A]Y M_<,@D]!S'3-A/K-`GX1^O2S];Q`">8;+7,R%[<MF\OS\`K@<)D/(X7&Q.4(& ME\7@LS@"J<UF"GE\#*/.$0:P@C`[/B_`'Z--U,6<`M@"<0N:T7B:,95JS>,N M9?/97"8;LV;X^F)>/(&0S<(\@K`97"';5Q>C3<)F\Y:S_3S8?#!,34VQI7R> M'V9B9F"`63IB0AY&,Y"6M>D,)GLIA]DY&\R%X\?6(9-M>,P`/S97:$9UX0A] MV6;4.;P`/A,TC"YD,(5F9$<7&SV:$=5>W]!X(F;)Y;(#L>F8'8_ABX$GS)7' M]_'W97`Q:&!D:(0Y\CPXOAQA$&;)PNQY3.GR[/7MJ71&@"\V4Q]S9K-80;J2 M-6#6/+Z_/AXT;!P-FV!@I&<XT5C/U,1THCY&G>['X/B:88,P>S?Z=.=9,V;/ MQ/`:(<_,'USI^^CS<4_3.+@C?8@Y1E#Z\0-EZFP&WYOAR\"LO!@"'SQ:_V)T MDPG&IN*QOQU:73HV5^)*WT/BJFL4=1B_UX?*9#(5CYD9M4<@!?YL)F<IARW` MA%YLS)_/8[)9`7PPE\(>@;"*H[K<&!.R^7X<+@0=LHI[Y:^`P&,K.$(O#-]N ML&OHLQQG"S!MMKZG/F8WQU$7LYP]9P;F,L-R_/09EI@Q31>CVUCKZ&-SF#Q_ M-L9;VN6&P_4$@^D;P()Q!6PN"Z_`D\MG,]F<Y;BUG,>!;<B$;2C0E1IX/#`N M3PBSE^QTW<Z^`B\>7XCYL04"AB>X_-;5MP_UJ=2.+02QH>E@-NSE;%^>OV3A M&#M0R.8*P+E`LG#Q)$%WQF6%%X?IA7$$&.Z!"\<#CQN++0V7^#A!:\/QA@8& M!E3#+O??GM$><1>/(Y#V_39?_\J]D4Z/QBS(;8<;4W$;C.'+\<2G*<Y<QR(Z MVE&-=3#;`"',`Q.G%Q\,>M%ZC.C'".H,A2#`W]^7C9]@!C\($L!?#KF!'+E: MTK]-L'A`0SN,RQ;B59*L>#`$[!\T,^IJ!L?#"Z(KW6UP"WFP?[2&"?KB^XK) M]H>;A&K+\80UT,S$QZS3M0>X9+.EJ1,/+]ZR5"I%3DZ.2I7<,YA4?GR;>(IO M$[%7CA_FR&8+Q9N3P\!Z7I:8'#B!VU$?OR8EMR,5KB!/-J8!QYIN:3<=4Z(I M4_^<_/$OA9_R4W[*3_DI/^6G_'<+?(HFX)_4`7V`!E@"=&`O<!%(`8J!D7T0 M&@5@P*^`&[`>V`!L!`X"T<!#H*B/Y-,_$2`!*H`J(a)`%JP!C`%#ZE6P,$.?B4 M#)@!DX%IP#'@-^`4<`%(!)*`BW*2[Z6^H*9W]2]0+2I_6I0/5LZ7K"^@TD&E MHK._P3\4AV+1_CW[=^[_XR#T+A0#!P7D9P]A(N$E1"5ZX]5X>2Z%(#N!$C)U M+*&C%FKPIF0O"N+:RY$4)$^M'48B:0T9:JP=%)&\#"6$Z&VFC)`LA0"]P+<\ MDM:6#^JH[3N1$F*%]U>$^$#97-(9D2=*"E3PUM6$))ZEK*0"=?8="NVE!8D> MB>0Z9XOTD#3W-&G.G8!D:<ZO`;>``FG^*_!O7*3Y=P)B@*;NP6KH;CS[GQDW M$OIT&<G=GWQC)'0WHKL;.WLUOAEG0Z\&+OT1&G1<"2D!@S4)U!P*DJ&3KZDA MF7[X`WK7@SZ(<$U-!F]/U)21=&'U^N3'?;[SAB'<&J))D-GKBRB/#?"O#;_T M(a)=%!9`D2.LH_JNO78_(2KW)XK?EW-?3.&C<5V'+_;OZK@";@"]#^@_UPK]OY M?P009']\#XSJ<1=H`R;DKCO!!H@#9"A0!I!<USW1#S"5WA<6TOO"%O"1WAMQ MW>Z+9"`%2`4N`9>!-"`=N`)<!3*`3.`:<!VX`60!-X%L(`>X!>0"><!MX`YP M%[@'Y`,%P'V@$'@`/`2*@$?`8^`)4`R4`$^!4N!WH`PH!RJ`5EQ:Q#^;<>DL MB*6EYYY%J/G?%;R3#(&`9(@$1"(2^O3UZ,C9_W8^.O+PKOM\OS$>=#?N=C=N M_Y<9WRPNI]=F<$@0&K!Q]5?\CVKXD=$D*K(J(5O8']P/W?4/ZWJ]W=`0/$=_ MQQGYBKK)EY_&7V;@`ON"J`C[BX!4_LQ]50E4`<^`:J`&J`6>`W7`"^`E\`IX M#=0##4`CT-I]/C^-O\[H$OQV4/FS>7P#B("WP#LYR;MYV_?RXQG\E+]5X$U` MJ;<<_B=;ZQ/Z*?^WI?M;A?C\]QF)1IV_/QX[7SE%[3R%K`YH[#S21Q/0.@]O M<E.&B^;`6]^Z.?=.76QH=LXX:LC/L?5@:6IU^=2$MQ83>",I"5@(-X,54H/V MJ"TPIM;-Q]=ENM)4HW3Z"^)3/YU-#Q[LG:3E?@2S,EZG5$CW"D&1BCY!,W64 MMY?:.MZ6I[;1PM2<=G[>8#QTA+<ZYK515OO7.&?+;2E+!MX?NL-8Y^C1(TY? M\P\=:*Q-G)]R/M1^3'.C>>-E(\_\`Z9U=Q=8VMPA'%6H4S^(_4,C?K""7JZ: MPYV\0WE*UEL4',E'0T?F.<ZK=KGB$W!E.\DC9'`E\4CJV9,;@M5S'*:9#M]* MV/R2+W_L=E4NF9-A4E(<M3F\(DPVRCYL/G&D'7./Z.,F%\YM!>V(BVLFR^_7 M6\W<:%1FLSV^[PK&0Z7+'\M6?])TM4@++K(F#[^=^"`\*&&EB/JFZ,2(12=: MDLNMXY/.!7E^W/KF\^&7+1H183M./A*T%%K=^S1)XX3]0\^F4\V-AA_<<EH) M,2O="CZ,FY64OBAYX=-Y56URM1DZ>]SVU$1;1+3HE!^R58UU/Y#=0$YUN42\ M-T.H*5\2$&6CDKB/*!SV,"KON)`7%6GQNFDHI7Z-:_/N9V[3?+Q4SAP)VVTK MV+DJLB#NH]>J$(?U41E;5,OX97>RSMW=JK69$9_\V+K?(M]/3<OGZUTXH[4] MYTKFUZ!?0C-/1YBK5-!\VFT2UM#=??*,4\[,>REZP(G/6I.<00MP?9P5%ER^ MH+QQ0JM_A6.R*C\\3T?^XMTYKC4%K25/`L^GV1>]B=+E-&<L1DI$:V&0A6C` M@0GOZXQE?V&=/M^D=V^Y*'#.R6SM@F-V7N9AQ*V&(1G3?J-N)B>^Q51J5UU0 M","\K+/F:3?NZ)]O2QJ72<\]X/=VKDLY>1%Y[9";9_A3(U)<CQNFAM3<;:TI M7/UATI8'3OEHLPQS_>[Q_:\F!_]Z]I>"P.<ZW%.R@WQ"^B7TOV\5K)K[^(KG MZZF.LYV+`PHCZ\TNO%X6^?P"P8L43+CN[3>DJ=\YK]TTE2_UM?<+*'HS3U)3 M(Y+I!2^-*OM5:MZ?Y=VNJOCZIKZ3>M-V!\:+_,JX^&O*1UQ:TF5+%A_>M>W= M;N',%O<+Y]0F+]:]1<H^IV7GBDH.H[=)TP:-G?11\^N:TKG1MQ=.X$0_53U# MCR_5L/*8L^?0_/ZER5,^'4Q-]#3?L_ZU<ZA@0OB%?\0TH+*:PC/G5]T^.>QI M3$*N^J"U0Z/=3_MY5]U2/;BL\K<5SM5S?4X_]+*8__NS"<P8F]8+"1_&U8]P M&S",//^*P^"7\R;O*]9OOW`\V^=53-3D`W.QV*7"<>E'0O.;O@RH5!2I^0\( M"PJ_VF8TMM8J>WI(TQ=OYXD!(Y>7V[S@#3=VE5FX-\Y<Y8VS??9BN8DVWL&S MRN(83]\\EHUN;2R0%427R0IB<B::[#<Y,^Y=QMJW-QM\+%[:6/2+:;S81/5C MN=0</GMVC5%.JWM+U=8Q#B$5]"J32K_^(L.RM*;,?6--GFDG)`6J#S$;MUX_ M]&B67$VHQC-C6>?*CR.W!^TF5AQUWGQE^"%5_[O5!D_?;4H^3,R/0^Q%&]B_ M;GK-(9[14AZA]=J4]<I4BRZB15E8&%%"7^N)#!6"TLO[58FJ=KTMI-;\HK[6 MZDVVT]E0C]T^)RF;Y$>%#AAEES6KYO+322?3\N/:)])4+Q\=L>53YONOD>V. MV_5+YU+3QM*&-I=]\6^):7B?5R08*GNLX;/)\!'M6V;7EU[]+-BUP^(D.3>V MSG;Z\Q5V:S.4]X?DMZD'1!C>KBJX=>R,90)/ID0FO+WNP>CB]<9>7*W#[SG# M'.+OCVGA[W56:EZ==K5>+?:7B#A1R[(,7E624D4J2;!WY?Y6$X_BVK)'$>\/ M%?EX)=@%%U]X7I9@/F;4:@MNXZ17&],J!KYK:@G[5--ZN4)4EUY'J4UOGC5R M=L4]_I**>RLG9*S:5JRS=VNHVMLRWXKB,:X["\:<4WKT(M.A1F.2\(Y]<V#X MN1T1!8/J+)^,GH?)US:G+SI7J''MA$&YG\@MXLD3A<J$O0T1'GM^UW/=5,.- MD_M,HNZ+7!O/?JS;MV;9CD+=15&;&P>>6U:I)$H^<2IR!$OE<T+D3.N5J6\K MRD=DY]J^I.:EU:Z*DS%>';KZZMZ21551Z3;'S"E#TY*LWM[X9.MI7W@H*CK; MU$T]@W1#6=!49:1T?D#QPVWC@[<R\YO+:,]U23F4@/QBRB658!_LU>3X*#LL M,[M5NZPY/R:OZ./GPHHTUH@"SZ,R"@>3Z`FLG`\C3PXI;%BVDG?TV0?_O+NQ MAUCIV<%>:F.SD@G]LU7.?^3->+-83>G&&O+J?9^6M*0QORY(V&1LD]!.K0U/ M?G'CR#+&[YDAS]3"5YBJWN[//)WW=F!%M$KALL/;MSC?Y!Y05(R]!S7QR\Q= M9HQ6?;>U>FB<VXZ!38%;JQ>%;YFX:]L6V^UF(B>-ZJSG2<WU5R**6CT]*+[5 M[?<]Q[\*GQK]Q'TSO3V@?-K43=RR]U<JFBM8!IZ.'RMNM:\][%^QZI9W>:K: MXNK]1'DEM<;5;_S:%^^Q_M2V>.Q3&KDEXWWJ*.;(EDL1JM%"BP5M0R[6#'/L M[5?T7RSXM\TVB"6U9*1:\L7!N#['^A018XD_[-A-Y!%)9`XZD=17A'\UA/\] M`?5%R!KU$PV%(LD2]Q="4$!H8"8!_P^F[?`3;SE01)*X6&>(R*+9,!<B*7E_ MF<EKOP.7"E>6I519*B6WH[&#)#.R$3?EH25J(T3J4->SI;\^0ML^PWLHO)5B M7^%S#;SE&#SHC]8U4Y%($8G?2DZ[D86/LQ-C'=?1%:]9[1JK9V,U2(:BWNJL M18JZ[^.EZ'YEVO&%-<_5IV\7&1_!UA^CK-09;#.=%*F>.WV@DRHFHPY/]K?? M75U_I<0QL"Y9<+6N]HYI9E)+0WY;<%)%X]W&8!J=A"5RAJV3H>>N:U-V40K- MO6PTWC_YQ=:9D7?4!:7!!BM*;V_<.WWP?7<U)N9PATY:MW4=DY`09[XI^3C% M\U#IKE)N96/",_=YKN5!U^5/..1>US'[NH1_Z\;:MMKPL,\6>]37!"U4?M/4 M]H0FRA2F!Y4-/S\LZ4R60@R35ZFT:E18$I5SJ6$&T5?V8TJ!4V*9_91ZR^P" M]XC*\A1S^8O4H$L--ZL;IAU>.D:T8/+!V*2KIG=2ZG12#J?LJW8:')C0NDWV M57';[<+%EV6?6CRD1\_2\),)2XU_H;-J1%+]I$LW,[:<FA(S?D5=<WNTFZ=% MDO=Y\R5NJ@MV[EMOG6A6//;U^GVUAY:DK!Z^(W(M28<_VDMMTH:#SD-#9RKW MK]<(+!]=;>$K&^P[I#JZ?%!=8;]+)4N?<4N'1)3N#2QY;+,SZE=W[:W[0BWG MFZI^V+7F^J[$*?O'S%\_(5&M>+3/AJQWO_VSO2^!IZK[&M[WFBXR90@A$:5! MYHQE2I(I0Q0EF2+SE*F!1_3TE$8E2852T62*#)$D22F*E*%(@T1)$^7=>Y\K MEYN>X?^^[^_[WL>ZO[7/V6OOM?9PUM[GK'W6V=?CZNM-:ZM:=[[^*A1/[CSQ MS#=VR0[?*PFUC+]/,CD0=4+&8I:2'EML5IKA^O,?:Z949TM=SZ[?'".^2$I- M<[EW7TC!R7;O7@I79?RBNV_?IAAZR'+FRIB&F:L=-I+/BI%P672IV$#MXYH2 M+][/&Q__467J*GDW8/FCFR==YC?LV?_$]KS_E)Y=?:_),ZL:!A/>=*AG1<ZI M"HBX:MRQ;M\UIAF1.F]=EIM*LIP^7G1*O>[,SC1SY3-+.*1V-(6K.EQ3S&Z- M.J:UF96S?%O;)M5I191%3(IM1G*,F[F:=&?<T)69RY;;>S;GNN1]EM9#QA%+ ML]ZY/XI)[>"3#O5)LGEQ<?>;4M:LR2]N38JPCFF;>9]T-?YKR++9ZY9N+VL" MC3JA=6UA<KSGSSZ\4%9X=@O%LS<UMD]JBV+XS;MO%LZ*K#!1$E#>=FF/S-8; M@I/*CHJSS,IG52NSOM#!)Y5/X0EA8GO&,2OJJIZ2P@%]N4].)$MF]JF5O,G? M-L4'^.V?4^YUGH.T@/0L>,>,"NUOF@:/TTM=[D1OT!0^O^%Q4'?A>96&SSQ> M%Q@6!2BKWGVN*6(3$ERVENVZH_3J?=:!JX)K&_P3.=GNB<E4%@8ZO#WP=D=@ MR[R510XK>AT?79_IO,!ACU.$Y1W_Z$\W0H.BV,L/&;]G=8B__#ESKF7AR@BK MY#:]6W[:!9RS7NBPWG-4TVN]:?H@/%[62*!YGV.8B"KN4[=+O_G=O!;C*KU" M94N91*=[$5/V.Z6YU[4NBBPHZ\H7::E<>9&K[NF,4Z7S/#DJ3G/6I[VOC=D1 M`KM4])78]O2SOEQ28-U,U=T,;7*NI3-56;['9:Q5+F&O[F6WW>FV=F%+3,%9 M9:XYB=L:2XNV>D&-?_JH=:9OB5IT=HWLX!^ATQ1K[%1;,LMX.A>_\3FXS@SV MJ,.URERM!YF59:[L<4K3,IK%DCSCVI0"A(^IQ,W4'`B?T=,O6-ZJJSY$EOS, M^:%]7Z??>8_$@*@S5=TFDV8>D7CRR.JI@'1D5\)'^[(/'2FG%DE.>GK,<=:Q MK:2(TG*_;979=U_J[=Z?P^-=-Y6[_()N4(7DH'K@\\LG%FUI>Y#DH;"%331T MCM)3$X^^O*82#K4<H3NU*HW+"K7@5=&<:M*]J]S7(RW$O*NB9L:ZSW-61TUY M:6=K-E"<:-FL[U#&=K]X\=5KDQ1<)9HWW+!4KBA?Y=/]-/]:^V$[F=C6]7N^ M;!1V#+['VSEO<=[#(0,&ZWF/,M0>O*I_</ND57;2UXP:\5Q1YY*ZKT%&[S*Z MVR#;2DZMM2(I^2DRY=;&\YH=:O*OO+JM;.)0P;NCZNL7F?,9_5^;5C@,O#YR MZFN!=.41B\$],C<O=:I8?_*U?UJEXI?@).KAF'G=:<>,M0=SRDSN\YK=FC47 M;'G`ZZLL72:;1%FT3D6_+KS6UB:(LCI:BB^JF:^]V&]-=XJ"ZW1^!8:7S/7I M/<>YO6)[E*LCMM<I;^B/.M,(F+NJGK#>-;2,L/%H]SRSHSAMGX?-BFFS7WR9 MG.Q91QZJ4:E0SN/YWJQ2NMMS]1.W]G<)YW:YO=$+V["SVC(SI9\E]]QLL=P' M?KMW57@U#1ULNNHY]=FZKI!K@79I9V\\57FPH.'TR0+MYMLRS8<<ZFP#MIY* M//IAYY>M!Q-,E.YZIJ;7N"G=$TG;VRG8KY)^)OO+WL0CU7P^WN92>!X2"+W; MI,?6G\UI5CM+XZA"MT38C?.G/`NWM>1HO)(,3RC)27^YLUC_\ANOV1(&/I$5 M^2>>5!Y-T^0Z>#;LV*[V"HM##57E@V>2$V:F_9Z<95)PVO6D1VW"M&T&262. M$/+U/LWMSQN.L_G$^B=N7/8^:-;UQ8.>3S)UK6KYGLTQC[H:<W^0QZI#V3S^ MQ<L$O]X]_M?GV(@^S\QX$F25FN?QX#[O5?4+AVX5Z=]Z;U40&[N49[/]-T\) M-2OK\Z_/?9A[0LM@RIN%ZAZ7[YD6)JLT/<^Y=>?DXF"%FAQWI;+@="6N3ZNC MW::T7%=_:,Y@%R7\F.W#Z5VI*E_OOUYOMSRE6U=F394,G!^:4^NK56IM5G.\ M]JB^?\Q3WL.E9VU`N.@1VTK>4P.*UDJ<GP)RW&^2`E_TA7T7C;KZBC5KGTV9 M0#+'L0#UB/+FITDMG\[[A=Z\]WC?\S\F\WRU:%W0\U+#K8"/W679SH>IN>=\ M7^[+XZ\=6.N2?ZWFJ5+ZZUVS&19VN#G.N["-J8@AN<-'/'Y^%RMS)ZFDE9&O MZVD$Z]V!K)R6(^T7,]VWY1K/-Y83:FR:6WK'E4'Z\+?&:OOK"T_)]2O["9L= M[9]KV/#9+NU%F;2':YR%:,_O?2]5E>5[+#3Z1*02+WD\MG92BHMYW>AX:Z_K MQV?<?=(?%?OD'^VLD#TU,T^IYF+)F1AK8[_B<(U%U[)7.#!="+6GE-3:#5F? MWBI_]L.>5[N[/W(a)W-A3%.7TP4*X9C`DPEEKEK%YKL?^$D#/3/+GP6<NR;\_0 M\KEO'"JVP?N^<?9N@<1#,G9>*TYW&UE&'CQR)/]ZQ(G+6<IAY8DQ>B:S@Y5W M]3IN,CF@H%8V3_5<3V9QF3K7BV4AKGF,`ZMB`T5\--HT:Z[X-*9\+OBF_+DJ MF;+CY4!QLB=[6-7C,N-0+=OY&Z)2OP9?E>R*2KRH]I)3(^I,R]07#\++'-IV M'6<I$JF/>NZ1;>QEP]@%;[*>D\)NS=3Q4IO,=^"/,BX5\L;U#QU<[-KG:H@L M:=K6V%P.A]KA397/*QPOEUQLZ.,IW'JYT6^PJ/N6I:=(^B-#T_OV33=*TH4< M%S[(UCN=YZ7[+B_?]?>^QMN;HT6+%]S)./<Y0>N/?B^EBK,FUKF;:F6/"P=G M-`UIFWCQ;;P8E'^LNTPH6&+^Q;M]887;N)I^&\S0JG2Y7H:*+#C:41M5>'CZ MDYNWGRET\A<S;3F]<E#N*HM;Z-Z200/M[=-^NVGNOIUM]5[=$W<C\B@AF8/7 MNHM@@:WY\:[[`X\M-CI;H^4QE7<V^S;=<Q]<U%8YQ"U[:M?"7/A9*=,I,M3^ MT<Z.)29VIOV%C\J^O%^B>$0MH'/1X<,#JR^%=<P-X9U2.CM"(-GFMLUM"\V3 M@NF"IS9M\INN&=G>SUQGV>IF4I]'+DJ]G%H<LM+TV?*"R&G+^,[Q[])QU[=, M8^=H:'#?YWS?*6O/L_[<SUN=ZS:]G[2X^MB9K1^;+S7/JLP[?B1/;'6V\JL= M7GJ5W=I?;YO6!;Q:O.K,AL',9)NZ;A/A#3U/=?+$/EW<'1"N$3/M4E_!^;?G M/(*G'<J=HGK#($:B.R@N+[T@1ZLTOGM%7/8%/\G"A&G9=?G[12NJ5%:J-?E> M>>_<M"/))37TDLN#@A2W0?>PUN]&TU:UB>;-V.*=T4O*U5AG]Y[UR,T7;\1+ MUCV6;UIE;[LNL-_;8MZ7@V)[N^NM']:*']8SNV6;*%F5HYM8YWK&(/RDX-$# MK;TQ$;N77YQ6W65RD?RD=`>W3GS;FK-DKM>%'QS/DK:DJ+Y<$M3?W#3YV:RE MK6?+^\^I\]]Y.EEU>U?_T0&AHJCTP-7^:R5:W)A?/<[AE?:($W:;_72=I>"" M(U/+EO>%7VR-CNH^!4J\4MY)U5R[F\#B%W4F=>75P\F,HG)W9C@M5;0*E7X9 MOE'Z;<.G#QJ]^UK,F[\.W3/]VG-58NCN4:N'E8;+$Z+/.<\(MLR)G[O;6X%U M8$!A6?52L7/?Y22&"E9)71!@6-JX1,3BXA^3+'+OW=*L2KVZTS*M'0C]\8UO MDV:2U_<#/?VWEI]](L6UZ7UC86EC4=Z@C-4G-BGE%HOIO+$R77*"47K3^0=" M(a)M,5F#5TU(.CW^TPKO#TZ;KUY,K4J<G]MZ_SN2SKVYFM=3]G7OFA[-S;'PQ9 M]Z_2<:EAM=!,=;K#JM!FL>>@3>?#HR8A]?Y1CK<.OA82[3LI;OU8_>O[?0?5 MQ,K?GPG>>&%%?5#`K(PNP=0N]\#5HH66/(O3SJ^./I^Q?.I^MZG)Q:N6?W*3 MO=)QZ1//_@:!Y&+AD_=V11KDWEC#NJO<7W@W?Y_5SAL.:3>FK]=<5^L@R]+\ MGEJWZ^)+'S6%&51&J*W/,&(M*<J4"INQ;6F-2_[2A`Y8BQG&O4+S+]\^IW%D ML%E+.#S7/]%&-&"!4*I@7+,+Y6/]SH8E]Q9GZTW>6;M=Z$7VUM_^$(RU`M_L M;0?6U9^*;CI8*R^OGK?=7_^S=8#ODRUO7EW]6#SI^,-]^K_O"%:X(;F<^1YP MB#OQO>2MYS5>ZYK3QU1SCK^]GZQN))';_\94RMJL,UG)UNQY9$J/,1=L86AP M6M[9Y#:MFRYFM7F-11^?++3A,IN4/F>_WI+=MN=:%V_F%P[=EB5W[%:Y_XY( M%RO.K'[OK.AGCB3E*+?30K>/KY#;V]01RL/.>UK:>9:T15!"9I[E!U-%ZTJS M5`NYU6J=^[?/2=^@UIH:D>#_T=ZE9D7>%[&4RT9[<TMJX@N"W'C%<CV-EN<I MW<U_*&GR6"&B8$6UYV[?HYL?*WDO6)^I;E!9I&-6&H_R]GLY:GQ3>7DT<.J- MD!OQ8O)-TL]NQ:^"EDG#E>(SF7;Q7K_%WEQ1\8(0NW]1;N%5);'*/+'8BQQO M;JSHE5>I"P^4;(Q^=W8-_T,GM0N=5I_6RFRJ/!"[R9:UI+9$SU:4T\E$-44U M[E+H39\#S=_$4@:WI#1UA@IF]-OF[V0MT3)*K>XO"`O),CC0>=)^1DA\=9B` MAOYS#?86K2\7G%*2*A_Z6][=S1U\@)P8"W6H((KAN3#G00??/4D/II;*Y];, M&QA`:N'3+_+1/"\X^5W"$@VUV%V;0HVK`\2TKJ5UFN9%UI<KJG=&UC<>"RQP M\6Y^U-'3<74@HUS[;M+IF2OW!9YT?J5?G):ZN5PTR*2.W\PC[DY:3&)J5]G< MLQS9_29J-GWO-&>G"MUW,6`YM%C$_GI%*8NM07O)OAN+.3[S;=@@4E]7W&K^ M:9-D<[QWK/J'_2"\RLOXH;7Q_</2LY/F;]',WC+/R,Y?S^]EU2YGO@7Q[D\L M!`)FKJPI=I;<?8`K)#'B]K+G_!7525*/DF3855>[ON>N:ENHD+!?:F_AG"7K MQ(1CJK*/YEB)+$QW]]]N<%/&*'Y#_5*)^O+[K]V]^E4;!O3/I(M969BE/$CE MYEA>>,\_4KKZTX&3[0?#5,_WZG\P?9T4>S+TS=&G5FOL0B3")/MCNI,O68KY M/SIZ:V/3)WZ.R&(E>R^#4M*WHGNIV=/:7S_]_5)WV'>O^M5=@EPA:>YV1FO" MO8]EQ"XYQYJN(^(68I`^N5+&?,WCQ!#GSU"3=Z\2V;@BKR7Y4M&2GJ'UN8.K MC^Q(4=U<IJ,[A67Z8K9UEXZ;ZQSB9-/E9]*+90Z5%MR36!]C**]RX,:TM6MT MMM=/UN";;JFS8/H50QYV65??/5&/!O7L6X3BC@U(QLD6EQ_:V/HI>4#K1?/& MNVI3O*5Z-]^)V]WI%:&7K..^,_MM:/49N]WISR/59):YZKY-$+&7;:Q0RU"\ M;[-;U[QG@ZROW_M`'74//SV+XME'U&?.[T\)K+K;$&;:TN;>$)J]9J:SG=G: M_>D[C)=9NCV?_C'HZ"$7)0_24<.]N;TO+V682*R,GW>.=V4\I6=RA9?$QWL- M.?J,UA(KI5)4]IY\KU_8Z,GKQ[5K3>V./IM5@ZR[-YO/3UC3]LQJ#]N+RY%- M[5N2-3,/S>NT.),89.K`D!-Z097OB;!&W'X7#O\\W>"5%7EZ'+*L1<>RVU5; M#$YS+-^@.F,G;S;7`G_;@(#4]?S.-TUW?9;.R.\QC[&#N:8:9$`#>=>[^-?O M.&R#NMZQ\W>D/EG0\RZ?Y?*4-\^2K!]_TV+3:6YEGKLQY_$#Q1=/=P@=_Q"I M&;&DI?CYFGOQ^@N<=0X]/R7P7%AT\YKYO9H5`WZ?%ZW4W>APO_61Y+?XH`][ MQ"(,7PP<YJ_A4J_\E*G/<DFT/ICOCZS#!_<=?J9I?"NEJH\_-,O;(CC0:,TK MH?>#FI^2EEF=K,XZWW!RL8EM7?0+K9:N7I/.!1?#XS;%!LET60:N,;RG>=+_ MLGW)RD;%]<M=7QAU*BY<Y*A8&MQ[3%2C,_CU?,-(?25[TO"JV7\`M56O0[]< MN<.S,PJ<!<O.L*-%PBE4]`6.(`AX`EFP`:(_<`'.\!<*M($[\`:!,([2G(`/ M\(*YV\9(0HN&7E"".\P5"/.H_TUYX\,0L2/!*)"0D/A)SA$8RS,VKFME3!O- M!O]#?8O66\?VE"X8VU/>,.8//&#H"5$6K`/KX3$`]IL+I/_E_IH,!``;(`$[ MP/5C]5<.`.UW0V1T!,S`%#+[X\(]`;%"S`W,C,A@.<0-AAV,7H:L%"M`TB;! M-"N`'`,-8;&.\+*A*K@!<2`/D+*0`/,,$ILT8#<@`=ZT',"7I@FTI5$*=HH6 M!,L,148)!A:`C*5:_%2J`I9*)J22"*F]5*DDV"K".1H)IA5J#!BP3..?RE3$ M,AD(F>31,LFPW6.EF0-&+,W\I]*4L#1&0AK#:&D,@'>XW:/:;`B8L$3#GTI4 M!N@;<R;`)LTX6APCJIO`*%':@!E+TOZI)!4LB1E*8AHMB8D%X&X30-K-@B7H M_U3"`BR!!4I@'BV!>=*H>A@"RB]:I(JE4*`4EM%26+A0/4;UC2E@Q9),?RI) M#4MBA9(HHR511G1A\JB::0(=[?=#)P":A@1@*UV`*W7Z"83RS/$`<X2R4>@+ MAY<X,(!C`0TK6I@%K+53P#N\5P2J52C,BX:@)Z[9!H#&T,+9)-W99'4P#=6? MI(YIP_5'>5'-N9%K!E^:.<#^F6W<I=-)9`JL+X#U13L&R,!2>$AHYP!V7#<W MR"D.^R((CLUU5"EH)PMQ6(8$:2XN`]77!T\#*)4#CG8:X9`B"W1A;@62+*Z[ M+LR+)EMQ.(Y=0`AN)RO44URO$"1=%:R`M=`AH:O&@Z5[PI\/V(@GZE^T?9(J M,(<E66!.]I^41(QG,N`'G`!_IL`]_,T$*I<$B)D'38U4IW.\,PUR-:$Z(Z,7 M3L@3'N_I@;YQY03HS12QG0D/0#,=@&TA]FA`^VF@/3W0+0R]H1*"*`QQ*D01 MB*(0Q2!.@R@.<3H@]M*0!,0>'<C]!5V)F8#8(T0&XFR(<P"QEPC:WP/UZ7R` M9U,\`Z+VH?D%S0IH'*,1B,80ZA&DNT(a)K^IB(.,I/PGOI`!I0H*.2J#)'4U%/ M*=%14=\ITU%1;ZK045'_+J"CHAY7I:,.GX^FXO>`=%1TG<AT5'3E&.BHZ%HR MTE'1U66BHZ+KS4Q'11K`0D=%.D&AHR(M8:6C(KUAHZ,B36*GHR+=FD1'1=K& M04=%^L=)1T4:R45'13K*34=%6LM#1T5Z/)F.BC2;EXZ*=)V/CHJTGY^.BL:# M`!T5C9`I=-1I@*C=:*HX(&HWFHK&E3`=%8VTJ714-/9$Z*AH-(K24='X%*.C MHA$[C8Z*QK`X'16-ZNET5#3.)>BH:.1+TE'17#"#CHIF!RDZ*IHOI.FH:`:9 M24=%<\HL.BJ:963HJ&@>F4U'1?/('#HJFD?FTE'1/#*/CHKF$5DZ*II'YM-1 MT3PB1T=%XU*-CCH\#]+#O^4.H`6H0"'A$#^34[`+!@7?"BGX<SD*,PY9<$C! M(2L.V7#(CD.\P1$%[_=`X<0AWBJ)@C=&HO#@<#(.>7&(=\^BX+VF*`(XG()# M01P*X5`8AU-Q*()#41R*X7`:#L5Q.!V'V.2B2.)P!@ZQZRA%&H<S<8@WHJ+( MX'`V#N?@<"X.Y^%0%H?S<2B'0WD<*N!0$8=*.%3&H0H.%^!0%8=J.!S1-72O M92,NZB@='`^<J!A,@Z$H@9'PF&:EGJ,OJM!7-?>H'O(H#5T56JWDIN9MI::C MZX6NC2V\Z+]!3(18!Y$!7GY1,E%77ML#0_'1O+9\0_Q;/6!>/X@!U#KP3L\9 MBM\*)?02'[LR8[\;]*T6TA]C$C%^$)J0D$Z2>FT!:CI++[HF9,:Q_KU#P(Z% MR"]&M9D5J'D9&"43V]\P.9TJW9'Q0(@E35=Y"+3K$'F&>U$;B+WC)N*8MG7K M5N0;SHU,S%ZDU]R`@AV%<.68T``1?#<)#`]R$A[D7("A=Q\@G(N(Z8ZUE[JC M%PTXP_R$TQ'J3B9J_E5@Q!D)R4?]'P#8>Y%R#3LCP>P4U-6`0K@DE2*7:`KA MF$0BD]%AQ#T)`D\O\3!"E(#L\<F`QMT)7E5+6`(:!H2\:CQ^"7F,#$@Y%C&0 M,/^()'4FXM*B.N;#CD(=;`7'7!ULZ(B1@3ZQ11]0)$&65(AI$#,@UD"\!]$# M5C8`XE:(VR!>@E@,40UVHP[$?;"X9(@%$"L@\E$_V51$#YL0T;9]>1`O0_S` MA*94D;^)+/`JX*D(I,!R3T+TAN6&0V2G*4,?HB5=6<)49,1RA*FRAH:(!R=S MJD$F#I;!Z50<6/Q8$9(%>G#"M`<V8"DT@O2!&3RSA'$KL!B80#Y[H`,YT5H) MXD$K(,'8-$%&1P"4&HS-)Q]H\B$C1!].V"IP4I;%:RC.ORS9A5KR<`X'FC1[ M:-I8`6.8L@[*L8<U"H3GWC`-&9/.F+84YK#&:4L@KSPLUP&VP`4:40[`"-<Q M`(:A,.8%CRY0`F'B(DYOJC'G#M,<8#V0.>H*CX[8$'.`+:?E0-+1;P&\O:CA MOD'ME(,465@7']@K_[L]3)3\YSW\;RSYWZ)5_Y9VNOY_VTZ3?UU+Y>%C^;^O MI=Q@8(@`M*C*`._`3-"D8H'/*^AIY3LUC7YO7A+(\[S'!9_'&'^6-AA^EL\_ M3CMNB&OL#X#5+DM$\S(Y7_\L[0KGL^GCR=RV1EA>_'SCH9_Q[9/G5QZ/[P2% M:R'7.&DVPO*ZX_&]F6,P;IHG3[C>>&GRYHP&XZ4]W=)K-EZ:J>\-J_'2+LPX M9SM>&@D=M$D_*+2[GQ#+N]0</USX:7,P4',,YV'Z21XF:AY9_%Q.S<="GX^% M)I\LE#R2EY4N+^N8O+)0\VCRLX_-S_Z3_+*P9K0\'&-X.,;AD84:/HJ/:S0? MUR_X9&$K1_/RC.+E^1->6;Q0,3Z0P&PL?\I/TMBA1<`5O9[$$YWPG1]MWK*> MQ&QF1`++(?K,@FR7>YFH0L8"`V:M)?-$RWW#K+5D9LPRG'E$.T:S'&?ZP7*< M";&,4A@PHC"CV7PI/]A\*8B-3H?`B`Z-9M5F_\&JS8Y8?ZI68$2M1K-S<_Y@ MY^9$[.-J&AC1M-$B#"?S1-\<P"(,)R,1OU0^,*)\H\4(\O\0(\B/Q/RI/H(1 M?1PMRER()WKM5RS*7`B)^DLJ"D94=+0X<9$?XL1%D+B_HK6$@OQEU2+T1&Y" MO>A$3*C7S]3K/YCTR$1MZ%(a)G-).NUR<T\W]5,ZFUH>?]">O(L]I_4-@$Z_\D M*\R!S25:MN'_O5$M<B$CT>CQGS8=F1^T<60"T,:1Z4(;1X_ZM'%DHM#&D6E% M&T?F%&T<F4FT<62FT<:1Z4(;1R87;1R9(;1Q9`;1QH<M0GW8WC9H:N+NU`:C M8#TDLE-&NG-,-P[]8^`&?PY#VH;FXL:.`2[^1BZ!XDKFP-C<2EX=&)J;ZQDK MFUB",:ECHO3`2&(\`+0!@QO:2HT$OH,M@#"[;,E$./)ZX)\"VJ.-3!,GP?), M+*WU*0Q_5KL.ZMRBB8^,T*A';YG^+[:)M)6$7U@@O#@E&-=6G'H/'CZ2A_4# MO4\YCEZZ:!,6[A*!/:@Z9&8&)D8F,@-C+&W-(!RC'JWPRHH+"`#BU#49M/+C M(a)QT?O6&Z,I1#!DQ,)#*)A9G\XS9.JY9;46`)0K%#%G*-`D!1&I?.SLQ(1C!N MZ3IX98=PL92`#?>C_`[/:LG$@`+@1K2&035$=,Z`'RRN0;1B1)V+1#*"W[AI MGPR(9Y7AN\]TU!'18`+^$9QD+F7)`3GP\BK(H0LN!-62<!@P'_L@^`^`4(BA MH<D_XN)@^$JR@24@"&H&6HE$VND$UL/CKU8H_S9\AW<P1K8Q6@D(U6G;=NS] M%[/UW!E[*6#.S.Q'L/4@FC3L800`>M>,.(\#8JBA?WU"LT<^(!:.T+Z7R$^A M$1`+1!T`OU4%'P"Q"#2)*DN01+PA5R(1BSW:).)M.7IOC9X?T5MQ]-;<&1[1 M#<V31(R[0!+ASQ%!G6\Z&`F?#507<=9A#R"B,'2.9"\)\A=?YN[EM-Z=)AW2 MQIZC^IKZ^'LY>@(G%$?EC_HO(#C`$1V5JPB"/-$YJHN)NY._3X"/:R#ZCR%G M<559V&G:2.Z:VBQTP.=4P.?VES-/RUTEX?,KL0[HGZ,8J'5!QVO4(QKJ=.;* M!$S`!$S`!$S`!$S`!$S`!$S`!$S`7X3Q[']$(3^H>9`D.Y5[_R%H_\_]<EX? MTIC&T`Q):$EQ^!LG`'P!8:.CSP716L!.0*P%'`#$6D`2(!PET@"Q%(_6#)!= MG@,(F[X($';T=4#]UVU`R$;_D(W6!-K!:%L?K2.L\'%R]+1R<8+&.V$C)Q&V M,DIC`"/?C:#E&G1\R4T!PZ_`QCN*<8_8X.*L8!(W(085B9J!_W88#!OJ$$Z3 MB/8BF$4EH^^6$=,JJIPL:APA6N]P,%^J[[#$>JD^3ITT3#%$_]QK^:.5.O"( MOG@-!XN!`E"$H3X,E>'Y/*`*CRHP-@\[>^GC,U48*L`8<N`C?JHPCSPP`'KP M7`D>-^%:(KEOJ.6B\C>"J?@XC(!Z1%</?=<Q'?SW?(*.9`TO3"+YRV$Z;7EC MRQ6C*_?O;1)`6]X$3,`$3,`$3,`$3,`$3,`$3,"_%Y!E-&P?(_L565W_R;X* MR"?NK^ZK@/(BJU("HB3X[]M7`<D=NZ^"!D2TSY,6-7T1(-Z_(RM8%Z#_JB!V M<UM,3?\&T9!Z/HS_%P&Y.*$=HL1ARY'M[/\WG4@$`!-I6!;2(6968BVIE$C& M#DMKI?_H2D<^#GMZUB/_!B-`]94"J,\=\8=R_Q38`/E'^0C^G(/8^Z.;GSB7 M!U;XDSU/X/)+GO&`D^K;_7?*%X?8/H<XMP$^^/-`??Q)7A!V01N[P]BO0!BV M'XU7-&[_:OD(0F6((Q.PQ*5ZX;6<4/RAH2L8WO$/?4[H@]W?QH-9_Z#_\=X< M5,<Y)KJ6_[WZJ,+RT;SU=\K'3KG4\DGX4THOX`O,H!9X_(KMIS`9EH\T'LV7 M?Z?_ATLB2D6?D@<"<SP6/7_)-Q8$`.E'V\<K?WC<#1]ITU#D_^K<-@%_#B1X M]1G8"-T=.W>C^_<8?S9]'Z<@+Q?O0/Q,8&*):)"$!Q,ZEQU.EU4%']2R_,`$ M_#\._P502P$"%``4````"`!GF7`GO$"DFS$S````F```"@```````````"`` FMH$`````351$+3$S+F1O8U!+!08``````0`!`#@```!9,P`````= ` end

1 0

Re: H.323 Annex I
by Roy, Radhika R, ALARC 24 Nov '99

24 Nov '99

Hi, Barry and All: I understand Barry's points. The scope of mobility work can be from H.323 application layer to the link layer. The fundamental question is: What should be the scope of Annex I in the context of H.323 (H.225.0, H.245)? My guess is that we are not addressing all problems related to mobility unless we can use in the context of H.323. The scope of mobility in the IP layer is very big. It includes mobile IP, cellular IP, and others. IETF is doing fine in addressing those problems. Even IMT-2000, 3GPP, 3GIP, TIPHON, IMTC, and other forums are also addressing the mobility problems. An enormous amount of work has been started worldwide to address mobility problems. Let those standard bodies/fora address their mobility problems as they want. Our objective is to limit our scope within H.323 mobility. What Ed wanted, I guess, to clarify that unless any work is related to H.323 mobility, we should not address those items. Therefore, H.323 Annex H should be focused FIRST. Now we have to make sure that the work of Annex I is being related to H.323 (please also see my email). So far, Annex I has NOT clarified this. I tend to agree with you that the work of H.323 Annex I can go forward in parallel with H.323 Annex H. In H.323 Annex H work, we also find that there is an item called "Network point of Attachment." The network point of attachment may include IP (or ATM) addresses. If people want to implement H.323 mobility over the IP network, I believe that H.323 Annex I can link its work to mobile IP and cellular IP. Annex H may also identify some issues for implementing to the IP network using the mobile IP and cellular IP. (Forums like IMTC, TIPHON, 3GPP, and 3GIP may also take the H.323 mobility work for implementation to the IP network. ATM Forum may also use this work for implementing to the ATM network.) So, I am proposing that you and other interested companies continue to develop H.323 Annex I bringing contributions. If needed, we can also arrange separate Ad Hoc meetings solely dedicated to Annex I. Best regards, Radhika -----Original Message----- From: Barry Aronson [SMTP:baronson@ieee.org] Sent: Wednesday, November 24, 1999 9:49 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex I Ed, (First, I assume you mean H.323 Annex I when you write H.246 Annex I.) Regarding H.323, I don't see at all how Annex I is dependent on Annex H. In fact, they are (and should be) orthogonal. Put simply, Annex I deals with everything from H.225, inclusive, on down in the context of error prone channels and mobile environments (e.g., cellular networks). This includes IP. There may be some recommendations regarding error resiliency in the codecs, but this should be approached cautiously. Ideally, an H.323 application will use exactly the same interface and messages currently used with regard to H.225 as it will when enhanced with Annex I. The changes will be quite localized, which will help with adoption and interoperability with existing systems. Annex I will be extremely useful without Annex H because H.323 defines a very simple call model that utilizes the Network Address and Call Signaling Channel TSAP Identifier of the called terminal -- no gatekeeper is needed. With Mobile IP name services don't have to be updated. In fact, Gatekeepers could be used with Annex I by using Mobile IP and automatic Gatekeeper discovery (presumably, a cellular terminal has been thoroughly authenticated long before having an IP connection). Even if this model is never used, separating Annex I in this way is greatly beneficial from a standards development point of view. Work can proceed without being affected by other development. Annex H deals with a terminal, user, or service that has moved either discretely or continuously. Clearly, user and service mobility can occur in a non-wireless setting. Therefore, there should be no dependency on Annex I for these functions. Conversely, there is no reason to address user and service mobility in Annex I. Terminal mobility may occur without the functionality provided in Annex I. For example, there could exist a large, homogeneous IP network running on Ethernet in which it was possible to move one's laptop from one link layer point of attachment to another and cause a change in IP address (due to being in a different subnet) and H.323 Gatekeeper zone, but still be a functioning host (through DHCP, etc.). Now, in this situation, Annex I could come into play since Mobile IP falls under Annex I and Mobile IP could deal with the changed IP address. However, this may not be the best solution. Since the new IP address will remain in effect until another discrete location change (ignore dynamic IP addresses as this problem exists for stationary terminals), it seems more efficient to update the name servers or Gatekeepers than to use Mobile IP. The question is, what procedures can be defined in Annex H that would assist this? Also, these techniques do not necessarily have to be efficient in the cellular world (Annex I will take care of that situation) since having an efficient way to deal with semi-permanent (hey, an oxymoron!) subnet changes would be a huge win. Although I started by stating that Annex I and H were orthogonal, it seems there is an overlap in the area of terminal mobility. This gets back to the original division proposed by Dale in Santiago: Annex I was to be Terminal Mobility and Annex H User and Service Mobility. If we went back to that, it might simplify things. On the other hand, there is a rational for dividing along the lines of radio-link/cellular/mobile vs. generic mobility, even if terminal mobility was covered in both. Resolving conflicts would be easy. Just insert statements like "when connected via radio link and/or the network point of attachment could change during a call, the procedures defined in Annex I shall be followed". But then again, it would be nice if there was a clear procedure in one recommendation that dealt with terminal mobility. Thoughts anyone? Barry Aronson Toshiba Corp. 33 Lake Shore Dr. Beverly, MA 01915-1907 USA Voice: +1 978 232 3994 Fax: +1 978 232 9220 Mobile: +1 978 902 0768 (mostly worldwide) E-mail: baronson(a)ieee.org H.320 and H.324 video conference available on request > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Edgar Martinez [1] > Sent: Tuesday, November 23, 1999 9:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > Importance: High > > > Dear All, > > I concur, with most of the attached email. > > And I have just a couple of comments. Until we resolve the pure case > of H.323 mobility and Interworking with PLMN in the application > layer. H.246 Annex I and Annex E will be delayed, I believe that > Annex I and Annex E are depended on H.323 Annex-H. Because, > the required parameters and network functions for the H.323 pure > mobility and Interworking case needs to be defined in H.323 > Annex-H. And expanded in H.246 Annex-I and Annex-E. > > If we do not get the H.323 mobility and interworking > parameters and functions defined, H.246 annex-i and annex-e > will be working in the dark. > > Because of the H.323 framework that we have to use > (already defined e.g., GK, GW, Terminals etc.) > and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS) > we need to work top-down (not) buttom-up. > Lets focus on H.323 Annex-H to make sure that it has the > network elements that can be re-used in H.246 Annex-I > and Annex-E. > > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Everyone: > > > > We have now three annexes related to mobility: > > * H.323 Annex H: User, Service, and Terminal Mobility in H.323 > > * H.323 Annex I: Packet-based Multimedia Telephony over > Error Prone > > Channel > > * H.246 Annex E: Interworking between Existing H.323 Systems and > > Existing Mobile Networks > > > > Per my earlier email, I promised that I would be providing some notes > > related to Annex I: Packet-based Multimedia Telephony over Error Prone > > Channel. > > > > Every Annex in H.323 has some direct relationship to the H.323 > application > > layer. Even the informational Appendix II - "Transport Level Resource > > Reservation Procedures" - shows how the RSVP messages are being > used in the > > context of H.323 signaling messages. > > > > The way Annex I has been structured shows that it will provide > information > > related to bit rate, bit error rate, delay, jitter, and IP > issues related to > > radio networks (e.g., mobile IP [home/care-of IP, home/foreign > IP network]). > > > > I understand that additional error correction and concealment techniques > > that may help specifically H.323 are the main purpose of this annex. My > > guess is that these proposed concealment techniques will be > used somewhere > > below the H.323 layer. If it is so, is not the case that H.323 > does not need > > to be aware of these lower layer techniques? > > > > Now the question is: Can this work of Annex I be directly related to the > > H.323 application layer signaling messages? > > > > If the answer is yes, the next question is: Is this present structure of > > Annex I good enough to satisfy our objectives? > > > > If the answer is no, will it be very helpful in H.323 even as > informational > > annex? > > > > However, I see that there is an additional scope related to this work of > > Annex I to the H.323 layer signaling messages. IP related > issues can be the > > major topic that will really be very useful to relate the network layer > > signaling schemes in mobile environment (e.g., mobile IP) to > those of the > > H.323 mobility. > > > > In this context, I see that there are some works that have been > performed > > related to the IP networking in mobile environment. It appears > that mobile > > IP has some problems: 1. If the mobile host moves very frequently and 2. > > Inefficiency for keeping too many reserved IP addresses in the > pool by the > > foreign agent for allocation to mobile hosts. > > > > To work around those problems, there has been enhancement of mobile IP > > (e.g., cellular IP) complementing the mobile IP solution. > > > > The important point is that they have been using the concept of > cells, cell > > IDs, and network IDs packet-switched based IP mobile networking > environment. > > A cell can be pico-, micro-, and macro-cell depending on the radio range > > which is a function of power. Cells are usually inter-connected > by the LAN > > in the case of IP networking. > > > > (By the way, none has used the concept of so-called location area [LA] > > concept in the IP networking either in the mobile IP or in the > cellular IP. > > I am curious to know why these prototype products and network > architectures > > do not contain the concept of LA? Can anyone provide more insights about > > this? Personally, I would love to relate the LAs with cells. > Indirectly, it > > may also help to inter-work with that of the circuit-switched based > > cellular-PSTN network.) > > > > The important point is that we can start with the existing standard of > > IETF's mobile IP/cellular IP. We can see that switching a cell during > > communications does not always mean changes in IP addresses. > That is, this > > handover (at layer 2) may be transparent to the IP network > layer (layer 3). > > No resources in the IP layer will be affected. If the switching in cells > > causes the change in the IP address during communications, the > handoff will > > cause the resource allocation and de-allocation in the IP layer > during and > > after handoffs. > > > > Extending the same analogy, we can assume that switching of the > cell may or > > may not cause any change in the H.323 application layer. If it > affects the > > H.323 layer, the resources in the H.323 layer have to be allocated and > > de-allocated in the H.323 layer during and after the handoff. > > > > The other important concept is that the cell IDs can also be related to > > H.323 zone IDs and so on. > > > > It appears that the mobility solution can be related to the link layer > > (layer 2) to the network layer (IP layer) mobility and the > H.323 application > > layer and vice versa. As a test case, people may also try to see how the > > application layer H.323 mobility solution (e.g., APC-1651, > APC-1646) can be > > implemented to the network/link layer mobile/cellular IP solution > > > > In this way, I see a wonderful ray of light how the work of > Annex I can be > > related to that of Annex H. > > > > Last of all, I would request the editor to expand the scope Annex I. If > > needed, I may also propose to include this item in the upcoming/future > > conference call. > > > > In the same token, I may also provide some comments related to > H.246 Annex E > > in the future. > > > > I would request all SG16 members to look into this proposal and > help us with > > their comments. > > > > Best regards, > > Radhika R. Roy > > H.323 Ad Hoc Mobility Group > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ >

1 0

H.246 Annex E
by Roy, Radhika R, ALARC 24 Nov '99

24 Nov '99

Hi, Everyone: Now I am providing some inputs related to H.246 Annex E - Interworking between Existing (Fixed) H.323 Systems and Existing Mobile Networks. This work item has not been discussed completely in the last Red Bank Q.12-14/16 meeting. However, a separate annex for this work item has been proposed. This annex has been proposed as a result of APC-1671 and APC-1672. An editor is yet to be assigned for this annex. In the last H.323 Mobility Ad Hoc conference call held on November 17, Paul Reddy of Intel has been assigned as an Ad Hoc editor to continue this work. * First, this work can only proceed independent of H.323 Annex H if it is considered that H.323 terminals are fixed. * Second, what should be the scope of this annex? I have couple of suggestions: * Let the ad hoc editor define the scope of the work. * Let the ad hoc editor formulate a work plan. Once the editor has some thoughts along the line, let us discuss this in the SG16 reflector initially. Depending on the responses, we may even consider let the editor and all other interested companies bring contributions along this line for developing this annex. If needed, we may even plan separate Ad Hoc meetings completely focusing on this H.246 Annex E. Our main aim is to make progress in all areas as much as possible with clear goals. I would request that all SG16 members provide their comments how the work of H.246 Annex E should proceed. It appears that almost all contributions and interests have primarily been focused on H.323 Mobility work (e.g., H.323 Annex H). Keeping this in mind, we must be responsive to the interest of our SG16 members. That is, our upcoming Ad Hoc conference call on November 29, 1999 should primarily focus on H.323 Annex H: H.323 User, Terminal, and Service Mobility. Best regards, Radhika R. Roy H.323 Ad Hoc Mobility Group AT&T +1 732 420 1580 rrroy(a)att.com

1 0

Re: H.323 Annex I
by Roy, Radhika R, ALARC 24 Nov '99

24 Nov '99

Hi, Barry and All: I understand Barry's points. The scope of mobility work can be from H.323 application layer to the link layer. The fundamenta question is: What should be the scope of Annex I in the context of H.323 (H.225.0, H.245)? My guess is that we are not addressing all problems related to mobility unless we can use in the context of H.323. The scope of mobility in the IP layer is very big. It includes mobile IP, cellular IP, and others. IETF is doing fine in addressing those problems. Even IMT-2000, 3GPP, 3GIP, TIPHON, IMTC, and other forums are also addressing the mobility problems. An enormous amount of work has been started worldwide to address mobility problems. Let those standard bodies/fora address their mobility problems as they want. Our objective is to limit our scope within H.323 mobility. What Ed wanted, I guess, to clarify that unless any work is related to H.323 mobility, we should not address those items. Therefore, H.323 Annex H should be focused FIRST. Now we have to make sure that the work of Annex I is being related to H.323 (please also see my email). So far, Annex I has NOT clarified this. I tend to agree with you that the work of H.323 Annex I can go forward in parallet with H.323 Annex H. In H.323 Annex H work, we also find that there is an item called "Network point of Attachment." The network point of attachment may include IP (or ATM) addresses. If people want to implement H.323 mobility over the IP network, I believe that H.323 Annex I can link its work to mobile IP and cellular IP. Annex H may also indetify some issues for implementing to the IP network using the mobile IP and cellular IP. (Forums like IMTC, TIPHON, 3GPP, and 3GIP may also take the H.323 mobility work for implemetation to the IP network. ATM Forum may also use this work for implementing to the ATM network.) So, I am proposing that you and other interested companies continue to develope H.323 Annex I bringing contributions. If needed, we can also arrange separate Ad Hoc meetings soley dedicated to Annex I. Best regards, Radhika > -----Original Message----- > From: Barry Aronson [SMTP:baronson@ieee.org] > Sent: Wednesday, November 24, 1999 9:49 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > > Ed, > > (First, I assume you mean H.323 Annex I when you write H.246 Annex I.) > > Regarding H.323, I don't see at all how Annex I is dependent on Annex H. > In > fact, they are (and should be) orthogonal. > > Put simply, Annex I deals with everything from H.225, inclusive, on down > in > the context of error prone channels and mobile environments (e.g., > cellular > networks). This includes IP. There may be some recommendations regarding > error resiliency in the codecs, but this should be approached cautiously. > Ideally, an H.323 application will use exactly the same interface and > messages currently used with regard to H.225 as it will when enhanced with > Annex I. The changes will be quite localized, which will help with > adoption > and interoperability with existing systems. Annex I will be extremely > useful > without Annex H because H.323 defines a very simple call model that > utilizes > the Network Address and Call Signaling Channel TSAP Identifier of the > called > terminal -- no gatekeeper is needed. With Mobile IP name services don't > have > to be updated. In fact, Gatekeepers could be used with Annex I by using > Mobile IP and automatic Gatekeeper discovery (presumably, a cellular > terminal has been thoroughly authenticated long before having an IP > connection). Even if this model is never used, separating Annex I in this > way is greatly beneficial from a standards development point of view. Work > can proceed without being affected by other development. > > Annex H deals with a terminal, user, or service that has moved either > discretely or continuously. Clearly, user and service mobility can occur > in > a non-wireless setting. Therefore, there should be no dependency on Annex > I > for these functions. Conversely, there is no reason to address user and > service mobility in Annex I. Terminal mobility may occur without the > functionality provided in Annex I. For example, there could exist a large, > homogeneous IP network running on Ethernet in which it was possible to > move > one's laptop from one link layer point of attachment to another and cause > a > change in IP address (due to being in a different subnet) and H.323 > Gatekeeper zone, but still be a functioning host (through DHCP, etc.). > Now, > in this situation, Annex I could come into play since Mobile IP falls > under > Annex I and Mobile IP could deal with the changed IP address. However, > this > may not be the best solution. Since the new IP address will remain in > effect > until another discrete location change (ignore dynamic IP addresses as > this > problem exists for stationary terminals), it seems more efficient to > update > the name servers or Gatekeepers than to use Mobile IP. The question is, > what > procedures can be defined in Annex H that would assist this? Also, these > techniques do not necessarily have to be efficient in the cellular world > (Annex I will take care of that situation) since having an efficient way > to > deal with semi-permanent (hey, an oxymoron!) subnet changes would be a > huge > win. > > Although I started by stating that Annex I and H were orthogonal, it seems > there is an overlap in the area of terminal mobility. This gets back to > the > original division proposed by Dale in Santiago: Annex I was to be Terminal > Mobility and Annex H User and Service Mobility. If we went back to that, > it > might simplify things. On the other hand, there is a rational for dividing > along the lines of radio-link/cellular/mobile vs. generic mobility, even > if > terminal mobility was covered in both. Resolving conflicts would be easy. > Just insert statements like "when connected via radio link and/or the > network point of attachment could change during a call, the procedures > defined in Annex I shall be followed". But then again, it would be nice if > there was a clear procedure in one recommendation that dealt with terminal > mobility. Thoughts anyone? > > Barry Aronson > Toshiba Corp. > 33 Lake Shore Dr. > Beverly, MA 01915-1907 > USA > > Voice: +1 978 232 3994 > Fax: +1 978 232 9220 > Mobile: +1 978 902 0768 (mostly worldwide) > E-mail: baronson(a)ieee.org > H.320 and H.324 video conference available on request > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Edgar Martinez [1] > > Sent: Tuesday, November 23, 1999 9:37 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Annex I > > Importance: High > > > > > > Dear All, > > > > I concur, with most of the attached email. > > > > And I have just a couple of comments. Until we resolve the pure case > > of H.323 mobility and Interworking with PLMN in the application > > layer. H.246 Annex I and Annex E will be delayed, I believe that > > Annex I and Annex E are depended on H.323 Annex-H. Because, > > the required parameters and network functions for the H.323 pure > > mobility and Interworking case needs to be defined in H.323 > > Annex-H. And expanded in H.246 Annex-I and Annex-E. > > > > If we do not get the H.323 mobility and interworking > > parameters and functions defined, H.246 annex-i and annex-e > > will be working in the dark. > > > > Because of the H.323 framework that we have to use > > (already defined e.g., GK, GW, Terminals etc.) > > and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS) > > we need to work top-down (not) buttom-up. > > Lets focus on H.323 Annex-H to make sure that it has the > > network elements that can be re-used in H.246 Annex-I > > and Annex-E. > > > > Ed > > > > "Roy, Radhika R, ALARC" wrote: > > > > > Hi, Everyone: > > > > > > We have now three annexes related to mobility: > > > * H.323 Annex H: User, Service, and Terminal Mobility in H.323 > > > * H.323 Annex I: Packet-based Multimedia Telephony over > > Error Prone > > > Channel > > > * H.246 Annex E: Interworking between Existing H.323 Systems and > > > Existing Mobile Networks > > > > > > Per my earlier email, I promised that I would be providing some notes > > > related to Annex I: Packet-based Multimedia Telephony over Error Prone > > > Channel. > > > > > > Every Annex in H.323 has some direct relationship to the H.323 > > application > > > layer. Even the informational Appendix II - "Transport Level Resource > > > Reservation Procedures" - shows how the RSVP messages are being > > used in the > > > context of H.323 signaling messages. > > > > > > The way Annex I has been structured shows that it will provide > > information > > > related to bit rate, bit error rate, delay, jitter, and IP > > issues related to > > > radio networks (e.g., mobile IP [home/care-of IP, home/foreign > > IP network]). > > > > > > I understand that additional error correction and concealment > techniques > > > that may help specifically H.323 are the main purpose of this annex. > My > > > guess is that these proposed concealment techniques will be > > used somewhere > > > below the H.323 layer. If it is so, is not the case that H.323 > > does not need > > > to be aware of these lower layer techniques? > > > > > > Now the question is: Can this work of Annex I be directly related to > the > > > H.323 application layer signaling messages? > > > > > > If the answer is yes, the next question is: Is this present structure > of > > > Annex I good enough to satisfy our objectives? > > > > > > If the answer is no, will it be very helpful in H.323 even as > > informational > > > annex? > > > > > > However, I see that there is an additional scope related to this work > of > > > Annex I to the H.323 layer signaling messages. IP related > > issues can be the > > > major topic that will really be very useful to relate the network > layer > > > signaling schemes in mobile environment (e.g., mobile IP) to > > those of the > > > H.323 mobility. > > > > > > In this context, I see that there are some works that have been > > performed > > > related to the IP networking in mobile environment. It appears > > that mobile > > > IP has some problems: 1. If the mobile host moves very frequently and > 2. > > > Inefficiency for keeping too many reserved IP addresses in the > > pool by the > > > foreign agent for allocation to mobile hosts. > > > > > > To work around those problems, there has been enhancement of mobile IP > > > (e.g., cellular IP) complementing the mobile IP solution. > > > > > > The important point is that they have been using the concept of > > cells, cell > > > IDs, and network IDs packet-switched based IP mobile networking > > environment. > > > A cell can be pico-, micro-, and macro-cell depending on the radio > range > > > which is a function of power. Cells are usually inter-connected > > by the LAN > > > in the case of IP networking. > > > > > > (By the way, none has used the concept of so-called location area [LA] > > > concept in the IP networking either in the mobile IP or in the > > cellular IP. > > > I am curious to know why these prototype products and network > > architectures > > > do not contain the concept of LA? Can anyone provide more insights > about > > > this? Personally, I would love to relate the LAs with cells. > > Indirectly, it > > > may also help to inter-work with that of the circuit-switched based > > > cellular-PSTN network.) > > > > > > The important point is that we can start with the existing standard of > > > IETF's mobile IP/cellular IP. We can see that switching a cell during > > > communications does not always mean changes in IP addresses. > > That is, this > > > handover (at layer 2) may be transparent to the IP network > > layer (layer 3). > > > No resources in the IP layer will be affected. If the switching in > cells > > > causes the change in the IP address during communications, the > > handoff will > > > cause the resource allocation and de-allocation in the IP layer > > during and > > > after handoffs. > > > > > > Extending the same analogy, we can assume that switching of the > > cell may or > > > may not cause any change in the H.323 application layer. If it > > affects the > > > H.323 layer, the resources in the H.323 layer have to be allocated and > > > de-allocated in the H.323 layer during and after the handoff. > > > > > > The other important concept is that the cell IDs can also be related > to > > > H.323 zone IDs and so on. > > > > > > It appears that the mobility solution can be related to the link layer > > > (layer 2) to the network layer (IP layer) mobility and the > > H.323 application > > > layer and vice versa. As a test case, people may also try to see how > the > > > application layer H.323 mobility solution (e.g., APC-1651, > > APC-1646) can be > > > implemented to the network/link layer mobile/cellular IP solution > > > > > > In this way, I see a wonderful ray of light how the work of > > Annex I can be > > > related to that of Annex H. > > > > > > Last of all, I would request the editor to expand the scope Annex I. > If > > > needed, I may also propose to include this item in the upcoming/future > > > conference call. > > > > > > In the same token, I may also provide some comments related to > > H.246 Annex E > > > in the future. > > > > > > I would request all SG16 members to look into this proposal and > > help us with > > > their comments. > > > > > > Best regards, > > > Radhika R. Roy > > > H.323 Ad Hoc Mobility Group > > > AT&T > > > +1 732 420 1580 > > > rrroy(a)att.com > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > >

1 0

Re: H.323 Annex I
by Edgar Martinez [1] 24 Nov '99

24 Nov '99

Dear All, I concur, with most of the attached email. And I have just a couple of comments. Until we resolve the pure case of H.323 mobility and Interworking with PLMN in the application layer. H.246 Annex I and Annex E will be delayed, I believe that Annex I and Annex E are depended on H.323 Annex-H. Because, the required parameters and network functions for the H.323 pure mobility and Interworking case needs to be defined in H.323 Annex-H. And expanded in H.246 Annex-I and Annex-E. If we do not get the H.323 mobility and interworking parameters and functions defined, H.246 annex-i and annex-e will be working in the dark. Because of the H.323 framework that we have to use (already defined e.g., GK, GW, Terminals etc.) and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS) we need to work top-down (not) buttom-up. Lets focus on H.323 Annex-H to make sure that it has the network elements that can be re-used in H.246 Annex-I and Annex-E. Ed "Roy, Radhika R, ALARC" wrote: > Hi, Everyone: > > We have now three annexes related to mobility: > * H.323 Annex H: User, Service, and Terminal Mobility in H.323 > * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone > Channel > * H.246 Annex E: Interworking between Existing H.323 Systems and > Existing Mobile Networks > > Per my earlier email, I promised that I would be providing some notes > related to Annex I: Packet-based Multimedia Telephony over Error Prone > Channel. > > Every Annex in H.323 has some direct relationship to the H.323 application > layer. Even the informational Appendix II - "Transport Level Resource > Reservation Procedures" - shows how the RSVP messages are being used in the > context of H.323 signaling messages. > > The way Annex I has been structured shows that it will provide information > related to bit rate, bit error rate, delay, jitter, and IP issues related to > radio networks (e.g., mobile IP [home/care-of IP, home/foreign IP network]). > > I understand that additional error correction and concealment techniques > that may help specifically H.323 are the main purpose of this annex. My > guess is that these proposed concealment techniques will be used somewhere > below the H.323 layer. If it is so, is not the case that H.323 does not need > to be aware of these lower layer techniques? > > Now the question is: Can this work of Annex I be directly related to the > H.323 application layer signaling messages? > > If the answer is yes, the next question is: Is this present structure of > Annex I good enough to satisfy our objectives? > > If the answer is no, will it be very helpful in H.323 even as informational > annex? > > However, I see that there is an additional scope related to this work of > Annex I to the H.323 layer signaling messages. IP related issues can be the > major topic that will really be very useful to relate the network layer > signaling schemes in mobile environment (e.g., mobile IP) to those of the > H.323 mobility. > > In this context, I see that there are some works that have been performed > related to the IP networking in mobile environment. It appears that mobile > IP has some problems: 1. If the mobile host moves very frequently and 2. > Inefficiency for keeping too many reserved IP addresses in the pool by the > foreign agent for allocation to mobile hosts. > > To work around those problems, there has been enhancement of mobile IP > (e.g., cellular IP) complementing the mobile IP solution. > > The important point is that they have been using the concept of cells, cell > IDs, and network IDs packet-switched based IP mobile networking environment. > A cell can be pico-, micro-, and macro-cell depending on the radio range > which is a function of power. Cells are usually inter-connected by the LAN > in the case of IP networking. > > (By the way, none has used the concept of so-called location area [LA] > concept in the IP networking either in the mobile IP or in the cellular IP. > I am curious to know why these prototype products and network architectures > do not contain the concept of LA? Can anyone provide more insights about > this? Personally, I would love to relate the LAs with cells. Indirectly, it > may also help to inter-work with that of the circuit-switched based > cellular-PSTN network.) > > The important point is that we can start with the existing standard of > IETF's mobile IP/cellular IP. We can see that switching a cell during > communications does not always mean changes in IP addresses. That is, this > handover (at layer 2) may be transparent to the IP network layer (layer 3). > No resources in the IP layer will be affected. If the switching in cells > causes the change in the IP address during communications, the handoff will > cause the resource allocation and de-allocation in the IP layer during and > after handoffs. > > Extending the same analogy, we can assume that switching of the cell may or > may not cause any change in the H.323 application layer. If it affects the > H.323 layer, the resources in the H.323 layer have to be allocated and > de-allocated in the H.323 layer during and after the handoff. > > The other important concept is that the cell IDs can also be related to > H.323 zone IDs and so on. > > It appears that the mobility solution can be related to the link layer > (layer 2) to the network layer (IP layer) mobility and the H.323 application > layer and vice versa. As a test case, people may also try to see how the > application layer H.323 mobility solution (e.g., APC-1651, APC-1646) can be > implemented to the network/link layer mobile/cellular IP solution > > In this way, I see a wonderful ray of light how the work of Annex I can be > related to that of Annex H. > > Last of all, I would request the editor to expand the scope Annex I. If > needed, I may also propose to include this item in the upcoming/future > conference call. > > In the same token, I may also provide some comments related to H.246 Annex E > in the future. > > I would request all SG16 members to look into this proposal and help us with > their comments. > > Best regards, > Radhika R. Roy > H.323 Ad Hoc Mobility Group > AT&T > +1 732 420 1580 > rrroy(a)att.com -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

3 2

Re: H.323 Annex I
by Gösta Linder (LME) 24 Nov '99

24 Nov '99

I agree with Ed´s conclution/Gösta -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Wednesday, November 24, 1999 2:49 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 Annex I Hi, Ed and All: Ed has provided a very valuable comment. In fact, it has been one of the main purposes of my email. The important part of his comment is that all works have to be related to H.323 mobility solution. Any work that does not related to H.323 mobility should not be undertaken. In this respect, Annex H is becoming the fundamental basis of all works because it provides the solution for the H.323 mobility. In fact, the dust will be clear as soon as we finish Annex H. Once the fundamental H.323 mobility work is finalized, other annexes can use this work for implementation to the lower layers (i.e., layers 3 and 2) and in specific interworking environments. I personally agree with Ed. I like to see the comments of other members. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Tuesday, November 23, 1999 9:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > Importance: High > > Dear All, > > I concur, with most of the attached email. > > And I have just a couple of comments. Until we resolve the pure case > of H.323 mobility and Interworking with PLMN in the application > layer. H.246 Annex I and Annex E will be delayed, I believe that > Annex I and Annex E are depended on H.323 Annex-H. Because, > the required parameters and network functions for the H.323 pure > mobility and Interworking case needs to be defined in H.323 > Annex-H. And expanded in H.246 Annex-I and Annex-E. > > If we do not get the H.323 mobility and interworking > parameters and functions defined, H.246 annex-i and annex-e > will be working in the dark. > > Because of the H.323 framework that we have to use > (already defined e.g., GK, GW, Terminals etc.) > and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS) > we need to work top-down (not) buttom-up. > Lets focus on H.323 Annex-H to make sure that it has the > network elements that can be re-used in H.246 Annex-I > and Annex-E. > > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Everyone: > > > > We have now three annexes related to mobility: > > * H.323 Annex H: User, Service, and Terminal Mobility in H.323 > > * H.323 Annex I: Packet-based Multimedia Telephony over Error > Prone > > Channel > > * H.246 Annex E: Interworking between Existing H.323 Systems and > > Existing Mobile Networks > > > > Per my earlier email, I promised that I would be providing some notes > > related to Annex I: Packet-based Multimedia Telephony over Error Prone > > Channel. > > > > Every Annex in H.323 has some direct relationship to the H.323 > application > > layer. Even the informational Appendix II - "Transport Level Resource > > Reservation Procedures" - shows how the RSVP messages are being used in > the > > context of H.323 signaling messages. > > > > The way Annex I has been structured shows that it will provide > information > > related to bit rate, bit error rate, delay, jitter, and IP issues > related to > > radio networks (e.g., mobile IP [home/care-of IP, home/foreign IP > network]). > > > > I understand that additional error correction and concealment techniques > > that may help specifically H.323 are the main purpose of this annex. My > > guess is that these proposed concealment techniques will be used > somewhere > > below the H.323 layer. If it is so, is not the case that H.323 does not > need > > to be aware of these lower layer techniques? > > > > Now the question is: Can this work of Annex I be directly related to the > > H.323 application layer signaling messages? > > > > If the answer is yes, the next question is: Is this present structure of > > Annex I good enough to satisfy our objectives? > > > > If the answer is no, will it be very helpful in H.323 even as > informational > > annex? > > > > However, I see that there is an additional scope related to this work of > > Annex I to the H.323 layer signaling messages. IP related issues can be > the > > major topic that will really be very useful to relate the network layer > > signaling schemes in mobile environment (e.g., mobile IP) to those of > the > > H.323 mobility. > > > > In this context, I see that there are some works that have been > performed > > related to the IP networking in mobile environment. It appears that > mobile > > IP has some problems: 1. If the mobile host moves very frequently and 2. > > Inefficiency for keeping too many reserved IP addresses in the pool by > the > > foreign agent for allocation to mobile hosts. > > > > To work around those problems, there has been enhancement of mobile IP > > (e.g., cellular IP) complementing the mobile IP solution. > > > > The important point is that they have been using the concept of cells, > cell > > IDs, and network IDs packet-switched based IP mobile networking > environment. > > A cell can be pico-, micro-, and macro-cell depending on the radio range > > which is a function of power. Cells are usually inter-connected by the > LAN > > in the case of IP networking. > > > > (By the way, none has used the concept of so-called location area [LA] > > concept in the IP networking either in the mobile IP or in the cellular > IP. > > I am curious to know why these prototype products and network > architectures > > do not contain the concept of LA? Can anyone provide more insights about > > this? Personally, I would love to relate the LAs with cells. Indirectly, > it > > may also help to inter-work with that of the circuit-switched based > > cellular-PSTN network.) > > > > The important point is that we can start with the existing standard of > > IETF's mobile IP/cellular IP. We can see that switching a cell during > > communications does not always mean changes in IP addresses. That is, > this > > handover (at layer 2) may be transparent to the IP network layer (layer > 3). > > No resources in the IP layer will be affected. If the switching in cells > > causes the change in the IP address during communications, the handoff > will > > cause the resource allocation and de-allocation in the IP layer during > and > > after handoffs. > > > > Extending the same analogy, we can assume that switching of the cell may > or > > may not cause any change in the H.323 application layer. If it affects > the > > H.323 layer, the resources in the H.323 layer have to be allocated and > > de-allocated in the H.323 layer during and after the handoff. > > > > The other important concept is that the cell IDs can also be related to > > H.323 zone IDs and so on. > > > > It appears that the mobility solution can be related to the link layer > > (layer 2) to the network layer (IP layer) mobility and the H.323 > application > > layer and vice versa. As a test case, people may also try to see how the > > application layer H.323 mobility solution (e.g., APC-1651, APC-1646) can > be > > implemented to the network/link layer mobile/cellular IP solution > > > > In this way, I see a wonderful ray of light how the work of Annex I can > be > > related to that of Annex H. > > > > Last of all, I would request the editor to expand the scope Annex I. If > > needed, I may also propose to include this item in the upcoming/future > > conference call. > > > > In the same token, I may also provide some comments related to H.246 > Annex E > > in the future. > > > > I would request all SG16 members to look into this proposal and help us > with > > their comments. > > > > Best regards, > > Radhika R. Roy > > H.323 Ad Hoc Mobility Group > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 Annex I
by Roy, Radhika R, ALARC 24 Nov '99

24 Nov '99

Hi, Ed and All: Ed has provided a very valuable comment. In fact, it has been one of the main purposes of my email. The important part of his comment is that all works have to be related to H.323 mobility solution. Any work that does not related to H.323 mobility should not be undertaken. In this respect, Annex H is becoming the fundamental basis of all works because it provides the solution for the H.323 mobility. In fact, the dust will be clear as soon as we finish Annex H. Once the fundamental H.323 mobility work is finalized, other annexes can use this work for implementation to the lower layers (i.e., layers 3 and 2) and in specific interworking environments. I personally agree with Ed. I like to see the comments of other members. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Tuesday, November 23, 1999 9:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex I > Importance: High > > Dear All, > > I concur, with most of the attached email. > > And I have just a couple of comments. Until we resolve the pure case > of H.323 mobility and Interworking with PLMN in the application > layer. H.246 Annex I and Annex E will be delayed, I believe that > Annex I and Annex E are depended on H.323 Annex-H. Because, > the required parameters and network functions for the H.323 pure > mobility and Interworking case needs to be defined in H.323 > Annex-H. And expanded in H.246 Annex-I and Annex-E. > > If we do not get the H.323 mobility and interworking > parameters and functions defined, H.246 annex-i and annex-e > will be working in the dark. > > Because of the H.323 framework that we have to use > (already defined e.g., GK, GW, Terminals etc.) > and the already defined mobile networks (e.g., GSM, ANSI-41, GPRS) > we need to work top-down (not) buttom-up. > Lets focus on H.323 Annex-H to make sure that it has the > network elements that can be re-used in H.246 Annex-I > and Annex-E. > > Ed > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Everyone: > > > > We have now three annexes related to mobility: > > * H.323 Annex H: User, Service, and Terminal Mobility in H.323 > > * H.323 Annex I: Packet-based Multimedia Telephony over Error > Prone > > Channel > > * H.246 Annex E: Interworking between Existing H.323 Systems and > > Existing Mobile Networks > > > > Per my earlier email, I promised that I would be providing some notes > > related to Annex I: Packet-based Multimedia Telephony over Error Prone > > Channel. > > > > Every Annex in H.323 has some direct relationship to the H.323 > application > > layer. Even the informational Appendix II - "Transport Level Resource > > Reservation Procedures" - shows how the RSVP messages are being used in > the > > context of H.323 signaling messages. > > > > The way Annex I has been structured shows that it will provide > information > > related to bit rate, bit error rate, delay, jitter, and IP issues > related to > > radio networks (e.g., mobile IP [home/care-of IP, home/foreign IP > network]). > > > > I understand that additional error correction and concealment techniques > > that may help specifically H.323 are the main purpose of this annex. My > > guess is that these proposed concealment techniques will be used > somewhere > > below the H.323 layer. If it is so, is not the case that H.323 does not > need > > to be aware of these lower layer techniques? > > > > Now the question is: Can this work of Annex I be directly related to the > > H.323 application layer signaling messages? > > > > If the answer is yes, the next question is: Is this present structure of > > Annex I good enough to satisfy our objectives? > > > > If the answer is no, will it be very helpful in H.323 even as > informational > > annex? > > > > However, I see that there is an additional scope related to this work of > > Annex I to the H.323 layer signaling messages. IP related issues can be > the > > major topic that will really be very useful to relate the network layer > > signaling schemes in mobile environment (e.g., mobile IP) to those of > the > > H.323 mobility. > > > > In this context, I see that there are some works that have been > performed > > related to the IP networking in mobile environment. It appears that > mobile > > IP has some problems: 1. If the mobile host moves very frequently and 2. > > Inefficiency for keeping too many reserved IP addresses in the pool by > the > > foreign agent for allocation to mobile hosts. > > > > To work around those problems, there has been enhancement of mobile IP > > (e.g., cellular IP) complementing the mobile IP solution. > > > > The important point is that they have been using the concept of cells, > cell > > IDs, and network IDs packet-switched based IP mobile networking > environment. > > A cell can be pico-, micro-, and macro-cell depending on the radio range > > which is a function of power. Cells are usually inter-connected by the > LAN > > in the case of IP networking. > > > > (By the way, none has used the concept of so-called location area [LA] > > concept in the IP networking either in the mobile IP or in the cellular > IP. > > I am curious to know why these prototype products and network > architectures > > do not contain the concept of LA? Can anyone provide more insights about > > this? Personally, I would love to relate the LAs with cells. Indirectly, > it > > may also help to inter-work with that of the circuit-switched based > > cellular-PSTN network.) > > > > The important point is that we can start with the existing standard of > > IETF's mobile IP/cellular IP. We can see that switching a cell during > > communications does not always mean changes in IP addresses. That is, > this > > handover (at layer 2) may be transparent to the IP network layer (layer > 3). > > No resources in the IP layer will be affected. If the switching in cells > > causes the change in the IP address during communications, the handoff > will > > cause the resource allocation and de-allocation in the IP layer during > and > > after handoffs. > > > > Extending the same analogy, we can assume that switching of the cell may > or > > may not cause any change in the H.323 application layer. If it affects > the > > H.323 layer, the resources in the H.323 layer have to be allocated and > > de-allocated in the H.323 layer during and after the handoff. > > > > The other important concept is that the cell IDs can also be related to > > H.323 zone IDs and so on. > > > > It appears that the mobility solution can be related to the link layer > > (layer 2) to the network layer (IP layer) mobility and the H.323 > application > > layer and vice versa. As a test case, people may also try to see how the > > application layer H.323 mobility solution (e.g., APC-1651, APC-1646) can > be > > implemented to the network/link layer mobile/cellular IP solution > > > > In this way, I see a wonderful ray of light how the work of Annex I can > be > > related to that of Annex H. > > > > Last of all, I would request the editor to expand the scope Annex I. If > > needed, I may also propose to include this item in the upcoming/future > > conference call. > > > > In the same token, I may also provide some comments related to H.246 > Annex E > > in the future. > > > > I would request all SG16 members to look into this proposal and help us > with > > their comments. > > > > Best regards, > > Radhika R. Roy > > H.323 Ad Hoc Mobility Group > > AT&T > > +1 732 420 1580 > > rrroy(a)att.com > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 Annex I
by Roy, Radhika R, ALARC 23 Nov '99

23 Nov '99

Hi, Everyone: We have now three annexes related to mobility: * H.323 Annex H: User, Service, and Terminal Mobility in H.323 * H.323 Annex I: Packet-based Multimedia Telephony over Error Prone Channel * H.246 Annex E: Interworking between Existing H.323 Systems and Existing Mobile Networks Per my earlier email, I promised that I would be providing some notes related to Annex I: Packet-based Multimedia Telephony over Error Prone Channel. Every Annex in H.323 has some direct relationship to the H.323 application layer. Even the informational Appendix II - "Transport Level Resource Reservation Procedures" - shows how the RSVP messages are being used in the context of H.323 signaling messages. The way Annex I has been structured shows that it will provide information related to bit rate, bit error rate, delay, jitter, and IP issues related to radio networks (e.g., mobile IP [home/care-of IP, home/foreign IP network]). I understand that additional error correction and concealment techniques that may help specifically H.323 are the main purpose of this annex. My guess is that these proposed concealment techniques will be used somewhere below the H.323 layer. If it is so, is not the case that H.323 does not need to be aware of these lower layer techniques? Now the question is: Can this work of Annex I be directly related to the H.323 application layer signaling messages? If the answer is yes, the next question is: Is this present structure of Annex I good enough to satisfy our objectives? If the answer is no, will it be very helpful in H.323 even as informational annex? However, I see that there is an additional scope related to this work of Annex I to the H.323 layer signaling messages. IP related issues can be the major topic that will really be very useful to relate the network layer signaling schemes in mobile environment (e.g., mobile IP) to those of the H.323 mobility. In this context, I see that there are some works that have been performed related to the IP networking in mobile environment. It appears that mobile IP has some problems: 1. If the mobile host moves very frequently and 2. Inefficiency for keeping too many reserved IP addresses in the pool by the foreign agent for allocation to mobile hosts. To work around those problems, there has been enhancement of mobile IP (e.g., cellular IP) complementing the mobile IP solution. The important point is that they have been using the concept of cells, cell IDs, and network IDs packet-switched based IP mobile networking environment. A cell can be pico-, micro-, and macro-cell depending on the radio range which is a function of power. Cells are usually inter-connected by the LAN in the case of IP networking. (By the way, none has used the concept of so-called location area [LA] concept in the IP networking either in the mobile IP or in the cellular IP. I am curious to know why these prototype products and network architectures do not contain the concept of LA? Can anyone provide more insights about this? Personally, I would love to relate the LAs with cells. Indirectly, it may also help to inter-work with that of the circuit-switched based cellular-PSTN network.) The important point is that we can start with the existing standard of IETF's mobile IP/cellular IP. We can see that switching a cell during communications does not always mean changes in IP addresses. That is, this handover (at layer 2) may be transparent to the IP network layer (layer 3). No resources in the IP layer will be affected. If the switching in cells causes the change in the IP address during communications, the handoff will cause the resource allocation and de-allocation in the IP layer during and after handoffs. Extending the same analogy, we can assume that switching of the cell may or may not cause any change in the H.323 application layer. If it affects the H.323 layer, the resources in the H.323 layer have to be allocated and de-allocated in the H.323 layer during and after the handoff. The other important concept is that the cell IDs can also be related to H.323 zone IDs and so on. It appears that the mobility solution can be related to the link layer (layer 2) to the network layer (IP layer) mobility and the H.323 application layer and vice versa. As a test case, people may also try to see how the application layer H.323 mobility solution (e.g., APC-1651, APC-1646) can be implemented to the network/link layer mobile/cellular IP solution In this way, I see a wonderful ray of light how the work of Annex I can be related to that of Annex H. Last of all, I would request the editor to expand the scope Annex I. If needed, I may also propose to include this item in the upcoming/future conference call. In the same token, I may also provide some comments related to H.246 Annex E in the future. I would request all SG16 members to look into this proposal and help us with their comments. Best regards, Radhika R. Roy H.323 Ad Hoc Mobility Group AT&T +1 732 420 1580 rrroy(a)att.com

1 0

Problem in Connect Message in H.2250 V3
by Aseem Agarwal 23 Nov '99

23 Nov '99

Hi All There is a problem in the additions made to Q.931 part of Connect message in H.2250V3. Two new IEs have been added AFTER User-to-User IE. The IE codes for the new IEs added are: Connected Number : 0x4c Connected Subaddress: 0x4d The IE code for User-to-User is 0x7e According to Q.931 coding Rules [section: 4.5.1], the IEs in a message should be in ascending order of their respective code values. These two IEs should be added after Date/Time IE. Comments ? aseem(a)trillium.com

3 6