- sg16-avd - lists.packetizer.com

H.MMS.2: Global Mobility Management Interoperability between H.32 3 and mobile networks.
by BOUGANT Fran�ois FTRD/DAC/ISS 17 Apr '01

17 Apr '01

Dear experts, The purpose of this mail is to initiate also work on H.MMS.2 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.2 introduces new functionalities (interfaces, protocol and user data) for user, terminal, service, and service provider global mobility management interoperability between H.323 systems and mobile systems. The concept of global mobility is defined here as the ability for a H.323 mobile user to access and manage services in a foreign mobile network with any terminal and a foreign user to access and manage services in a H.323 network with any H.323 terminal. As editor of H.MMS.2 document, I solicit you to make discussions in this area and bring contributions for the upcoming SG16 meeting. Please find enclosed the H.MMS.2 scope and terms of reference document presented in SG16 Launceston meeting. Best regards. Francois Bougant France Télécom R&D 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 FRANCE Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42

1 0

None
by Venkata Subba Rao Manne 17 Apr '01

17 Apr '01

Hi, where can I get the timer values of h.245( T103, T102 etc...). I couldn't get these values from either h.323 spec. or h.245 spec. any kind of help will be appreciated. thanks. mvsr

1 0

H.MMS.3: Presence and IM for H.323 Mobile systems.
by Paul, Manoj 16 Apr '01

16 Apr '01

Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). begin 600 TD-59a.zip M4$L#!!0````(`*.^9RJ0D?@>_R8```#"```*````5$0M-3EA+F1O8^Q<:Y`< MU74^O>^5U))66A18\VA`*)BL%B20`!6FA%[HO4*[PMC!0KTS/3NM[9D>^K&K MP?PA5CE`4HE#JE+825R`94CBE(L\_"./`D$28I(89!L<$[L2P)2<V`F%2>R` M`6V^<^[MGNZ9621(*E6V]^(SW;?[WG//^YQ[>ZT3SPZ\^.`?#;U$3>UZZJ13 ML_W4DWEF`&Y-.DN)#NIGIV9G9_G1+P)FY]M/5/OWSS]!5UO]741O+'L\U2P: MGIRZF&@Q31R>.'Q@Q8$5U-+ZNU;015<177VG@D]>0#33.BQML[-+3GN?-$]^ M_[J/TBO#`MP_@^LB7/])O\M>!S,87M7/;UXZ]Y7''\9U96;\*[N(UL*L/Z/' M9:\LA$=U/[G^^D#[:P%X.G!U=JG^F5R9CA5[B"Q,7#^*-=&_!\_/HM:6\)VL MU]Q^94"4."=]]^AU/Z&%UBS/A+^D<?];N'YVEY)#,J_YROB_W09/<[^@UT_: M)[+*>P\M*V]NC.=$=P/?V!#17LCS+VXD^CVCE<_WVT;U>@D_O[94V>4#.S<] M<^R1XP;;4[FW86]3RXC@)%38071%$QXF]4]WJ>>O:+R_B7%_"7I/C*K^=S'_ M=S+]T2;])?;[:A-_<UT[Z`7\[A@_8*VVQAW/*?B52EQU"W;D^E5K++*K13LH MNG?HOE.(_,!*VA:_$%><:F2-;UF][EK;'!L_L.4CUHW[1P_LL]:L-V\:V3)L M;1NV;ARVUJY>=_F:]=9^NU;S@\B)`VN/XT1N==(T=]MQM>"$D5\=MM99OV5= M:^VQ@T+96GO%%6M,<VSTP/[-6R_KV-"_M>AB;=,<WS&^>^N&_NTC>_:,C5QI M66,%O^98H!/T!Y70\DO6?J?D!`ZPFOL.[-\W.H;A^P*_YH>V9][6TDS3O&$B MC`*[$&TPQ\MN:!43O@I^-;+=:FC95DT0.,5W7<\J03J:LI'DQ@K+MN=91:?D M5AUK7^"$,I0Q[*B&D'`$882A/0EQ6`6[9D^XGANY3BC8*CZZ#G!=N1:8ZF'D M\)K33F#5[,*4$UD3-E-5=:(9?RH<,7/MAB@"&]#<!DL8P_^J?H2E+=9X+9[P M$DU7[")(FK9=SY[`<I%O165'CQBV)F*9Y%8C)ZC:GLQ.E<]/JT70X%>]NM`< MAXXU41<,>YS*!&B%(46.R(H?\G1F'V/<*$RL2@T-Y0U&N8$%4=7PSIUV+,BI M5))7!=\#C7Y@8PXXJNJQC#-P/"Q3M&;\8&K$VA%IR3/+$TXKB\."+V;Q3=2Y M4[=\((-D088/K8,H%I_H8L:-RC[$(&()7+R:"5P6+QM)R')H,#=B+A(K@36! M<K$7O$S,`4J`>.UB$>R%,D64%TQ9;/=N!([C0%00QN(NI[.92W?L^2`+HIVI MB!AF7$C!+3(O):46YP@H#UUF$NLHRM98EZJI>WRQP/H'V>@C'P+G015[RFEO MC7GR]B(a);]IS&TK87-C,,F;.EL,RKSHSE^9.P1$\PE!`/V";13:4/[M2:FH!$ M8ADA`2_,KN38+#UVA'&G4*X*UAUA&#NA^6&H4-E+JU*&^3&D;K/DTXFN3$RY M?V_LFV-`H9RYGKUG`["M`JQ'UICT\<.R:,:C&1NQQL7D?`3)D-7-KRNI\CW? M9L]37#G!-'N0YU;<2/.9+CNB0H",+\"9X1&WQS`D]P[H@L621+,PG@A!74WB M`B\&_W%+2:!(UFNF=DRM/0*[+)3MJAL"F:@9PL-2VOI<]8#)<K0KS<%7$R%A M"R5XDBA=\9U:BY)8:N)6)0XE`&C%,.J*RCY96V/\<'QHHF(S7X%S>^P&#H<X M+*7M-I9HQ@BREN"H,-*(7<@@%<D;;K40.`C0,,<;"LRHM1DI)?"]IBX(2J6F M@A;`GTF64<@AN((>+KK-ZLFM"N'ZOJ',F;(OVM:#)Y2^9LJ07=&.[,020L>I MZC=.51P7IC+I5)T`=""H.Q[+&I/>C6P_]HJL:)DB2&MV(`&Y%/@5H3E&H@B\ M.HN^EAA0$F2&+9A!0<RB+GX(Y11MEK\@M*T9N\XR`*M>K&;ZR$YU9-:"*[%L MQ!J+43DT/U:1'\DFM5EMK`GW6JJ><H0*!Z6B6Y*<'O&JC%CQPN*%5)ND(.RU M\,,WTQ`'\KCG''&U\XN5^\78LP-Q2B7J,)(076&'Y^#./A+%Q;HUC6%^#-W7 M:RI_VFII37*HM*+YT`L6D_2=,U(V"1>&KE*9<CX?GL<>T5#CB+E7A]9QU#L( MR_7T0:0?))H6CPJ<4LS:X22(I0.G*"Q5;+&`JL/$VH'6&R@NQI"0U!$5I^C" M.-)0CN)3^9KG3@DK1]Q,Z$U5IR*:I^Q8$DM)TG1Q-3O)?>R"?K5>4;)ENX=! M%."!X7`^\:FHH+R,?311[>F"SK1K*Z0-)@*).=M`QHX]P]G4F@2>I*0*G9;\ MC5"!(%.(($+,!_*19L0FRJ.8;<54IH+1_F15HK;H/M2O55J!6<-HW"A)7LJ@ MI]CAWEON'D6M:DOY)5+)+%+1A&-:4&]D"3N&?*N1%I2*P7-@;XZ>.LFKP)>1 M5P:ERA;@W4$UF.0)Y\RR#=0A!15+2VI4T3K>P:5EX8+8,XQ`!>\4N91O">>9 M4*=-AXL:L1\.&`7/=93C<O6KT-BJO-+KPRY7%_P@B$5FP]*O>79]`G6\RCZ! M.VT7ZJK<ULE111)9D,M8G904+RPMM6R8+!HFR^K7D5MA$TKUL$V2A+E9>ZNN M_;693D*T52:X;*/B!@8/J8M%QA&R4L'(-,:I9(-LX<(3>*%TA;8J;L0>CE22 M!-@)BCI@VW/A3U)AZ&?-`OO3VV,'>LR5M(J"B%6%I!<Z#62YW,@.)'O0EL7U MF@WE3J3A(K%'T3;FZZ6X:"EB6ZH*B,PRPRI$H&I(B4CVE&(1I3B`)94AI$!D M6T."R,X?,>=REH8DE6P:LAQF5T=L0NV'W,)9#-E[V&JK1]XS)OQR^&R*26$J MFD3/G)T2_TJE/N'K/,)QS0G2XB?=$,)=W1K;9S,^$2_C"U5B*'AQ,?%PE._5 M=+/`Q&4</^#AD+]73$I'DDZ0]3G`AZX%">)#YL9P\3F2I>9C$('*O-,(HA2 M?%N#4L,9.8;*?K)65)M0A"YH`6$V(a)-AKB!!89C*SDRRX`4QB.C$DE=>#V'-D MXYD/IY=G@FTV6>]K%*PZ/61V%ID*ELF4/*9$2%%[X;F8BPM&E$J!7;-+7IU MSF\%IQ8I]M)2C2D-V"6!BCF2+76.IR1!YDXX5$Z.`D0LV<,ATS0I,`U.85Q" M$F9CPBI"3$,Q;"6P[!(73^PQ*$:XO+.37>21A%_.9&5>J)(8NFFJHRQ5$:[V MF%YL#55D#&4#GTJG43NDI@O"5''GY3;LC62@[TY758@-5_UD)Z.B-XC;[W!@ M!]E8(XQ4V9SD!+%GI'LA,I.=HG?;J]<:[J"BBR[F;!<%NC]C!T4.D*M/O^HP MZNN:Y]>=H@0P!!?$-HY!I0`V'\3J$(,YY7V&%(5VK>;8,*4J;]%M.500D291 M(S=3CF58L6X5II*69_GS26`H@D*8:-Q^0"CG3B)(STWVXKG=H8HQL$LQM"04 M9?<UOLZV2;S1Q;;R%3[V*EE2$K*MHQB&7#Q7RC!^46TQ:)_/M6QUOE2R2K;K M@=TS*&3$X4H<^QLK,'MQ>JPW5?5GD#H0\K"G+O(IB#+NQK8G:X7F#1G_5A&> MM9[;5=923&IYEU-!6%9UN8[)R'+U:J$<^%7>IS3MT"<XT$E$2+:3.C2H:.U/ M'$:!F:0;/2[9E.5CE&@R.6-3\X8M?8*DD/$628QV6F><1O!JJ2PY-#IALU]R M0+&2Y![5[PO;1L9A62$-(a))D)K(C1.%)FB&UK`60TE)&O+/()INCPL9_"F26! M.<QHJ8R*8I+SN)]?I9'E=OO^5%P3O]N;586YHY2IDO06V,654>:E(.=RV9,' MR&$.0:B,#^=HFT&T!H?S.2;4"XLTM"5CO=PA$T<&!)HLZU+<<#F+\*]J&]0^ M$JYS*2>O$-X.9G.0:8Z/[S;'Y)BA*20CY(1^*=(18YA-76]BL8-W@\1PIARG MI@GAKJ<<(/0+KDKZ',=SF/4N(K=88P.-[3.(Y=)APBGY4MC#AIPC-5?7YJY2 M6Y)&Y)A`"'+4B53.757,F+8]MPA6MSF15#SI3<Z=W?2,*3U<FG34M@,;'CGY M:*@L\;U4LK+CW>LWNWL@M:"J*5'CBEO.56L(4I!YH)IHF6EM'Y32,2UA27RY MXD\W22*I&]N%'H07%3\X5#8^@9C[,LPEU376S@QI6CBNR6%H)-\?YJJA6FQ? M#DG'R_F!"I5LZ0,_GBQGO\U(?!>]^%Q81RHU1G+P48GYBT>[74::%S-(<]H" M]^DG!//#*O#D2@:VBTRXY^S7+I]QT-3%-\\8SISA9L35B,`UE-Z*?E!=LW61 M(-CUN4H./WMPX#=]*-%R5=FPL<LP>6.+!,YYW1P/['1KEOMVT-A"V1[O^>MS M*%)%`JF<];+)^3J'IZI$!.;X\@2A6B`YY"LPP\@Q&`<95B0GJ1(]%U!J<5A^ MUR)<WCDP[+*N*9H$(8=7F>E*FJ'4J9G:J1C;GOX$@)&Q%X5ZOYA)WFGAJT]B M&Z)(JD<F5LZ-5<6F-(50J9V\\<U37%=_,WT_7YN:/WTEF-<@Z134ADF9A&QE MTYGL]PG5P]D@9ZN]=LV?P8XI9J-!+7?'M'!=$ETY,E-_R`U3%3I._INL1/C6 M+4$SZRV?O'*?$UKV.6!HQ.RP+MNL$OH&LW\/G.JPM<^.O?[^_G''V]#_"VNL M*]=<85UUS1IKW;JU5UO]6U?O0?6XP5IN;?_(OJW[=^_8N\NZJ()'D;^A4L/, MC8@`GN?&E1%4Q1=9QF#KT[-,TZ3Y]K/>NHA&`%<#-@)N!(P!;@9\''`_X#.` M!P$/`3X'^$/`'P/^!/!-P`N`E_COQ0`+NHG^$?!-P,N`E3U$UP%NZB5ZKH_H M><#-_403@.)"HA"P:#'1>8".GR,Z!_!IP&.`E\\F>A7PO7-Q!3Q_'M$_`^X\ MG^A>P)N`[@N(_AM@6$2?O)CHEP%W`^X!/`9X''`2\%W`OP)^#'@+\`Z]^0[] M\#_IU9/?/OGJF_3F<V_2L_3LT_B/GJ3'Z4L"^?^^2%^@A^FS#__VP]1UQ4[0 MM:2C[Z[.PRS$GC[C0)_1KSJXP_NE1*;J\SV>+5O7=]?HS@ZZ"7!KWUT'<:&N MS8QGD8W?RO;^KA!`"S$NZ?2E3Q?CZ:V-%[2\@1MO@!XOTS&+,&91%_6E=YUX MW(NWFW>>2SUJ%'7B2A\BK?-$WW<"/JUU_@6M:];O][5^9P'4K?3\]X!_`'P% M\`S@C:Q=_6#.SK]D.]_(=KZ:[3P[9^?OLIV_RG8>RW:^F.U\?L[.Y]Y'IZ49 M1/UGT8)5M'`;T?)C1VCP&-'20>I<:9A/=1GW=M.2HT0#@(.`0P![I<&RQP#< M]2XC\ZF^SJ'.1<O/7@6SX(D8`;R#U+V<&$7O$%%?>KO\V)=I(T8.I$\6'_WZ M.:N*/089^Y[BO_":[3$,^A@>]F8F?0>FRMU>=(U'+GF2EC$-[#?O,+SSKCS. MMY^JUM5%AM'!?OMLM_J+R:\"O(a);X.N`YP/.`;V3B.<?P6S)Q_&0FEA<6YN-Y MSI3^OSJO9SO/9#M/9SM_F^WD0L;<P[XTYYLS[%!_9Q(?!HZ6C4.`_IS7+T?$ M(,.B;B,91Q>OH)7BTI?(KW+OGY??O0TG'VW<9ES_IL8M+>"%EG3P,IV/=%W5 M\T3O\>/'Y4_WSTIR[^\N(7H8\.(`T6N`^Y83?6N0Z&W`GYU%]#>`MU:@OT+E MZ/LS>?JELQNY^BOG0/*`%P`_!#SQ`:(?9<7P7]G.^WGSOT:0LY)<9^YU_F\[ M_Y'MO#CGL#-I9FI52XZ>Z!@X>L4[!W$]A&O&CEC3AM7&`NELUL]W`/]V;J/. M>NZ\1JWU\?,;]=8;F9KK1YFZZ\N`IP'/62J7W`=X6^<4_O\0Y&3\VD]SY_MS MOCDY9^>5;"<WYSTUUG'7@*X;LKJW6FSD_E/*1NX_16>_I74TWWXFFV'1FD^5 MC0L>/7&Y]>B+'[KPT;[>BP`7?^J![I6`2QX]'8+Y]I/=>&.UY;2C3M-.//V] M^IM__LS`K_X2_0'M^OV%_'][0EU`J"&H0C6R*2:/-E)$`;FX\_`;X\T(%<C' M%4FP"<-5,M.6T1'&;#A#//-MOLVW^3;?YMM\FV_S;;[-M_DVW^;;?&O3!NE" M6D`&-M)+J#-]>@W1QA_,=N"ZB'IH+S;7@6S'^5]EX<W]V<0?KF_;;G1E/UU' M@(^2L='`F(]B9C]M)P>SBL!>I4FR:`WQP8!!/2L-.9%<0,N/O4:#QZZ3CYGG MDWRBMFC7=HN:/I7;>'PK\#+N6]OB7BNX.Q1N(X_;P'O@7J^^@&=0?RS!?B[= M3)U"^<UML5\IV#L5]HX\]@X:4I0/M5(]1#NI2ZC>V1;O58*W2^'MS./MI,6D M/]H#'].XF[H%U^ZVN-:)/KMIP:JN/**NP93[(<TU4[8-NF5LV]IB6R_8>H"M M.X^M6U.U0E&U`E;2*WBN:8OG:L'3"SP]>3P]_*],]<G,Z]O.O$9F]F%F;WYF M;P^M%RYV8];<\KA6YO=C?E]^?M\@,?F)LI2F5M!U=,/&UV<?Q'41K:`MP%;2 M1TX1L.W#?0"8E-\:E?%L&SRCBK?9=HA.+6&:#@'+LISO6/@M8;2#)Q:N+L!# MC^@\]KZ5G>93BZEKJ/&)[OCR8QL->V4G,-D[!]G/^N!G?=?1JHT/D6%<)RLP M#3XP5>77`>;]0CFOXN!I05;H`\=+:>OV'E!^'NQ\F5'#;+/-[''\'A&>KB3^ MGM#9S7_#,,"6ER7M^)*CLS1PU)CEOW8XB/M#N&=:EXILL_1NHE.C!EUD;,** M?;25;H=,;>&?I<<ZXN^3"TE_"3W^Q).,,\_S>L&QUEB/YUVIIOD?JUJN)`?R M>H>.(a)X#\O-TR;Y/!%M)+.[!>":L6`07,MF@PG7UO-UBZMWO@Z/2/#^)Z"-<6 M;+<(M@ZZ1;#=`&Q5D=9VB3Z7TEF,3:*/06V4R?9WA(!U"7M0%C&BSJG1VXT) M@Z//8AJ#EAQ0Z&J[2;3$.N5XL4)1O:CCQ:7'+^QX;MDCEQ@=B>R7Y2@>)@O: M#HQAB>1Y/"8PF4_UD6`Q.*Z/T`%8UEW&B/:GNM`1R$%KE::(_X6CZR\S-EW6 M42L3S<)'3HT^1+]A;(%.^B&/,=C[&KJ-9L3J63\7,J>;+M/^1O`WHJGMKW15 MME-7%1#W&9#F&GCQ0P9+=2%\V:50/&ZO'.Y.:&I7(LJ*=)$WS';2%<GF];53 M^R+'WF[QBP*HNU@\[@,$P^YAVV[!]*)!K1JZ6W`]:=P-7$.T63@,!&-BR1;X M=^28.A#[]L7/-^'9I,B/$.W/Y;_XP:J+CS[0O02@C.(U6E5<U/C3G47RISL/ M=!\$V!B;1N]!X6Y<*/F:,2[^Q#[.<N)(,BT9=C6X:Q=-EAP=ZAPX>O+MY<?V MP6.'.@_AGJVF2[!N!-;;C9>-C2(KI<L1P3>(S,Q_/\!FTEDV3G1<TR6>Q[8V MNK,3.NT4#-<@ZQOTNL%Y8`'BY?^T=^W!=53G_=N[]Z4'UI5L25?"V`IM'4%` MD0%3F?`0-F`[P4:.1'$RQ)9M*6-G9"1L.=B._U`:)W$9F@`!0A)"E=8#I*'4 M39C63#NM4\C$">"XQ31VVC+.8SINDF%NTC*IG[>_WSEG]^Z]=U?WKC#!9/;3 M_+2[9_?[SF//X_O._<[9$36!?U=1GQ*3N8IS5A'GM;*88V^,/5H&)<86NMW# MUZ%:[I#**Z74(J1AUP9K-7_#EJ\AY.Q<_1.HH`P$O)H8FF2Q(X_<[8YA2X`_ M`CXA>C^N+XG>9^T;P-,`=\7B[[AG^2;(0`<*X$7@)>!EX"#P`^`0\"_`OP*O M`(>!5X%_`WX('`%60JU:!1Q&H;T*_!>][1(BZX#U*9$A8`M07XM:"7RU3N0) MX-@%(CG@P0:1?\^(G`:>:Q3Y#G"J"==`VTR11X$O`?\(_'B6R$^`UX&7FY%. MX"CP!O#M5I&?`O]-CTKCK7&X#6D"7@,^T8[R`.X%_@\X`23HO0'\!K!FBQP` MOD</@=EZM[\'@=-`'G@41373V=AL@IA>2+K",WQO#)DUK9"FLA"I@JNYBI"" M'#%I+I?\NQ%27H8M12%\@U99:724A13DW&!7Q]6)?[8;0G]D?\F%D+9$Z3/E M(5*EY'/U3'BNPS.H750GN?"^OME0^@:=D([0(5^6RKD('T+)Y>^].*>+FDK3 ML[RIM#3*GUDPZW<S1*HLYTKOBY*K:7%?[A5I+'ZF+(2[LKIU3%-<>]G3LXA. M`&TFC-ZF]#BDUQGO(1%J+U$Z"V3-,_0:XWZG/<!:@.,]Q_.9JV;EFR=087(] M*HIDCARQM)Z1("P#"($V,^=7&>'>LGPV+Q,3$_(;*BT-$LL]*#Q+Y]*&P08' M#+`<\]`@\5RG"J_)9:2<8E*K^!A+PCR_",<F$VXQ=F2Q7^IR<W#Z3Q;C>E'I M)GF+A1ZW:W!^@VVIN!MS<9,**BND7H">6]"PE>)+)>4SHIL@59T]HI65?P;3 M]X`7$-M!H!ZEF`6N`Y8`GS<NF@=13C\".C&@7V4&^3\!)H%GS"#?"+0B_HOF MZH']"QS0S<">0E934%PU$@:S0T#_)_&%[C!Y^4O@6\"W@9,H!!O%^??&]?A/ MH0!]!3B*]_T:T(=:-`BT(Q^79G4:==JN-.FY<@KHN!>;<AU'F=T+_#GPU\!3 M&'R>!UX&7@&ZD98%<;TL8@7P`O`*\%ZDZRK@%F`Y\#G@8>"[P(&$7N:R&'@. MV`]\!S(a)(+$3TUP.OX;7_%%B,?#T&_!+X%0";16J!M<`&X!Y@)_!AO-,UP&KD M?PWP`/`C5,DA='8G@?^@P@<<0RMZB4H>WN%WC9+V:?,>'S!*VL/`5X$G(a)%.F M[*CXOQU(E5SE\^P&$AX/G_EX5]?(G3`O::;3N-&*_Q;A%`H-`6UJC2O3BY,] M6_!T@?].-7FS!08KC;`Q7`\@Y'(8FJM@TFCC_^V,;_6;CN]&G(\ILWR]9RJE M`Q)YM19/+%?W-B-\"\!IISOE#F.6DW^K2JLVB4=A--'(ILFU!=P?5Q-!Y.HH MRLE:W!V*<A+EY+>4D[>J72[`WV^S'U@@"\^+^*YX"^-;Z\;8+#OS^?SC]^U_ MKGQ??TMVX]ZLU3+8+OF&XC]+GES49V>N[EQ7>B??D)%%@^FZGWSQ\=KR>R)[ M-SY<+W_QL3<XU<<Q)2%)C"MIH9ZU??ZJS+K$HQ_TDWFH<_)=3W]MUU?\9-9> M>MVE.^Z>5>?'-^^"9^8_GMUQO=^]_ZG;MW#U\B?.^.5]Z\JCU^^XMOYN/[Y; M/]1ZXZ&^H5_ZI>5SLX=O>OKWKC[B=V_GNFMNV9-N?]WOWO-+&VX+BJ_E(]\? M>F3)(S_TNW?DXK_==/R^7__83V9O;6XL*"W;Y^_<,J_]_H_ZR?QZX^OC07SI MEK^YY^=?O_<__?@L4W9EE.5RAG2*RQF:.7^?3B57XYK+&O14]M2<&RR7<X.5 M7*T6Q!1Q9@J<&YS3;&$)A>(\%$LZ2RD*G/'[@S@G$R[G9"+)V5W-:1G.V(-! MG&/IQEVWYA7G6!J<8^E!7,=0WTUJ`^/LK7/C[*T#9V^=CM.NF-K,#)<S,P.< MF1F:,UXQM<<R;FJ/9<!Y+*-3FZB8VKTSW3CWS@3GWIDZSF3%U$ZTN)P3+>"< M:-&<J8JI[6MS4]O7!LZ^-IW:M.&T5#]20HI3K^@MU#Y1*WMK,?YM5CWH>C4I MWR%.S6B)U]15E*1JAI94IWIC[P\,6I(J"67R^LEB_>PKJ9]]9VWI!,<ENBQB M0;R#=N.N,5T6@S9X!^U!7)/7-KS!+2IGN_'FR)NS&2_KRR4FQ4&<$W&7<R+. M=Q?7G`DWO4&<&;2H8Z:.LMPR:%''5'VI%"?;8E])6^SSUI?`.+N3;AEU)\'9 MG609%>J+7PG9NG9;;IQ[V>?LM1CG:*>.D,^EK;(WHUE[\5+WGU&L/2RB7KS4 M_6?`RCD("YI$%T9WS6O9B3(1,7=Y8'&]Z'9$=*E.*.9DP$ZD2D78IGI,GBZN M'I.G(2+E$=&%NE(04]QV[&S<U)3,Z>*:DJ&8FA(Q7>X+5***&H^=39BJ,W&J MN.I,G(*H.A]17<I]HB#.N_^)G4V:^I0[65R?<B<A[H(`<5W*A$CTC/LV]F4 MJ6B#)XLKVB!%-DPALDM2)6(+7_FQLVE3"P^=**Z%ATY`;&,%L5VHJ-K3)ZB: M^@]PHYVJ?IEV-3%5NYIRC/OC(,Z*8UQ@G!7'N$#.BF-<8&HKCG&!<58<XP(Y M*XYQ@:FM-,8%:SM5Z$FNWU@Q9[8P'F39RK-J/(B+4ST=;J>W*N8^@(:=]M2C M`VC8Z;-)\59N5T+*3$^M)!M9PKU:3]:R+8S:2EM'@4I-3Y2]J%6'M=]U9$: M2-F'6GG\=&V9E'BQI+IR27MK&W>MTI*>JN=[KQW$=;VOI$2)M`O*I#U5W[CK M@.[XMC5`VE/U@[B>$2(a)M62JQH4P[15OH.56HT9-H"SVG,E-*3)5);?31!4WW MIVH[V\D@IR\K2'5J9JMG$MZ17#=%-W7;^RU9":A1]>]R2L3]02+\.RO',T&) M&)6I1;#7,B+<7HLBXA`1UR*>K)`*_^XK5$;\^[%0&>&+,B+<#BUD1OQ[ME`9 M\>_B0F6$?9T1X?9UOAEY$R9>(&=DXE5*[?EFXBGJ+7!ZR3(([H1ZXFZ:E%[> M$P^J\H$B_.<P0E7Y(S6N"#5(':D)W78YGA@1:G3B>!*R[6YK<$6H(6E;0^B, M+&UR12QM@HBE3:$SDFUV162;J78TA\[(\597Q/%6B#C>&CHC^]I=$?O:J3:T M^V2$NI!C*Q61$N&9$U":EYX3<*JD2,%=WZ%D*9_JO#3?@K1U=1H-^V;56#J4 MC'R!M6!V9@HR'%Z)GO9YVEC;4DK:B/+7FXT19?I(L<K>H9VU)$AU!G-<BK3G M0%O?7WN&`!\%.M#:]U>@(21`APZT]_UU:`B:0HT.M/C]U6@(JZ!)!]K\_IHT M!%:A3`=;_;[*-(16J4\'VOW^^C0$5Z]2!U?:*2>HIJZRG@FJ7O8ZO<X$%9]G MO%-7V/-R<DJ-Z.=F<DJUPG,W.:44A7,[.:5$GOO)*=5SA)J<HNA@!3OX%Y]+ M*G#Z*TFL59HSO&X40BL)THU":"5!NE$(K21(-PJ1D2#=*$1&@G2C$!G9?9$K M8O=%$+'[HJ",!*K=T?1!040T?5`04=7T@=+]?'J:ZG4_GVG3<+J?S\QI>-W/ M9_)T>KJ?S_SI]'4_GRG4-Z?[^<RBOGG=SV<B]=SH?CYSJ>=$]XL,ELA@>6<: M+-.?J`V<3(PF:BNE]GR;J(VZKZC[>D=V7Y$-$MD@;X$-PD5R]!H6#]$SV7M- M+V;O-3UMO=?TN/9>TT/9>TT/XL+5S<ICVGN?7MG>:^6)[2%Z!!=?K_(T!E'> MX-[KG:77ZZZYQ7M-[VKO-;V8O=?T7/9>TUO9>TTO9.\U/:N]U_FWA)HE#!6> M;Y(&J8FW`1<"0>?ZR2<^]?V'*CU9G;PFU*Z:N`TD@*#S:M-6G30GOZTX;ZT8 M<W7IJZ9$JB_CZF+]C&=#!!);=;[7FK#4RD.BYZ$MPLEPIUK?;(XQIUUP&>@@ MUXGVLBI00$IN%^Z^PCUZ[L%_AJ:E0/HIO=8UYJQX]9Q395G20FTM%DO:B7@B M9L<_NT,Z$#SAR#$B9$`VJF4A7!*R`L=[A/L)<7-M+A`160`Y4!X35LQ*)6.N M'N-MU!/\UR_;A7NWC`KW#+MRGHJ]+AF/D0)COU%M[*WW&;MA@>))V36Q6"(6 M#^3A3BQ;%9_>5TFG6N1]2952*:&RE-YAEKH,N4M>1"[&6'YW>G=6<H=B3M_\ MQG7]'R5>__G*>?JGB,^C6IQMXTNFDA,7._.''N'Z%P^32'F7+;[+B2.JAM*I MR<2S\JQ\\I-7=/,5MJF]A;BJ_!=S*_%6IL+OO/57?&HEWY.W=?E1/M]DSKID M&=K,[:AWEXO>KV;$+'K;A+^MJ%&EB^CZU1(Z+K9:JY;+;90=)?>UR_^H6OQ- M\B[A\IZ?"SJ;I_SRY0"LM\<^_6>_/G';ALPW'DC+>][]K:,H>MECB=)\>?]1 MT64W"5"+.")Z[?W/1/<Y_)A-T@AC1U%OZ3T'9N-(L^4R(ZO'$F69#.!(;6+0 M$F5<C%BB6M8V2ZVHEUTX4O&_S]+-^"%+[R[PF*73\;,X]Q`4>2^P;.#VCLL[ M!H9'AHL_"]\_OO:NH;6;AS;N,-?#Z\='-TOW'),G`=\<DV[US4P9&';OX;KT MG/E:P8^VXK47\^EKINL*T<\RK<LW\INV_-ST':.;ASH6=G7+>"_EW?*\^@J+ M.J\_VG[9O?LM=?[(7[VXY\GB<]ND@4?V03RR'RIW"(DHHH@BBBBBB"*****( M(HHH(DU!]C]#8J^^_.IC71=FOO!%V/^7G7B&,^6)DC!NIM9M['7:I-RTCC8Z M9]TY!_"0:)OX,8`_K>T!N-L?=]JEK?^L:%O^'T3;QR^(WA'P)=&V_V'1LAM* M;/QVX*;AD9&.Q:.;QK:.#V_&R>:QT<W*JI<190MS-LXV<GC\Q5Q]G*RM$>=7 MBZ#CG(S.SS3F$NHS.JG.=,#`QO&187&,=M%Y=FSU#A/<(YJIUUSSG/E>T[?L MIC5+;UVVX@/];OYOQ''$"*><C\L25Y[WR/+G]!C+:CH?4YPK?C^W1Q111!%% M%%%$$44444011?1.),?6I+W(W^YI,]*NY._:_*V>O]/SMWG:Q;1':4OSMWC: M^+3;:=/S-WS:[MS&FZYKWAW]Z:-!^_-L/I^?+?SNDC:,:5MV"+\/16\;??_W M<?P#8![P;M'?>+@$H`?C>X#+A-\VHL^%MLOICT!O1WY[B]_GNPK@-_#XY3K: M_K2IZ2UX#?`^X%K@.N%7YT1N$&UKTY9>)'IS>,YOT!V+KEG\2M!28!GP?M'I MNQ7'Y<`*@%Z1?<!*X(/F_@".MXO^NM`=P"K@0\"'S?TSP$?,N8.WF^C;Q2^" M=2#G=ZFY`.?;2=51BR0L1Q;K4+)&SR7MU[>+G#<[?C!XD/X+:\2X7HFX6TI/ MEVHEYL9/JLPA<B'_&6>L^3*`V->)_@Y?>)HAVA<L3/QT]#ADW&J=3;-+MV2N MEMJ1?[97MMMJXR==?)4^)J1?Q;I)>2-M=[^0I[]96/A&7Q!U3J/\/\!_IOP3 M93D/EYX>Q,]^*TS\_?QGXK>4_R#GPVY#+?C85&R^U(3X6>/97X8I?R<F':OV M^.I3;3&<7U<+<E"I_)UVYQR]]WAQ/O1#$;T]9.'MV[6Z[I;VW1R_2_S5;AI= MOW73\%WC2B=8WL\P!*G&Q/,NYWY7C_SOPF_>+1&=Y_3_4$L!`A0`%`````@` MH[YG*I"1^![_)@```,(```H````````````@`+:!`````%1$+34Y82YD;V-0 52P4&``````$``0`X````)R<````` ` end ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Binary Encoding of H.245 Related Properties given in Table C/H.248
by Muhammad Mukarram Bin Tariq 16 Apr '01

16 Apr '01

Dear All, My question is regarding the encoding of the H.245 related properties listed in Table C/H.248. I presume that all these property values are encoded according to PER. Also that the entire MultimediaSystemControlPDU is encoded, instead of just the message structure. e.g to encode an OLC, we should encode the entire MultimediaSystemControlPDU that contains the OLC message, or just the OLC message structure. I am asking this question because in the presence of "Tags" it is quite possible to live without encoding the entire MultimediaSystemControlPDU. Regards, Muhammad Mukarram Bin Tariq __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Documents for the SG16 meeting in Porto Seguro
by OKUBO Sakae 15 Apr '01

15 Apr '01

Dear SG16 experts, The next Study Group 16 meeting will be held during 28 May - 8 June in Porto Seguro, Brazil (see <http://www.itu.int/itudoc/itu-t/com16/coll/01-04/001_ww9.doc>). Since this is an official SG16 meeting, all the documents are managed by ITU-TSB. There are three types of document: White Contributions from the members, Delayed Contributions from the members and Temporary Documents from Rapporteurs. To facilitate the advance review of experts, please upload your document to ftp://standard.pictel.com/avc-site/Incoming or e-mail it to me when you have submitted your document to ITU-TSB. These documents will not be AVD-numbered as in our autonomous Rapporteur meetings, but placed at http://standard.pictel.com/ftp/avc-site/0105_Por/ without changing the file name. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Question on presence
by Paul, Manoj 13 Apr '01

13 Apr '01

Dear Mr. Okubo, As you pointed out, the item (3) still needs to be worked on and the intention is what you mentioned during the end of your mail. In addition, the Presence signalling shall be carried out using the genericData field in RAS messages (using H.323 Generic Extensibility Framework), instead of adding new IEs to RAS messages. The ASN.1 synatx of CommunicationState may be further enhanced/modified to be more generic and reflect the necessary information that Presence is required to support (e.g user information in a standard presence format). The work on this is to be carried out further and presented as AVDs in subsequent SG16 meetings. best regards Manoj Paul. -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Thursday, April 12, 2001 8:10 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Question on presence Dear Mr. Manoj Paul, I am trying to understand the concept of H.323 presence. In AVD-2087, communication states to be exchanged are listed as: 1) status of the user, 2) its reachable address, 3) user's means of communication, including the preferred mode. The ASN.1 syntax CommunicationState in AVD-2087 includes newAliasAddress (corresponding to 2) above, I understand) and availableForCall, busy (both corresponding to 1) above). I wonder how 3) is handled. Is it going to be added in the course of work? Or as H.323 has the H.245 capability exchange procedure, H.323 presence needs only 1) and 2) above? Or still we would like to indicate e.g. being ready to communicate with fixed H.323 terminal at office, mobile phone like H.323 or H.323 on PDA on the road before the actual communication? Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

The reason I was thinking about this is that if it was NOT included in the RRQ/GRQ, and the gatekeeper would be force to use the source IP address for any other messages (from GK to GW), the same as if it had been explicitly indicated in the GRQ/RRQ, then it would be possible to use a gatekeeper on one side of a NAT while both endpoints are on the other side. I guess not. Thanks Terry. > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Friday, April 13, 2001 6:31 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: ras address in RRQ/GRQ > > > This is of course the opposite of H.248 where replies must go > to source > address. But remember that there are requests (as opposed to confirms > and rejects) that are sent from GK to GW and the GK must know what > address to use. If no rasaddress were registered and ARQs > (for example) > came from various port numbers, the GK would have no idea > where to send > a DRQ, URQ, IRQ, etc. > > rasaddress is not optional in GRQ and so cannot be omitted. It is > probably not intended to be optional in RRQ although since it > is defined > as SEQUENCE OF TransportAddress and SEQUENCES can be of zero > length, it > is in effect optional. A comment probably should be added to make it > required for the above reason. > > "Paul E. Jones" wrote: > > > Francois, There is no requirement that RAS messages sent to a > > Gatekeeper have to be sent from the same port that it will > receive RAS > > messages. If it is not included, I would expect that the > results will > > be unpredictable. Some devices will probably assume an address and > > others will probably just reject the request. Paul > > > > ----- Original Message ----- > > From: Francois Audet > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Sent: Thursday, April 12, 2001 8:17 PM > > Subject: ras address in RRQ/GRQ > > Guys,What is the purpose of the rasAddress in GRQ and > > RRQ?Shouldn't it just be the originating IP address? Is the > > gatekeeper supposed to send the GCF and RCF to IP address > > indicated in the GRQ/RRQ, or is it supposed to send it to > > the source IP address (at the IP layer)?What if the RAS > > address is not included in the RRQ/GRQ?----François AUDET, > > Nortel Networksmailto:audet@nortelnetworks.com, tel:+1 408 > > 495 3756 > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572(a)skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > >

1 0

ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

Guys, What is the purpose of the rasAddress in GRQ and RRQ? Shouldn't it just be the originating IP address? Is the gatekeeper supposed to send the GCF and RCF to IP address indicated in the GRQ/RRQ, or is it supposed to send it to the source IP address (at the IP layer)? What if the RAS address is not included in the RRQ/GRQ? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

3 2

Is the capability set also a delta for MultiplexCapability?
by Frank Derks 13 Apr '01

13 Apr '01

There is general consensus that received capability sets should be treated as deltas (unfortunately H.323 is not really explicit about this). This certainly applies to the capabilityTable and CapabilityDescriptors elements in the TerminalCapabilitySet message, but does this also apply to the multiplexCapability? If I first send a TCS with a nonStandard element and then a TCS with a h225Capability element should this be treated as a delta or a replacement? If I send two TCSs, both with a h225Capability element, should anything that is present in the second, but not in the first TCS be "added" and anything that was present in the first but not present in the second be removed? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Merchant Status Account #6DA0
by Victor Simmons 13 Apr '01

13 Apr '01

***** This is an HTML Message ! *****

1 0

All VIP'S
by Earnie Preston 13 Apr '01

13 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept.  If you wish to be removed from our list, please submit your request at the bottom of this email.   0); // returns false if empty } // --> International Executive Guild Registration Form (US and Canada Only) Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of  www.  Confirmation of its delivery is made by browsing your outgoing mail. Thank you for filling in this form, we will contact you with more information. List Removal Click Here

1 0

EndSessionCommand?
by Paul, Manoj 13 Apr '01

13 Apr '01

Hi, Does an endpoint using Tunnelling to exchange H.245 messages with peer, need to send EndSessionCommand message during call termination? There are two different texts relating to this: H.245 Specification(V7), Section B.13.4: "This command indicates the end of the h245 session. After tx EndSessionCommand, the terminal shallnot send any more of the messages defined in this Recommendation". H.323 Specification (V4), Section 8.5: Phase E-Call Termination "..It shall transmit H.245 endSessionCommand message in the H.245 Control Channel..." First statement seems to indicate that notwithstanding how H.245 messages are exchanged, an EndSessionCOmmand should be sent to stop any further exchange. Second statement seems to mean that EndSessionCommand is sent only when H.245 Control Channel exists (tunnelling not used). Could someone clarify? thanks Manoj Paul. Trillium Digital Systems. -----Original Message----- From: Nehru, Archana [mailto:archie@TRILLIUM.COM] Sent: Thursday, April 12, 2001 5:34 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.323 v1 problem hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.323 v1 problem
by Nehru, Archana 13 Apr '01

13 Apr '01

hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

All VIP'S
by Perry Thomas 12 Apr '01

12 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept. _____ If you wish to be removed from our list, please submit your request at the bottom of this email. _____ International Executive Guild Registration Form (US and Canada Only) _____ Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. _____ Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email _____ TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... _____ Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of www. Confirmation of its delivery is made by browsing your outgoing mail. _____ Thank you for filling in this form, we will contact you with more information. _____ List Removal Click <mailto:nvbobr@netscape.net?subject=remove> Here

1 0

Re: EndSessionCommand?
by Paul Long 12 Apr '01

12 Apr '01

Manoj, I'm sure that was an oversight when the tunneling stuff was added. There are plenty of examples of that sort of thing in H.323. Let's see, how shall we rationalize this... :-) Okay, how about this? When talking about tunneling, H.323 always uses the term, "separate H.245 connection" or "separate H.245 channel." The important qualifier here is "separate," so when H.323 simply talks about the H.245 Control Channel, for example, it is referring to the logical channel irrespective of the transport mechanism, i..e., separate or tunneled. Therefore an EP is required to transmit endSessionCommand regardless of whether the channel is separate or tunneled. How does that sound? Paul Long ipDialog, Inc. ---------- Original Message ---------------------------------- From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> Reply-To: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> Date: Thu, 12 Apr 2001 19:07:02 -0700 >Hi, > > Does an endpoint using Tunnelling to exchange H.245 messages with peer, >need >to send EndSessionCommand message during call termination? > There are two different texts relating to this: > >H.245 Specification(V7), Section B.13.4: > "This command indicates the end of the h245 session. After tx >EndSessionCommand, >the terminal shallnot send any more of the messages defined in this >Recommendation". > >H.323 Specification (V4), Section 8.5: Phase E-Call Termination >"..It shall transmit H.245 endSessionCommand message in the H.245 Control >Channel..." > >First statement seems to indicate that notwithstanding how H.245 messages >are >exchanged, an EndSessionCOmmand should be sent to stop any further exchange. >Second statement seems to mean that EndSessionCommand is sent only when >H.245 >Control Channel exists (tunnelling not used). > >Could someone clarify? >thanks >Manoj Paul. >Trillium Digital Systems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Question on presence
by OKUBO Sakae 12 Apr '01

12 Apr '01

Dear Mr. Manoj Paul, I am trying to understand the concept of H.323 presence. In AVD-2087, communication states to be exchanged are listed as: 1) status of the user, 2) its reachable address, 3) user's means of communication, including the preferred mode. The ASN.1 syntax CommunicationState in AVD-2087 includes newAliasAddress (corresponding to 2) above, I understand) and availableForCall, busy (both corresponding to 1) above). I wonder how 3) is handled. Is it going to be added in the course of work? Or as H.323 has the H.245 capability exchange procedure, H.323 presence needs only 1) and 2) above? Or still we would like to indicate e.g. being ready to communicate with fixed H.323 terminal at office, mobile phone like H.323 or H.323 on PDA on the road before the actual communication? Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: H.450.2
by Horvath Ernst 12 Apr '01

12 Apr '01

Francois, I think you are right; thanks for pointing this out. It will be corrected. Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet am: Dienstag, 10. April 2001 02:12 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: H.450.2 Guys, In Figure 7/H.450.2 in section 11.2, shouldn't the boxes A1 and A2 under "After service" say "Idle" instead of "Transferring"? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

H.450.2
by Francois Audet 09 Apr '01

09 Apr '01

Guys, In Figure 7/H.450.2 in section 11.2, shouldn't the boxes A1 and A2 under "After service" say "Idle" instead of "Transferring"? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

Information for traveling to the SG16 meeting in Brazil
by Patrick Luthi 06 Apr '01

06 Apr '01

Dear experts, I have been asked by many people if I could host a directory on the standard.pictel.com FTP site that would provide information and tips for traveling to the upcoming SG16 meeting in Porto Seguro, Brazil. I am happy to announce that I created a new directory called 0106_SG16meeting_Info (ftp://standard.pictel.com/0106_SG16meeting_Info/) and I have already posted a few documents that were sent to me along with a FAQ. Please feel free to upload useful documents that you want to share to the (0106_SG16meeting_Info) dropbox and e-mail me any answers to a question that should be posted in the FAQ! See you in Porto Seguro! Best regards Patrick ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Issues and Solutions: H.MMS.1 (Mobility for H.323)
by BOUGANT Fran�ois FTRD/DAC/ISS 06 Apr '01

06 Apr '01

Dear experts, Further to Mr. Roy message, I would like to make some comments : 1- Considering that any H.323 mobile user IS CONSIDERED ALSO AS A MOBILE USER by his network access provider and all his other service providers, there are two ways to design the H.323 functional architecture to support mobility : way A : define specific functional entities for mobility management in H.323 systems (HLF, VLF and AuF) without regarding mobility issues in external systems. Physically, each FE represents the database (containing ONLY data related to H.323 user and services) and the associated processes (access, updating...). Relevant interfaces between theses FEs and other FEs like GK, BE and IWF are defined. A specific protocol is defined also only for H.323 MM purpose. way B : Consider the mobility management as a service to make PER USER, and NOT PER USER AND PER SYSTEM. define the database containing data related to H.323 user and services. This database may be considered as a subset of the global database related to the H.323 mobile user (this global database contains also data related to the network access providing, billing, and other services). This global database and its associated processes (access, updating...) are common to different systems (related to the different access and service providers) and are seen as common FEs (AuF, HLF, VLF). Define also relevant interfaces between H.323 FEs and HLF,VLF,AuF-like FEs that doesn't belong only to H.323 functional architecture. A common protocol (or a protocol primarly designed for H.323 systems but containing extensions to be supported on interfaces between FEs from different systems, e.g. protocol compatible with different protocol stacks, different address formats, etc...). Regarding that any actual user subscribes more and more services that are more and more complex to implement, adopting the way A implies to solve serious problems of Mobility Management performance, because the HLF, if supposed to contain only data related to H.323 user mobility, need to access and update data in external databases, implying message and parameter conversion, interface multiplication, etc..., for different purposes (e.g. service interaction). Currently, the way A is chosen in H.MMS.1. I agree with Mr. Roy arguments by preferring the way B. 2- Because some interfaces are used both for MM in H.323 systems and between H.323 and mobile systems, the same protocol should be used for simplification. The protocol defined defined in H.MMS.1 (H.225.0 annex G), because H.323-oriented by nature, can't be optimized for a using in H.MMS.2. I also agree with Mr. Roy arguments and propose to keep all definitions and protocol design in H.MMS.1, but change only the name of the protocol, so it would be possible to make right extensions to this protocol for H.MMS.2. Best regards, Francois bougant ITU-T SG16 WP2 Q.5 participant H.MMS.2 recommandation editor France Telecom R&D -----Message d'origine----- De : Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Envoyé : lundi 2 avril 2001 00:36 À : ITU-SG16(a)MAILBAG.INTEL.COM Objet : Issues and Solutions: H.MMS.1 (Mobility for H.323) Hi, Folks: Further to my earlier message, I am sending a note related to the fundamental issues of the present H.MMS.1 (Mobility for H.323) draft. The note also includes the proposed solutions for all those issues. Please note that we discussed all those issues in the last November'00 SG16 meeting. We do not want that the same should be repeated in the upcoming SG16 May-June'01 meeting. In this regard, I also draw the special attention of editors of H.MMS.1 and H.225.0 Annex G, Rapporteurs of Q5/16 and Q2/16, and Mr. Tosco as well. Issues and Solutions of H.MMS.1 (Mobility for H.323): 1. Problem A: The document (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a]) still shows that HLF, VLF, and AuF, as if, are another sets of H.323 functional entities (like GKs, BEs, MCUs and terminals) that are entitled to use H.323/H.225.0 (RAS, Q.931/932)/H.225.0 Annex G protocols. However, like many other services such as directory, billing, and others, HLF, VLF, and AuF are the backend services and the protocols used by those entities must NOT be called a part of the H.323/H.225.0 protocol because these backend services protocols can be used by other application protocols (e.g., H.234, H.310) as well. Problem B: If the mobility management protocol is called H.225.0 Annex G, it cannot be used or extended for the global mobility management purpose (e.g., H.MMS.2). Problem C: More functionalities like Authentication, Charging/Billing, Directory, Policy, and other entities are needed for mobile (and even for non-mobile) functions. We cannot use make them as a part of H.323 protocol. Problem D: We cannot make one HLF/VLF/AuF protocol for H.323, another HLF/VLF/AuF protocol for H.324, and another for H.310, and another for IMT-2000. The same protocols MUST be allowed to be used by any applications whenever needed without providing any restrictions. Solution for problems A, B, C, and D: No functional entity like HLF, VLF, AuF, Charging/Billing, Policy, Directory or others will be defined as the H.323 functional entity. Rather, each of this entity will be a backend functional entity and the protocol among these entities must be independent of the H.323/H.225.0 Annex G protocol. The protocol used among HLF, VLF, and AuF entities may have all capabilities, functionalities and features as described in the document, but MUST be called a different protocol (e.g., M.management) so that all application protocols including H.323 will be at liberty to use it. So, the said protocol MUST NOT be called H.225.0 Annex G or its extension. In other words, we are changing the name only (not the capabilities, functions, or features). Similar will be the case for Charging/Billing, Policy, Directory or others. 2. Problem: Mobility management procedures (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a (Figure 11a)]) still indicate that there is only one HLF that communicates directly with the VLFs located in two separate administrative domains. This breaks the fundamental concept of the administrative domains as standardized in H.323 because an administrative domain is autonomous and can communicate only through the BEs (with one HLF, this principle is violated and breaks the basic foundation of H.225.0 Annex G). Solution: Similar to inter-zone (e.g., Figure 13 of AVD-2053a), the communications between the two administrative domains MUS be made via the BEs no matter whether there is one or multiple HLFs. Communications scenarios with at least one HLF in each administrative domain needs to be shown. Best regards, Radhika R. Roy AT&T Technology Consultant Room 3D-2C09 200 S. Laurel Avenue Middletown, NJ 07748 +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: What does 'exchange' mean and which H.245 message gets to be sent first?
by Frank Derks 05 Apr '01

05 Apr '01

Paul, H.323v4 is indeed where I got the text from, but that still leaves me clueless about what these procedures could be. You say that the sending of the TCS can force the remote EP into sending a TCS itself. I didn't think it is also the case that upon reception of a TCS, the receiving EP also has to send a TCS. It is only in this first occasion (or after an "empty TCS"), that this situation arises. What is your interpretation of "capability exchange" (I.e. the sending of the capability set only or the mutual exchange of capabilities)? Regards, Frank plong@IPDIALOG.COM@SMTP@MAILBAG.INTEL.COM on 03/04/2001 19:18:54 Please respond to plong@IPDIALOG.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: What does 'exchange' mean and which H.245 message gets to be sent first? Classification: Frank, 1. I have no idea what those failing procedures would be. Maybe it's a v4 thing. 2. Yes, that is correct. Because the TCS must be the first message, if an EP receives a TCS, it must sends its own TCS (if it has not already) before it responds to the TCS with, typically, TCSAck. This is how an EP can force the remote EP into performing cap exchange. Paul Long ipDialog, Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Frank Derks Sent: Tuesday, April 03, 2001 10:33 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: What does 'exchange' mean and which H.245 message gets to be sent first? H.323 talks about capability exchange, but it is not clear to me whether exchange really means that communicating endpoints send their capability sets to _each other_ or that one endpoint sends its capability set. An example of this can be found in the below text. It talks about succesfully completing capability exchange, but does this means that the initiating endpoint has sent its capability set and that this was acknowledge by the receiver or does it mean that it has also received the capability set of the other party? 8.2/H.323 states: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent unless the endpoint is indicating that it understands the parallelH245Control field (see section 8.2.4). If prior to successful completion of terminal capability exchange, any other procedure fails, (i.e. rejected, not understood, not supported) then the initiating endpoint should initiate and successfully complete terminal capability exchange before attempting any other procedure. " The second sentence mandates that the terminalCapabilitySet message be the first message sent (given that "parallelH245Control" is not used). Which "failing procedures" are then being referred to in the third sentence? If terminalCapabilitySet has to be the first message to be sent, does this mean that an endpoint that has not sent a terminalCapabilitySet message yet and receives this message, it first has to send a terminalCapabilitySet message before acknowledging the received capability set? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Sending the "empty capability set" in the first TCS
by Frank Derks 04 Apr '01

04 Apr '01

Suppose that, after having established a call with a remote party, I want the remote party to send its capability set, but do not yet want to send my own capability set. If I am the one that established the H.245 Control Channel, I can imagine that the establishment itself does not necessarily trigger the remote party to send its capability set (although it could), but that the reception of a TCS message does. If I now send a TCS message with an empty capability set, am I doing something that I shouldn't do, or is this perfectly alright and does this trigger the remote party to send its capability set? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Some questions about H.450.4
by Frank Derks 04 Apr '01

04 Apr '01

5/H.450.4 states that it is an implementation/application matter which of the two hold scenarios (near or far end) is invoked. It does, however, not state whether it is mandatory to implement both, any of the two or one particular scenario. Which is the case? The fact that 10.2/H,450.4 mandates that a Gatekeeper/Proxy passes near end call hold messages on to the held endpoint would seem to mandate that at least the near end scenario has to be supported. 5.1/H.450.4 states that the holding endpoint "has to" stop receiving and sending user packets. There is, however, no "shall" in the sentence. Should this then be treated as mandatory? Furthermore, what does it actually mean? To stop receiving can, e.g., mean that received packets are not passed on to the user. The section then continues with a number of MOH options, the last of which is "other indications". This is extremely vague when considering that 7.1.1/H.450.4 mandates that MOH be provided. Does "other indications" include doing nothing? 7.1.1/H.450.1 mandates that MOH be provided to the held user. Why is MOH a mandatory requirement? 7.2.1/H.450.4 states that if the response to a holdNotific.inv or a retrieveNotific.inv, while in the state Hold_NE_Held, is a reject APDU, this shall be _ignored_. The first means that the originating endpoint (or rather its user) simply (and falsely) assumes that the remote party is on hold. Ignoring the second, means that originating party does not restore its state to Hold_Idle! The section then state that user B knows about the hold condition because of the MOH. How can it be guaranteed that the MOH is such that it is recognised as such? 10.1/H.450.4 is about remote-end call hold. Nevertheless, it states: "The proxy in this case shall act as a held endpoint for remote-end call hold and may act as a served endpoint for _near-end hold_". Should the part about near-end hold be interpreted as applying to the role it plays towards the held endpoint? 10.2/H.450.4 states that the near-end call hold messages _shall_ be passed on to the held endpoint. Why isn't it allowed to use remote end call hold on the held side? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Try it for free! 3840
by stacy__l＠DORADO.UNER.EDU.AR 04 Apr '01

04 Apr '01

1 0

Megaco File Repository -- Addition Of Sample Call Flows
by Tom-PT Taylor 03 Apr '01

03 Apr '01

This note has two purposes: to remind people of the Megaco file repository and to announce the availability of a sample call flow document created by Madhu Babu Brahmanapally <madhubabu(a)kenetec.com> and colleagues, which could be the strating point for an Informational RFC. I have place these call flows in the Current/IETF/ sub-directory (see below). The Megaco file repository is at ftp://standards.nortelnetworks.com/megaco/docs/ and has the following structure: docs/ Approved/ Current/ ATMF/ IETF/ ITU-SG11/ ITU-SG16/ Expired/ Related/ The documents in Approved/ have all been formally approved by the IETF and/or ITU-T SG 16, hence represent the current state of standardization. In particular, this directory holds the latest formally approved H.248 Implementor's Guide, which all developers should have to hand as a supplement to H.248/RFC 3015. The documents in Current/ represent work in progress in various organizations. They all need refreshing at the moment. In particular, I don't have the latest from SG 11 and the SG 16 meeting last month. The ITU-SG16 directory holds the latest draft of the H.248 Implementor's Guide. NOTE THAT THIS IS NOT FORMALLY APPROVED, HENCE CAN CHANGE. The next meeting at which formal approval will take place is in early June. Expired/ holds old drafts, long gone from the IETF archive. Related/ holds documents of interest to Megaco. File names ending in _PDF are PDF documents; those ending in _MSW are Microsoft Word documents. The remainder are text. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor(a)nortelnetworks.com

1 0