- sg16-avd - lists.packetizer.com

FW: H.323 questions
by Roy, Radhika R, ALARC 09 Dec '99

09 Dec '99

Hi, Everyone: I am enclosing Ben's questions to the SG16 members for their answer because I believe that there are many members who might better insights for taking part in H.323 development. Best regards, Radhika R. Roy AT&T +1 732 420 1580 > -----Original Message----- > From: ben-w(a)jlonline.com [SMTP:ben-w@jlonline.com] > Sent: Thursday, December 09, 1999 4:09 AM > To: Roy, Radhika R, ALARC > Subject: H.323 questiones > > Hi Mr.Radhika , > I have some questiones about Ad Hoc Conference defined in ITU-T > Recommendation H.323. > > H.323 Section 8.4.3.1 states: > > Endpoint 1 creates a conference with Endpoint 2 as follows: > A1) Endpoint 1 sends a Setup message to Endpoint 2 containing a > globally unique CID ? N and conferenceGoal = > create according to the procedure in 8.1. > A2) Endpoint 2 has the following options: > .... > A2d) If Endpoint 2 is an MC(U) that hosts multiple conferences and > wishes to provide Endpoint 1 with a choice > of conferences to join, it can send a Facility message > indicating conferenceListChoice and a list of > conferences that Endpoint 1 may choose from. The list of > conferences is sent as part of the Facility- UUIE. > For backward compatibility, with version 1 endpoints, > conference lists are only provided if the > protocolIdentifier in Endpoint 1's Setup message indicates > that it is version 2 or above. > > Upon receipt of this conferenceListChoice Facility message, > Endpoint 1 may join a conference from the list > of conferences by sending a new Setup message to the MC(U) on > the Call Signalling Channel which contains > the selected CID and which has conferenceGoal = join. If > Endpoint 1 chooses not to join any of the listed > conferences, it shall send a Release Complete message to the > MC(U). > > 1. When EndPoint 1 calling EndPoint 2(MCU),MCU "wishes to provide > Endpoint 1 ...",what > does it mean?Can't any endpoint get a list of conferences?What > decides it's wish? > CUSeeMe Pro and NetMeeting get diferent list of conferences from > MeetingPoint(MCU), I > called MeetingPoint too,but I can't get a list of conferences,I > connected with it just like an > endpoint.Why?Does it mean I have created a new conference in a > MCU?! > 2. If an EndPoint is a standard H.323 client,and MCU provide it with > a list conferences,then it > has only two choices: join or release.It means the EndPoint can't > create a conference!How to > create a conference in a MCU?Who is the initiator? > 3. If I want to learn details about MCU calling procedures,what other > protocols should I study? > > The questiones puzzle me,can you help me ? > > Thanks, > Ben. > email: ben-w(a)jlonline.com <mailto:ben-w@jlonline.com>

2 1

Re: H.245 "receiveAndTransmitAudioCapability" and symmetric codec s
by Tzvi Kasten 09 Dec '99

09 Dec '99

Paul, Regarding your two questions: 1. Do we need a way to express symmetric codecs. - Yes of course! 2. Will using receiveAndTransmit caps for this cause problems - Considering that vendors are already using receiveAndTransmit caps for this and considering that assuming that the endpoint is signaling symmetric codecs in a case where it is not will not break anything in terms of interoperability I would think that the safest way to act when receiving receiveAndTransmit caps is to assume that the capability is symmetrical. As this seems the most convenient way to address the issue of symmetrical codecs and as vendors have already interpreted it and are using it this way I would suggest the document be updated to have the receiveAndTransmit caps be the way to express symmetric codecs. Regards Tzvi Kasten Networking Infrastructures Group Manager Research & Development VCON Ltd. Tel: 09-9590020 ( 972-9-959-0020) Email: zvik(a)vcon.co.il http://www.vcon.com > -----Original Message----- > From: Paul Long [SMTP:plong@SMITHMICRO.COM] > Sent: Tuesday, December 07, 1999 3:35 PM > To: h323implementors(a)imtc.org > Subject: RE: H.245 "receiveAndTransmitAudioCapability" and symmetric > codecs > > Paul, > > The capability table is a sort of artist's pallet, containing all the > colors > that he or she may use. The descriptors, on the other hand, are the > brushes > that mix the colors and apply them to the canvas. Without descriptors, no > modes are expressed--the canvas is blank. (Hey, I think I could write a > haiku about this. :-) ) It is H.245 and not H.323 that stipulates this > (B.2.2.2/H.245v5: "CapabilityDescriptors are used to indicate a terminal's > capability to transmit and receive"), so a referencing Recommendation > would > have to override H.245 to avoid using descriptors, none of which do, as > far > as I know. > > IMO, the purpose of a receiveAndTransmit cap is at minimum to provide a > shorthand replacement for separate receive and transmit caps. From what > I've > seen, that's what vendors by and large use them for. I don't think the > H.245 > authors ever intended receiveAndTransmit caps to stand alone, unreferenced > in the capability table. Moreover, I believe that the authors intended > receiveAndTransmit caps to express symmetric codecs, although this is > clearly not stated in H.245 (or H.323). Finally, I believe we could add > normative text to H.245 that says that, without the slightest possibility > of > breaking existing implementations, receiveAndTransmit caps shall express > symmetric codecs. I've worked through different scenarios and have > convinced > myself of this. > > The two questions I pose to this reflector are, 1) do you agree that we > need > some way to express symmetric codecs and 2) can you see any way that > requiring receiveAndTransmit caps to express this could cause existing > implementations to break or make things any worse than they already are, > i.e., one-way audio? Here's an important point: I am saying that this > _cannot_ break an existing implementation not that it _probably_ won't. > > (Should we move this discussion to the ITU-SG16(a)MAILBAG.INTEL.COM > reflector?) > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paul.jones@ties.itu.int] > Sent: Monday, December 06, 1999 11:33 PM > To: Karl.Klaghofer(a)icn.siemens.de; h323implementors(a)imtc.org > Subject: Re: H.245 "receiveAndTransmitAudioCapability" and symmetric > codecs > > > Karl, > > Here's my interpretation on this topic: > > To indicate simultaneous capabilities, an endpoint will normally send a > capability descriptor table with the transmit and receive capabilities. > Each table entry will list the codecs that may be used simultaneously. > The > remote endpoint may select a single descriptor table entry to use when > selecting channels to open, but may not select one codec from one table > entry and another from another table entry. > > Here's a section from 6.2.8.1/H.323 on this topic: > > --- BEGIN > The terminal's total capabilities are described by a set of > capabilityDescriptor structures, each of which is a single > simultaneousCapabilities structure and a capabilityDescriptorNumber. By > sending more than one capabilityDescriptor, the terminal may signal > dependencies between operating modes by describing different sets of > modes > which it can simultaneously use. For example, a terminal issuing two > capabilityDescriptor structures, one { {H.261, H.263}, {G.711, G.723.1, > G.728} } as in the previous example, and the other { {H.262}, {G.711} }, > means the terminal can also operate the H.262 video codec, but only with > the > low-complexity G.711 audio codec. > --- END > > Inside a given table entry, the endpoint will indicate it's capability > to > transmit G.711, for example, and receive G.711. Rather than insert two > capabilities-- one for transmit capability and one for receive > capability-- > the endpoint will provide a single "receiveAndTransmitAudioCapability". > If > this "combined" capability did not exist, the endpoint could just > examine > the capability descriptor tables looking for descriptor table entries > that > had an acceptable transmit and receive capability and work within that > context. > > Perhaps the main use for the "receiveAndTransmitAudioCapability" is the > case > when there is no capability descriptor tables is transmitted at all. > Suppose you have an audio device that can do G.723 and G.711, but only > one > at a time. Rather than build a capability descriptor table that looks > like > this: > > {G.711 Receive, G.711 Transmit} > {G.723 Receive, G.723 Receive} > > one could simply send over two capabilities, one for G.723 and one for > G.711, that are both "receiveAndTransmitAudioCapabilities". That may > have > been the intention of the sentence you quote below. However, I would > not > that this not legal in H.323. Specifically, H.323 says that ``all H.323 > terminals shall transmit at least one capabilityDescriptor structure.'' > Perhaps this text was inserted to allow other device types other than > H.323 > to avoid using descriptors in simple cases. > > I hope this helps... and is consistent with others' views. > > Paul > > ------------------------------------------------------------------------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info"

1 0

FW: Contribution for Conf Call on December 14
by Roy, Radhika R, ALARC 08 Dec '99

08 Dec '99

The SG16 mail server might be working now. > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Wednesday, December 08, 1999 3:35 PM > To: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > 'laurent.thiebaut(a)alcatel.fr'; 'Ameneh.Zahir-Emami(a)alcatel.fr' > Cc: 'Dale.Skran(a)ascend.com'; 'ggf(a)lucent.com'; 'okubo(a)GITI.OR.JP' > Subject: Contribution for Conf Call on December 14 > > Hi, Everyone: > > I am enclosing a contribution for the upcoming conference call on December > 14. > > This is a follow-up discussion of today's conference call. As I explained, > there are three distinct areas where we need to focus to develop the H.323 > mobility protocol. This contribution describes three distinct areas. For > each area contributions are needed. However, some contributions have > provided a complete solution in one of the areas. There contributions need > to be discussed in great detail immediately. For example, AT&T's > contributions - APCs-1651/1652. Similar is the case for other > contributions. > > I am also providing this contribution to all members so that all members > provide their comments immediately. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > <<MTD-y_ATT.doc>> > > PS: SG16 email reflector is still down. >

1 0

ITU-SG16 Mail List Active Again
by Meyer, Greg W 08 Dec '99

08 Dec '99

Hi: I've discovered that mail lists are like children - they seem to know when you're not looking and will do something you don't want them to. In this case, I was away from my email for several days and that's when this mail reflector decided to have problems. An endless loop caused LISTSERV to stop. I've deleted the offending subscriber and the list should be back online now. My apologies for any inconvenience. Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506

1 0

IGNORE THIS EMAIL: testing to see if this reflector is working
by Kumar, Vineet 08 Dec '99

08 Dec '99

testing to see if this reflector is working

1 0

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

H.323 Mobility Meeting Meeting Minutes
by Roy, Radhika R, ALARC 22 Nov '99

22 Nov '99

Hi, Everyone: The detail of our next H.323 Ad Hoc Group conference call is as follows: Next Conference Call Information and Agenda Date: November 29,1999 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13617781 Number port reserved: 30 Ports Conference Call Bridge call in number: +1 (415)-904-2888 Passcode: 6752410 (IMTC Representative for facilitating the conference call: Senthil Sengodan, Nokia, senthil.sengodan(a)nokia.com. We appreciate IMTC for facilitating the conference call) Agenda: 1. Call to Order & Opening Remarks 2. Attendance Registration 3. Introduction and Numbering of Contributions: 4. Agenda Review and Approval 4a. Review H.323 Mobility Ad Hoc Meeting report 5. Correspondence to other standards groups: Discussed and identified other standards group like TIPHON, IMTC, IMT-2000 ITU-T SG-11, 3GPP for correspondence 6. Old Business 6a. review Carry over contributions 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF) 6c. H.323 Mobility Architecture: 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, Goal and work plan) 8. Meeting Schedule 8a. Discuss next conference call meetings 9. Review Assignments 10. Review Workplan 11. Open Discussion 12. Adjourn Paul Reddy (Intel), Ad Hoc Editor of H.246 Annex E is hereby requested to conduct the meeting. (Some members wanted to know whether any member of SG16 other than the sponsor company may conduct the meetings. We are open to the fact any SG16 member can conduct the meeting irrespective of the fact whether the conference calls are facilitated/hosted/sponsored by a particular company. Every SG16 member is welcome to conduct the meeting.) All contributions will be allocated on or before November 25. The uploading of the documents should be done by November 26 (12:00 AM EST USA). Please contact Paul K. Reddy, Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone # +1 (503)-264-9896, paul.k.reddy(a)INTEL.COM, http://standard.pictel.com/ftp/avc-site/Incoming/H323_Mobility/ for obtaining the MTD number and uploading the document. The meeting minutes of the last conference call held on November 17, 1999: Conference Call Meeting Summary 1. Call to Order & Opening Remarks Conference call started at 8:15 am, Tuesday, November 17, 1999 hosted by Intel Corporation. 2. Attendance Registration See roster below. 3. Introduction and Numbering of Contributions: MTD-14 A total of 14 contributions were submitted and uploaded to the standards.pictel.com server for reviewing and discussion during this conference call. See the contribution list table below. Contribution MTD-14 was introduced by Intel and AT&T with the list of all H.323 mobility related contributions at SG16 meeting in Red Bank, NJ, USA and for the conference call meeting on November 17, 1999. Contributions are upload and are available for review at: http://standards.pictel.com/ftp/avc-site/Incoming/H323_Mobility/Conference_C all_11_17_1999 and http://standards.pictel.com/ftp/avc-site/9910_Red 4. Agenda Review and Approval Contribution MTD-01 (Agenda, from conference call chair) reviewed and accepted as modified ( * add to the agenda item 5, TIPHON, IMTC, IMT-2000 ITU-T SG11, 3GPP standards group for correspondence * reassign the MTD-03a contribution to agenda item 6 instead of agenda item 6b) 4a. Review H.323 Mobility Ad Hoc Meeting report TD-65.doc TD-65 document was included into the MTD-03a document by the H.323 Annex H editor, deferred to review MTD-03a 5. Correspondence to other standards groups Discussed and identified other standards group like TIPHON, IMTC, IMT-2000 ITU-T SG-11, 3GPP for correspondence 6. Old Business :- MTD-02a, MTD-03a, MTD-04a * Contribution MTD-02a: AT&T presented this document with the summary of the H.323 Mobility work at Red Bank, NJ, USA meeting. * Contribution MTD-03a: H.323 Annex H Editor from Motorola presented this document with inclusion of TD-16, TD-42b and TD-65 as the main H.323 Annex H document. The following changes were suggested by the group: 1. Section 4. Scope: Keep first sentence and delete the rest of the paragraph. 2. Section 5.1: change the title to "Basic concepts that could be used to provide H.323 Mobility" 3. Section 5.2: remove reference to IMT-2000, the title should read as "Mobility Management applicable to H.323" and beginning of the paragraph should read as "H.323 should support the Mobility Management defined as:" * Contribution MTD-04a: H.323 Annex H Editor from Motorola presented this document with new sections to be added to the main H.323 Annex H document. Group agreed to include section 8 title and section 10 title of the MTD-04a document into the main H.323 Annex H document. The section title which are agreed are: 1. H.323 Roaming Interworking with Non-H.323 Networks 2. Non-H.323 Supplementary Services Interwroking 6a. review TD-16, TD-42b TD-16, TD-42b documents were included into the MTD-03a document by the H.323 Annex H editor, deferred to review MTD-03a 6b. H.323 Mobility Functional Entities (HLF, VLF, AuF, IWF):- MTD-06, MTD-07, MTD-09 Contributions MTD-06, MTD-07, MTD-09 are carried over to next conference call, which is scheduled on November 29,1999. 6c. H.323 Mobility Architecture: MTD-05a, MTD-08 Contributions MTD-05a and MTD-08 are carried over to next conference call, which is scheduled on November 29,1999. 6d. 7. New Business 7a. H.323 Interworking with PLMNs (H.246 Annex E scope, terms of reference and work plan): MTD-13, MTD-10a Contributions MTD-13 and MTD-10a are carried over to next conference call, which is scheduled on November 29,1999. 8. Meeting Schedule 8a. Discuss next conference call meetings: MTD-11, MTD-12 * Contribution MTD-11: "Nokia's proposal for IMTC to facilitate all future conference calls only, was agreed by the H.323 Mobility Ad Hoc group. Under the conditions that the SG16 Mobility Ad-Hoc group will continue to work within the ITU SG16 Q13/14 bylaws and procedures. And that the SG16 Mobility Ad-Hoc group was no obligation to IMTC." H.323 Mobility Ad Hoc group agreed to have next conference call on November 29, 1999 from 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) and IMTC to make arrangement for the conference call bridge. * Contribution MTD-12: This contribution from AT&T was withdrawn after the MTD-11 was accepted by the group. 9. Review Assignments 10. Review Workplan 11. Open Discussion * On behalf of Ad Hoc Mobility Group, Radhika Roy, AT&T discussed the H.246 Annex E work progress and requested Paul Reddy, Intel to work as Unofficial Editor to make progress on the H.246 Annex E document, since this group cannot make decision on the Editorship. Intel agreed to work as an unofficial Editor of the H.246 Annex E Document and will bring in a contribution on H.246 Annex E for next conference call. All companies interested in H.246 Annex E are requested to submit contribution for the next conference call. 12. Adjourn Conference call Meeting adjourned Tuesday, November 17, 1999 at 10:20 AM (PST). Attendance Registration for H.323 Mobility Conference Call on November 17, 1999 Name Company Phone FAX E-Mail Paul K. Reddy Intel Corporation 503-264-9896 503-264-3375 paul.k.reddy(a)intel.com <mailto:paul.k.reddy@intel.com> Vineet Kumar Intel Corporation 503-264-3439 503-264-3375 vineet.kumar(a)intel.com <mailto:vineet.kumar@intel.com> Jaakko Sundquist Nokia jaakko.sundquist(a)nokia.com Peeter Pruuden Nokia peeter.pruuden(a)nokia.com Senthil Sengodan Nokia senthil.sengodan(a)nokia.com Pekka Nokia Nokia Radhika R. Roy AT&T rrroy(a)att.com Marc Roelands Siemens marc.roelands(a)siemens.atea.be Edgar Martinez Motorola martinze(a)cig.mot.com Paul Guram Motorola lpg019(a)email.mot.com Milo Orsic Lucent Technology orsic(a)lucent.com Stephen Terrill Ericsson stephen.terrill(a)ericsson.com <mailto:stephen.terrill@ericsson.com> Goesta Linder Ericsson gosta.linder(a)lme.ericsson.se Anders Svennevik Ericsson Anders.Svennevik(a)era.ericsson.se <mailto:Anders.Svennevik@era.ericsson.se> Michael D. Gallagher Synacom Technology mike(a)synacom.com <mailto:mike@synacom.com> Stu Jeffery Synacom Technology stu(a)synacom.com <mailto:stu@synacom.com> Paul E. Jones Cisco paul.jones(a)ties.itu.int <mailto:paul.jones@ties.itu.int> Nextone Barry Aronson Toshiba Corp. baronson(a)acm.org Laurent Thiebaut Alcatel +33 (0)1 3077 0645 laurent.thiebaut(a)alcatel.fr <mailto:laurent.thiebaut@alcatel.fr> Ameneh Zahir-Emami Alcatel Ameneh.Zahir-Emami(a)alcatel.fr <mailto:Ameneh.Zahir-Emami@alcatel.fr> Contributions submitted for H.323 Mobility Conference Call on November 17, 1999 LA MTD Source Title MTDs in the Conf. Call, Nov. 17, 1999 1a Intel H.323 Mobility Ad Hoc Group Interim meeting via Conference Call Agenda 2a AT&T H.323 Mobility Ad Hoc Group Activity Report 3a Motorola Annex-H (User, Terminal and Service Mobility in H.323) 4a Motorola To Complete the H.323 Annex-H draft outline 5a Motorola Integrating 3GPP's option-1 architecture into the H.323 wireless IP mobility system and a full migration from GPRS to a Multimedia IP network proposal 6 Nokia H.323 Annex H Functional Architecture and Reference Points 7 Ericsson "Definition of terms for H.323 Annex H". 8 Alcatel Integrating 3GPP's architecture into the H.323 wireless IP mobility system 9 Alcatel Clear Split of functions between Call Control and (radio) Access networks /Annex-H (User, Terminal and Service Mobility in H.323) 10a Motorola IMT-2000 Global Roaming and Interworking Scenarios 11 Nokia, Intel IMTC Proposal to host future conference calls for H.323 Mobility Ad Hoc group interim ITU-T SG16 Q13/14 work 12 AT&T AT&T's proposal to host next H.323 Mobility Ad Hoc group conference call. 13 Intel H.246 Annex E Goal and Workplan 14 Intel, AT&T List of all H.323 Mobility contribution at SG16 Q13/14 meeting in Red Bank, NJ,USA and Nov 17,1999 conference call Best Regards, Radhika R. Roy H.323 Ad Hoc Mobility Group AT&T +1 732 420 1580 rrroy(a)att.com > >

1 0

OBJECT IDENTIFIER for ISUP
by Francois Audet 22 Nov '99

22 Nov '99

Anybody has an idea what the OBJECT IDENTIFIER should be for the different versions of ISUP? ETSI, ANSI? ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

1 0

Definitions of terms for [Robustness]
by Maureen Stillman 22 Nov '99

22 Nov '99

We need to begin a debate of the terms for robustness. The following by Radhika Roy of AT&T is a first set of definitions for your review and comment. Note: The following definitions are a part of the document referenced below: Study Group 16 Delayed Contribution: D.225 (WP 2/16) Santiago, Chile, 17-28 May 1999 Question(s): 13/16 SOURCE*: USA TITLE: Framework for Reliable H.323 Gatekeeper Architectures AUTHOR: Roy, Radhika [rrroy(a)ATT.COM] Reliability: To have the robust GK architecture for increasing reliability (e.g., appropriate redundancy in the architecture as well as robustness of the software codes). Availability: To provision the GK architecture with implications for both the planned (e.g., upgrading, maintenance, etc.) and unplanned (e.g., failures) outages of the GK itself or its components to meet the desired availability goal (e.g., appropriate redundancy in the architecture based on trade-offs between the planned and unplanned outages). Serviceability: To include provision for outage tolerances in the GK level architectural framework to meet the service level requirements (e.g., if 24-hour a day, 7-day a week, and 365-day a year is the requirement for the GK, the GK architectural scheme can be provisioned with redundancy to meet the requirement considering the outages). Recoverability: To keep proper provision within the GK architecture for the recovery time as well as for any signaling messages that might have been in transit at the time of failure Scalability: To be able to increase the throughput by the GK architecture as more resources are put to the system considering the fact that a GK might be used by a large user community (e.g., capability to provide automatic load balancing within the GK architecture with proper redundancy considering outages). Context: To be able to maintain context across multiple requests with minimum latency within a session by the GK architecture in view of outages. Security: To provide adequate security with redundant GK architectures in the event of failures as well as during replications. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

Minutes of the [Robustness] telecon on November 17, 1999
by Maureen Stillman 22 Nov '99

22 Nov '99

Minutes of H.323 Robustness Teleconference - November 17, 1999 Prepared by Maureen Stillman, Nokia Next Teleconference: Will be held on Tuesday, December 14 at 11AM EST USA. Nokia will host this again. Please send e-mail to maureen.stillman(a)nokia.com if you wish to join in. Agenda for the next teleconference: Discuss failure scenarios that have been posted to the mailing list by the robustness working group. Action items from this teleconference: 1. Post meeting minutes to mailing list 2. Post terms and definitions from submission D.225 Santiago Chile from R. Roy of AT&T to mailing list to kick off a discussion of terms. 3. Everyone needs to post to the SG16 mailing list one or more failure scenarios that require robustness/recovery mechanisms. Please complete this by December 6 and include in the subject heading the keyword [Robustness]. Anyone is welcome to send a scenario, so please join in. Attending the 11/16 teleconference: Rich Bowen rkbowen(a)cisco.com Paul Jones Paul.jones(a)ties.itu.int Radhika Roy rrroy(a)att.com Orit Levin orit(a)radvision.com Terry Anderson tla(a)lucent.com Kumar, Vineet vineet.kumar(a)intel.com Michael Corrigan Michael_Corrigan(a)mw.3com.com Robert Callaghan Robert.Callaghan(a)ICN.siemens.com Glen Freundlich ggf(a)lucent.com Boaz Michaely Boaz_Michaely(a)vocaltec.com Jean-philippe Caradec caradec(a)piano.grenoble.hp.com Maureen Stillman maureen.stillman(a)nokia.com Yorg Ott jo(a)tzi.uni-bremen.de Michael Vortensy at Vocaltech (please send me your e-mail address) Ed Federmeyer Ed_Federmeyer(a)mw.3com.com Sasha Ruditsky at Radvision (please send me your e-mail address) Summary of Teleconference: Robert Callaghan reported that the direction of the rapporteurs from Study Group 16 was that the robustness working group produce a submission that could be debated and voted on at the February meeting in Geneva. Given this deadline, the group decided on the following course of action: Step 1: Describe scenarios to determine which failures exist (see action item number 3). Step 2: Examine scenarios and determine means to deal with them Step 3: Determine short term measures for dealing with failures and propose them at the Geneva meeting. Discussion: Definition of terms for robustness: We need to define terms. This was supposed to happen on the mailing list over the last month, but no one sent any input. It was suggested that we use R. Roy's definitions in section 2 of D.225 as a starting point for the discussion. These definitions will be posted to the mailing list (see action item 2). Short Term Issue #1: The problem of defining the alternate gatekeeper mechanism is not quite solved. Some of problems with it in the H.323 document were brought up at the Red Bank meeting. Short Term Issue #2: The standard's document does not adequately describe whether we are referring to a TCP connection or a call signaling channel. What is the difference between a disconnect versus an IP failure? We need to carefully go through the standard and clarify in each place clarify what precisely is meant by "call signaling channel". Short Term Issue #3: For systems currently compliant with H.323 v3 or lower, if a call is disrupted the endpoint is left in a "hung" state, meaning that you can't make another call to the endpoint and you can't recover. It was suggested that we deallocate or clear the resources associated with these "hung" calls so that the endpoint can receive new calls and operate normally again. The group decided that we need to perform further analysis before we decide on how to deal with this issue. Goals: The group formulated the following (incomplete) list of goals for the robustness work: 1) Recovery from GK crash 2) Recovery from other components crashing including gateways, MCUs, MGC, etc. 3) GW switching NIC cards during a call 4) Call signaling channel fails; but we don't want to lose a call already in progress between two endpoints. 5) How do you detect a failure? 6) What are the procedures for recovery from a failure? 7) Clarify on how to reestablish call signaling Legacy Issue: Once we have decided on robustness mechanisms, these would be included in version 4 or later of the standard. How do we deal with earlier versions of H.323 that don't handle robustness? How do we deal with the fact that in an operational system some components will support robustness mechanisms and some will not? Call Signaling Channel Issue: Standard currently says that the call signaling channel can be closed during a call and the call will continue. It also states that the call signaling channel can be reopened, but it doesn't say how. The problem is that we don't know how to associate the new connection with any ongoing call. A second problem is that we may need the call signaling channel to establish supplementary services. If the channel has been closed, then we may want to bring it back up for supplementary services. Scenarios: It was decided that the work of the robustness group should be scenario driven. We need to determine what failure scenarios are likely to occur in order to understand how to correct them. It was decided that everyone from the group would submit one or more scenarios in time for the next teleconference for discussion (see action item 3). Please submit these to the list by December 6. Simple Scenario: We discussed the most simple and basic scenario (outlined by Y. Ott): Corporate Environment - 1 gatekeeper; all calls are gatekeeper routed; H.225 up and running; might be using fastconnect; two endpoints have a call in progress Gatekeeper goes down or fails - the two endpoints lose the call signaling channel We agree that such a call needs to be continued - how this should be done is a problem that needs to be solved. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

[Fwd: Re: [Fwd: H.323 Mobility: post meeting]]
by Edgar Martinez [1] 19 Nov '99

19 Nov '99

Dear Roberto, I did think we have agreed on the VLF, HLF and AuF definitions, yet. Those terms came out of the Ad-hoc meeting in Redbank. Ed -------- Original Message -------- From: wnk(a)fub.it (Roberto Winkler) Subject: Re: [Fwd: H.323 Mobility: post meeting] To: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Hello, I may have missed some crucial piece of information but can somebody provide me with the number of the contribution where the entities VLF, HLF and AuF are defined ? Thanks very much and best regards Robzerto Winkler >FYI > >-------- Original Message -------- >From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> >Subject: H.323 Mobility: post meeting >To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> > >Dear All, > >I have updated MTD-03 Annex- H outline >now MTD-03b as requested >by the Ad-hoc group. > >For each section I have identify where the section >and text came from. Where we stray from the >annex H "Terms of Reference" it has been noted in >the document e.g., to delete part of "Scope". > >I have also added the change marks and a document >history table to MTD-3b. > >All the documents have been place in: > >http://people.itu.int/~emartine/temp/SG16-mobility/ConfCall_Nov17-99/ > >You also can get access via > >http://people.itu.int/~emartine/ > >Regards, >-- >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/ > >------------------------------------------------------------------- >Mail archive for TIPHON_WG7 can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm >------------------------------------------------------------------- Roberto Winkler Senior Researcher Fondazione Ugo Bordoni Via B. Castiglione, 59 00142 Rome Italy tel +39 0654803411 fax. +39 0654804404 e-mail wnk(a)fub.it

1 0

AD Hoc Mobility Gorup Activities
by Roy, Radhika R, ALARC 18 Nov '99

18 Nov '99

Hi, Everyone: I have to report few things after yesterday's conference call as follows: 1. I have requested both editors - Ed Martinez and Paul Reddy to prepare the yesterday's meeting minutes and send it to me for distribution to the SG16 reflector. 2. Both editors have also been requested to prepare a tentative meeting agenda for the upcoming conference call to be held on November 29 and send it to me for distribution to the SG16 reflector. IMTC representative has also been requested to send the conference bridge information for distribution along with the meeting agenda. We provide our sincere thanks to the IMTC for facilitating the SG16 conferencing. 3. All contributions will be allocated on or before November 25. The uploading of the documents should be done by November 26 (12:00 AM EST USA). Please contact Paul K. Reddy, Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA, Office Phone # +1 (503)-264-9896, paul.k.reddy(a)INTEL.COM, http://standard.pictel.com/ftp/avc-site/Incoming/H323_Mobility/ for obtaining the MTD number and uploading the document. 4. The final agenda for the upcoming conference call on Novemebr 29 will be sent by me (along with editors) on November 26. 5. I will request one of the editors or any other SG16 member to conduct the conference as per agenda on the November 29th conference call (while I plan to act as a moderator behind the scene as I did in the yesterday's conference call). 6. Editors are hereby requested to clearly indicate in the edited documents what has been added as new and what has been in the previous version. The general principle is that editors will add new things based discussions held in the conference calls, discussions via SG16 emails, APCs, TDs, and MTDs. (However, SG16 members are welcomed to discuss any item with editors on one-to-basis to clarify additional points. Editors may include any of those items if these are consistent with the general principle. If editors feel that additional points that need to be included based on private conversations and are not covered in the public discussion as indicated in the general principle, they indicate clearly in the document that those items have been included after private discussions.) 7. I plan to send brief notes related to H.323 Annex I and H.246 Annex E soon. We have seen that Ed Martinez of Motorola had already sent the revised version of H.323 Annex H so promptly that we appreciate his work. We also thanks Paul Reddy of Intel who is working so hard in helping to make the activities of the Ad Hoc Group a success. Finally, we all have been very much encouraged to see the amount of support provided by all members through their lively discussions, contributions, and bringing new ideas for creation of H.323 mobility standards solving complex problems. Definitely, we can make it!! Radhika R. Roy H.323 Ad Hoc Mobility Group AT&T + 1 732 420 1580 rrroy(a)att.com PS: Paul - Kindly put this email as another MTD for the upcoming meeting.

1 0

Re: Problem in Connect Message in H.2250 V3
by Lop Ng 18 Nov '99

18 Nov '99

unsubscibe -----Original Message----- From: Guntram Diehl [mailto:gdiehl@INNOVAPHONE.COM] Sent: Thursday, November 18, 1999 12:55 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Problem in Connect Message in H.2250 V3 Hi, I would say the table does not indicate a order of the IEs. The order of the IEs within the message is determined by the code value. Guntram > -----Original Message----- > From: Aseem Agarwal [mailto:aseem@trillium.com] > Sent: Wednesday, November 17, 1999 11:44 PM > To: h323implementors(a)imtc.org > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Problem in Connect Message in H.2250 V3 > > > 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 > -------------------------------------------------------------- > ----------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" > >

1 0

H.323 Mobility: post meeting
by Edgar Martinez [1] 18 Nov '99

18 Nov '99

Dear All, I have update MTD-03 Annex- H outline now MTD-03b as requested by the Ad-hoc group. For each section I have identify where the section and text came from. Where we stray from the annex H "Terms of Reference" it has been noted in the document e.g., to delete the part of "Scope". I have also added the change marks and a document history table to MTD-3b. All the documents have been place in: http://people.itu.int/~emartine/temp/SG16-mobility/ConfCall_Nov17-99/ You also can get access via http://people.itu.int/~emartine/ Regards, -- 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

unsubscribe
by wlp 18 Nov '99

18 Nov '99

unsubscribe

1 0

Re: Problem in Connect Message in H.2250 V3
by Guntram Diehl 18 Nov '99

18 Nov '99

Hi, I would say the table does not indicate a order of the IEs. The order of the IEs within the message is determined by the code value. Guntram > -----Original Message----- > From: Aseem Agarwal [mailto:aseem@trillium.com] > Sent: Wednesday, November 17, 1999 11:44 PM > To: h323implementors(a)imtc.org > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Problem in Connect Message in H.2250 V3 > > > 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 > -------------------------------------------------------------- > ----------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" > >

1 0