- sg16-avd - lists.packetizer.com

Re: Mob ad hoc group progress
by Guram Paul-LPG019 03 Apr '00

03 Apr '00

Mob group and Vineet Vineet is most probably right. If when discussing the intra-network scenario, it is seen that the H.323 inter-network scenario can also be specified at the same time, and that there is nothing extra special to consider, we shall state so and log it as such for the base-line text. MD00 has been reserved as the contribution list and allocation file for the MDs. Paul -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: 03 April 2000 02:30 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Paul, I think that we should look at both intra- and inter-network scenarios together. I don't see anything special in the intra-network scenario that would require us to look for its solution first. vineet

1 0

Re: [Robustness] H.225 & H.245 state info
by Maureen Stillman 03 Apr '00

03 Apr '00

Terry, thanks for compiling on this important state information for H-323. For those of us who are nit-picking could you give us a definition for the elements in the table? x o t new(???) n/a (blank), etc. I'm not really sure what they mean. The labels at the top of the table, why they are there also need some definition, although I think I know what they mean. A paragraph on the scope of the table would also clarify, for example, are conference calls included? Also, if you could take us thru one scenario in the table that has different elements in it, that would be helpful. I want to make sure I have the right interpretation of the table before we talk about it on Thursday at the teleconference. Thanks. -- maureen -----Original Message----- From: EXT Terry L Anderson [mailto:tla@LUCENT.COM] Sent: Friday, March 31, 2000 5:14 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [Robustness] H.225 & H.245 state info I have been working on collecting the call state information present in various H.323 network elements. The goal is to: 1. see what data is present 2. suggest what data must be re-established if a new element takes over (or an element recovers but has lost call state data) in order to allow the call to continue at various specified levels of recovery: - call can continue but billing data lost - call can continue with full billing data - etc. I have certainly not completed this study, but have collected a fairly complete set of call state data items and put them into a table indicating which element(s) they reside in. The plan is to choose a notation to indicate how vital each element is for various levels of recovery and which other element has the data that can be used to restore it in the new element. I will share this much at this time and perhaps we can begin a discussion about - completeness (what I have missed) - presentation (is there another format that could make the information more understandable) I am attaching it as a word document. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

2 1

Q12-14/16 Rapporteur meeting in Osaka
by Sakae OKUBO 03 Apr '00

03 Apr '00

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. M. Wada, KDD De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 3204 8194 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Sonusnet USA Tel: +1 732 972 2653 Fax: +1 732 972 6389 E-mail: dskran(a)sonusnet.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ---------------------------------------------------------- Subject: Notice of Q.12-14/16 Rapporteur Meeting in Osaka Date: 31 March 2000 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Osaka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 15 (Monday) - 19 (Friday) March 2000 starting at 9:00 on the first day closing at 18:00 on the final day 2. Venue ^^^^^^^^ Osaka International Convention Center 5-3-51 Nakanoshima, Kita-ku Osaka-shi, 530-0005 Tel: +81 6 4803 5555 Fax: +81 6 4803 5620 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Issue white papers for: * H.323 V4 * H.225.0 V4 * H.323 Annex J * H.323 Annex K * H.323 Annex L * H.323 Annex M.1 and M.2 * H.450.8 [may have been issued already] - Progress work for: * H.323 Annex N (QoS) * H.323 Annex H (Mobility) * H.323 Annex I (Error prone channels) * More robust operations * H.225.0 Annex G V2 * T.38-like protocol for modems & related H.323 signaling * H.450.x new recommendations * SS7 interworking 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Issue white papers for: * H.235 V2 * H.245 V7 * H.248 Annex F * H.248 Annex G * H.248 Annex H * H.248 Annex I * H.248 Annex J * H.248 Annex K * H.246 Annex E - Progress work for: * H.246 Annex D * H.248 V2 * other new items that may arise (e.g., new packages for H.248) 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 5 May (Friday) /// /// Distribution of the document: by 8 May (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 5 May (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Osaka, 15-19 May 2000 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (8 October or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0005_Osa directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring their laptop and 10BASE-T cord along. 6) The copying service is very limited and expensive at the meeting site. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0005_San/Information_ITU-T_Osaka.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 24 April: Ms. Noriko Hosokawa Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: nonko(a)giti.waseda.ac.jp Tel & Fax: +81 3 5286 9863 AND advise Rapporteurs of your attendance by e-mail: To: okubo(a)giti.or.jp, dskran(a)sonusnet.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Osaka meeting registration Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting together with the meeting registration. Special room rate is 12,600 Yen (single) or 18,900 Yen (twin room, single use) per night including breakfast, service charge, local tax and consumption taxes. The block reservation is held until 24 April. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, about 20,000 Yen meeting fee is collected by the secretariat (exact amount will be announced later). We are looking forward to meeting with you in Osaka. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0

Re: subscribe
by Sebestyen Istvan ICN M CS 27 03 Apr '00

03 Apr '00

Dale, any news about the status of the August/September SG16 Q.11-14 Rapp. Meeting? Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Skran, Dale[SMTP:DSkran@SONUSNET.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, April 03, 2000 3:00 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: subscribe > > dskran(a)sonusnet.com > > Dale Skran >

1 0

NetMeeting & T.120
by Stevie Gray 03 Apr '00

03 Apr '00

Hi, I am currently implementing a program which essentially passes T.120 data from one endpoint to another. I am doing this over H.245 using dynamic ports. The program basically joins the two T.120 bi-directional channels together via Winsock and lets the two endpoints get on with it. What I have discovered so far is that NetMeeting only seems to initiate a T.120 conference if it originated the Q.931 call. I have a scenario where I initiate the calls to each of the NetMeeting endpoints and join them together. However, in this scenario NetMeeting does not initiate the T.120 conference, I'm assuming they are both waiting for the Q.931 call initiator (i.e. me) to initiate the T.120 conference. I have tried various combinations of the T120SetupProcedure flag in the OLC Ack but to no avail. Is this a limitation of NetMeeting or is there a way to get this working. Here are a list of scenarios I have working NetMeeting --> MyProg --> NetMeeting NetMeeting --> MYProg <-- NetMeeting The one I can't get working is NetMeeting <-- MyProg --> NetMeeting I am using NetMeeting 3.01. Regards, Stevie. ========================================================== Stevie Gray sgray(a)ridgeway-sys.com Senior Software Engineer Ridgeway Systems & Software www.ridgeway-sys.com Tel +441189381124 Fax +441189354444 ==========================================================

1 0

Use of IRR by Gateways
by Mohamed Mustafa 03 Apr '00

03 Apr '00

Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed

5 11

[Fwd: Force remote to start H.245 session?]
by Chris Wayman Purvis 03 Apr '00

03 Apr '00

Reply intended for the list unintentionally sent to Paul personally, so here you all are! Chris Chris Wayman Purvis wrote: > > Paul, > > First of all, sorry for the fact that this seems to be a week-old mail I'm > finally responding to... > > I may have misunderstood, but I don't understand why this is necessary. If > both endpoints have expressed willingness to use tunnelled H.245, why can an > endpoint not simply start sending H.245 messages (of COURSE starting with TCS, > and potentially tunnelled in purpose-built FACILITY messages) when it wishes to > start a tunnelled H.245 session? I would have thought that would be a pretty > clear indication of intent to start a tunnelled H.245 session! > > FACILITY/reason=startH245 is required for separate H.245 connections because an > endpoint may not know an address at its interlocutor to use to initiate an > H.245 connection. This problem doesn't exist in tunnelled H.245, so I see no > necessity for the extra interpretation! > > We may want some extra text specifying behaviour at the start of an H.245 > session, to ensure that the destination of the initial tunnelled H.245 message > actually does something constructive (sends a TCS) rather than non-constructive > (merely Acking the TCS it's been sent and not advancing anything useful). > > Regards, > Chris > > Paul Long wrote: > > > > How does an EP force the remote EP to bring up a tunneled H.245 session? > > > > Consider this call scenario: Fast Connect was enough to establish the > > desired media between two EPs. Both support H.245 Tunneling but neither has > > initiated an H.245 session because neither had any need to. One EP now needs > > to use H.245 procedures. It doesn't matter, but reasons include DTMF > > transmission via UII and requesting a different video format or different > > audio bit-rate via RequestMode. That EP can initiate its own H.245 > > procedures, e.g., TCS and MSD, but how does it force the other EP to bring > > up an H.245 session? > > > > H.323 and H.225.0 say that Facility/reason=startH245 is just for switching > > from Fast Connect or H.245 Tunneling to a separate H.245 channel, not for > > initiating an H.245 session via tunneling. Is it just hoped that when an EP > > sees that the other EP is bringing up an H.245 session, it will do the same? > > Seems like a pretty weak assumption. It would be nice if > > Facility/reason=startH245 without an h245Address meant to bring up an H.245 > > session on whatever transport is already established, i.e., tunneled or > > separate channel. Seems like we could do this in v4 because startH245 > > without an h245Address currently has no meaning. Whadya think? -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

subscribe
by Skran, Dale 03 Apr '00

03 Apr '00

dskran(a)sonusnet.com Dale Skran

1 0

Re: Mob ad hoc group progress
by Kumar, Vineet 02 Apr '00

02 Apr '00

Paul, I think that we should look at both intra- and inter-network scenarios together. I don't see anything special in the intra-network scenario that would require us to look for its solution first. vineet -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Sunday, April 02, 2000 12:52 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Mob ad hoc group progress Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

Re: Mob ad hoc group progress
by Guram Paul-LPG019 02 Apr '00

02 Apr '00

Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

[Robustness] telecon -- April 6 9AM EST USA
by Maureen Stillman 02 Apr '00

02 Apr '00

The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. Please send me e-mail at maureen.stillman(a)nokia.com if you plan to attend (some have sent e-mail already). The number to call is: (613)688-2795 the passcode is 8689# You must enter the pound sign after the passcode. The agenda is: * Terry Anderson will provide H.225 and H.245 state machines for us to review. * Randy Stewart and Qiaobing Xie of Motorola will join us to discuss SCTP and DDP and answer questions. * Discuss the SDL for the robustness procedure produced by Sasha Ruditsky of Radvision (attached). This SDL is for the Geneva SG-16 document from the February 2000 meeting, document TD87 from WP2. SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt -- maureen <<RobustnessSDL.ZIP>> Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks 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

3 2

Missing FastConnectRefused flag in PROGRESS message
by <Karl Klaghofer> 02 Apr '00

02 Apr '00

In the Geneva 2/2000 meeting, we introduced the fastConnectRefused flag into some H.225.0v3 (Imple Guide) and v4 messages. We forgot to put this new field into PROGRESS as well (especially required for GWY interworking). Otherwise, it is difficult to comply with the following statement: ".....fastConnectRefused - A called endpoint should return this element in any message up to and including the Connect message when establishing a call to indicate that it refuses the Fast Connect procedure. ....." Note: The original contribution D.459 from Orit proposed to add this flag to the H323-UU-PDU structure, which would have enabled the flag for PROGRESS as well as for any other message. I guess we changed this in order to only put the flag to the messages where it makes sense (which should be backwards messages) and missed the PROGRESS. I consider this an an error and propose that the editor should add the missing field to PROGRESS to the next updated draft of H.225.0v4 (I assume that no APC is required for Osaka for this ?). Is there a way to correct this also for H.323/H.225.0v3 ? Thanks and Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 31 Mar '00

31 Mar '00

Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Friday, March 31, 2000 9:47 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Mob ad hoc group progress Hi Mob group, See the following High Level Progress report. Please inform group of any important aspect that I may have missed. 1. A conference call was held on 23 March 2000 with representatives from: AT&T, Alcatel, Ericsson, Intel, Lucent, Motorola, Nokia, Siemens. 2. The "All H.323 Scenario" was chosen to be studied and specified (out of the many other scenarios presented). When this work has been completed then the other scenarios will be specified. For the chosen scenario, mobility related contributions are now solicited for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release Also it was decided to progress and add to the architectural work as required. These contributions will enhance/form the base-line Annex H text for paragraphs 6, 7 and 8. 3. Next conference call is scheduled for 17 April, again at 8 a.m. PST. 4. It is now a matter of real concern that nothing much has moved in the Annex I (access and lower layer work). Any contributions to kick start this Annex would be appreciated. 5. For H.246 Annex E, it is important that the companies look at the MAP mapping for GSM and ANSI 41 contained in this annex.... to make sure that any errors are identified before the Osaka meeting. Paul

1 0

[Fwd: Summary of Issues Raised On the List]
by Glen Freundlich 31 Mar '00

31 Mar '00

For those interested in H.248, but not subscribed to the Megaco list, I'm forwarding the summary of issues that Tom Taylor distributed to the Megaco list (and to which he referred in his "Megaco Meeting Summary" email). -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Mob ad hoc group progress
by Guram Paul-LPG019 31 Mar '00

31 Mar '00

Hi Mob group, See the following High Level Progress report. Please inform group of any important aspect that I may have missed. 1. A conference call was held on 23 March 2000 with representatives from: AT&T, Alcatel, Ericsson, Intel, Lucent, Motorola, Nokia, Siemens. 2. The "All H.323 Scenario" was chosen to be studied and specified (out of the many other scenarios presented). When this work has been completed then the other scenarios will be specified. For the chosen scenario, mobility related contributions are now solicited for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release Also it was decided to progress and add to the architectural work as required. These contributions will enhance/form the base-line Annex H text for paragraphs 6, 7 and 8. 3. Next conference call is scheduled for 17 April, again at 8 a.m. PST. 4. It is now a matter of real concern that nothing much has moved in the Annex I (access and lower layer work). Any contributions to kick start this Annex would be appreciated. 5. For H.246 Annex E, it is important that the companies look at the MAP mapping for GSM and ANSI 41 contained in this annex.... to make sure that any errors are identified before the Osaka meeting. Paul

1 0

R:Megaco Meeting Summary
by Tosco Federico 31 Mar '00

31 Mar '00

Tom, Thank you for the information. I take the occasion to thank you again for your very important contribution to the cooperation between IETF and ITU-T. Best regards. Federico > ---------- > Da: Tom-PT Taylor[SMTP:taylor@NORTELNETWORKS.COM] > Risposta a: Mailing list for parties associated with ITU-T Study Group > 16 > Inviato: venerdì 31 marzo 2000 2.37 > A: ITU-SG16(a)MAILBAG.INTEL.COM > Oggetto: Megaco Meeting Summary > > Apologies to Alison -- I don't have her E-mail address. > > Megaco met for one session on Thursday morning. The agenda included a > review of status, a discussion of the future of work on development of > Megaco/H.248, review of work items in progress, and review of potential > new work items. The main points out of the status review were that we > must close on Last Call items within the next week to make the base > protocol documentation available for the April IESG meeting, and that only > MIB development remains out of the original charter work items. > > Discussion of how the IETF wishes to relate to future development of the > Megaco/H.248 protocol brought out the following points: > > -- painful as it has been, we wish to remain fully involved in > development of the base protocol at every stage > -- leaving that aside, it is desirable for interoperability that package > development be coordinated to minimize unnecessary proliferation > > -- there was a strong consensus that in future work, ITU-T determination > of jointly developed documents should truly indicate that these documents > are technically stable, with rigorous change control applied thereafter to > ensure that changes are restricted to clarifications and error > corrections. > > The consensus was therefore that Megaco should continue to operate, though > perhaps at a lower level of activity. It will be necessary to draw up a > new charter for the Working Group, and the Chair has been tasked with > drawing up a process document to form the basis of a permanent agreement > with the ITU groups with whom we cooperate. (This document will be > offered to the list for discussion before being passed to the AD.) It was > noted in later discussion that within the present organization of the > ITU-T we will need to work with Study Group 11 as well as SG 16. > > A first engineer-to-engineer interoperability event is being planned, > tentatively set for August, somewhere in North America. Nortel will set > up an implementor's E-mail list and web site. We welcome any TIPHON > initiative to develop an H.248 PICS. > > Notes on existing work items: > -- the suggestion from discussion was that each package (including those > currently in H.248 Annex E) will be published as a separate RFC. Megaco- > or ITU-initiated packages will typically be standards-track, but this > decision can be made on a per-package basis. > > -- discussion of the IPPhone profile brought out the following points: > Megaco will not initiate the development of profiles, but will typically > become involved as technical consultants in the final stages of turning > mature documents into Informational RFCs. The IPPhone draft itself will > probably be recycled once more in response to list comments, then sent to > WG Last Call, around mid-April. > > -- the NAS package work continues to be a matter both of controversy and > of an apparently low level of general interest. It will be fleshed out to > meet the published Megaco requirements. We are looking to WG Last Call in > mid- to late April. > > -- MIB work has begun to take off. A recycled draft with a substantial > amount of content should be available within the next couple of weeks. We > are looking toward WG Last Call toward the end of the month. It was noted > that each package will probably engender a corresponding MIB. > > A number of potential new work areas were reviewed. These will be > discussed on the list, with a view to identifying specific WG work items > over the next month. > > -- ISDN-related work should be coordinated with Study Group 11 > -- additional packages proposed in draft-brown-supplpkgs-00.txt will be > generic in intent, although in detail some aspects may be specific to > North America. The work should be coordinated with Study Group 16 in > particular, and possibly also Study Group 11. > > Work on adding ATM capability to SDP is in progress. The work is being > taken to MMUSIC (who are prepared to supervise it -- there was a question > of whether they would refer it back to Megaco.) > > A final presentation on the potential application of H.248 to the control > of UMTS terminals included a request for help in development of the > implied call flows. An I-D will be submitted and can be discussed on the > list. > > As a personal note, I cannot guarantee E-mail connectivity over the next > week -- my modem does not seem to agree with most Australian telephone > circuits. I will be back in full operation April 8. > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > >

1 0

Megaco Meeting Summary
by Tom-PT Taylor 30 Mar '00

30 Mar '00

Apologies to Alison -- I don't have her E-mail address. Megaco met for one session on Thursday morning. The agenda included a review of status, a discussion of the future of work on development of Megaco/H.248, review of work items in progress, and review of potential new work items. The main points out of the status review were that we must close on Last Call items within the next week to make the base protocol documentation available for the April IESG meeting, and that only MIB development remains out of the original charter work items. Discussion of how the IETF wishes to relate to future development of the Megaco/H.248 protocol brought out the following points: -- painful as it has been, we wish to remain fully involved in development of the base protocol at every stage -- leaving that aside, it is desirable for interoperability that package development be coordinated to minimize unnecessary proliferation -- there was a strong consensus that in future work, ITU-T determination of jointly developed documents should truly indicate that these documents are technically stable, with rigorous change control applied thereafter to ensure that changes are restricted to clarifications and error corrections. The consensus was therefore that Megaco should continue to operate, though perhaps at a lower level of activity. It will be necessary to draw up a new charter for the Working Group, and the Chair has been tasked with drawing up a process document to form the basis of a permanent agreement with the ITU groups with whom we cooperate. (This document will be offered to the list for discussion before being passed to the AD.) It was noted in later discussion that within the present organization of the ITU-T we will need to work with Study Group 11 as well as SG 16. A first engineer-to-engineer interoperability event is being planned, tentatively set for August, somewhere in North America. Nortel will set up an implementor's E-mail list and web site. We welcome any TIPHON initiative to develop an H.248 PICS. Notes on existing work items: -- the suggestion from discussion was that each package (including those currently in H.248 Annex E) will be published as a separate RFC. Megaco- or ITU-initiated packages will typically be standards-track, but this decision can be made on a per-package basis. -- discussion of the IPPhone profile brought out the following points: Megaco will not initiate the development of profiles, but will typically become involved as technical consultants in the final stages of turning mature documents into Informational RFCs. The IPPhone draft itself will probably be recycled once more in response to list comments, then sent to WG Last Call, around mid-April. -- the NAS package work continues to be a matter both of controversy and of an apparently low level of general interest. It will be fleshed out to meet the published Megaco requirements. We are looking to WG Last Call in mid- to late April. -- MIB work has begun to take off. A recycled draft with a substantial amount of content should be available within the next couple of weeks. We are looking toward WG Last Call toward the end of the month. It was noted that each package will probably engender a corresponding MIB. A number of potential new work areas were reviewed. These will be discussed on the list, with a view to identifying specific WG work items over the next month. -- ISDN-related work should be coordinated with Study Group 11 -- additional packages proposed in draft-brown-supplpkgs-00.txt will be generic in intent, although in detail some aspects may be specific to North America. The work should be coordinated with Study Group 16 in particular, and possibly also Study Group 11. Work on adding ATM capability to SDP is in progress. The work is being taken to MMUSIC (who are prepared to supervise it -- there was a question of whether they would refer it back to Megaco.) A final presentation on the potential application of H.248 to the control of UMTS terminals included a request for help in development of the implied call flows. An I-D will be submitted and can be discussed on the list. As a personal note, I cannot guarantee E-mail connectivity over the next week -- my modem does not seem to agree with most Australian telephone circuits. I will be back in full operation April 8. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Inconsistencies in the H.225.0/Q.931 text??
by Frank Derks 30 Mar '00

30 Mar '00

When reading through the "Q.931 part" of H.225.0, the text for the "Q.931" messages specifies "who" is supposed to send and act on the messages. Strangely enough, these seem to be somewhat inconsisten with each other. From the list below (extracted from H.225.0), some messages are sent by the user (???), some messages are sent by (any???) H.323 entity, some messages are sent by a specific H.323 entity and some messages are sent by "something" unspecified. Alerting: "This message may be sent by the calling user..." Call Proceeding: "This message may be sent by the called user..." Connect: "This message shall be sent by the called entity..." Information: "This message may be sent by an H.323 entity..." Progress: "This message may be sent by an H.323 gateway..." Release Complete: "This message shall be sent by a terminal..." Setup: "This message shall be sent by a calling H.323 entity..." Setup Acknowledge: "This message may be sent by an H.323 entity..." Status: .... Status Inquiry: ... First of all, it is not correct to state that any of the messages are sent by the user. Secondly, according to the definition in H.323, an "H.323 Entity" is: "Any H.323 component, including Terminals, Gateways, Gatekeepers, MCs, MPs, and MCUs". From the definition for Endpoint it follows that only a Terminal, a Gateway an an MCU can call and be called. This seems to somewhat contradict the definition of which messages can be sent by by which "components". I.e. this seems to restrict the components that are allowed to send H.225.0/Q.931 messages to Endpoints. Thirdly, a Release Complete message can only be sent by a terminal. I can not imagine that this is correct. I would imagine that Gateways, MCUs and even Gatekeepers are also allowed to send this message. Is there anyone who can shed some light on the above? Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

Re: [Mobility]:Ideas from phone conference on scenarios
by Roy, Radhika R, ALARC 29 Mar '00

29 Mar '00

Hi, Steve: You are right that the situation will look like scenarios you have proposed in this email. We would appreciate any Ericsoon's proposals regarding this. It has been long overdue to have something from Ericsson's. We also discussed this in the SG 16 in Feb'00 and got assurances from Ericsson they would bring some contributions. Yet, it is NOT too late. (by the way AT&T contributions also provided many of those scenarios). Please note that a domain consists of a single or more zones. A zone may have many networks (e.g., IP network addresses). A mobile entity may have its home and foreign network in its home zone as well. >From the conference call, it was clear that we may focus our discussion with a very simple case first. If anyone else has any thoughts, please, like Steve, let us know. We appreciate Steve's inputs. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group -----Original Message----- From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM] Sent: Thursday, March 23, 2000 3:01 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Mobility]:Ideas from phone conference on scenarios Hi All, After the phone conference today, I think that we need to cover the following for the "All-H.323 Scenario). A(home) -> B(home), A & B from same domain A(home) -> B(home), A & B from different domain A(home) -> B(roaming), A & B from same domain A(home) -> B(roaming), A & B from different domain A(roaming) -> B(home), A & B from same domain A(roaming) -> B(home), A & B from different domain A(roaming) -> B(roaming), A & B from same domain A(roaming) -> B(roaming), A & B from different domain This could be represented as follows in the document. xx.1 Registraion xx.1.1 Registration from Home domain xx.1.2 Registration from romaing domain xx.2 Location Update xx.2.1 xx.3 Call establishment xx.3.1 Call originating from terminal at home domain xx.3.2 Call originating from terminal at roaming domain xx.3.3 Call terminating to terminal at home domain xx.3.4 Call terminating to terminal at roaming domain xx.3.5 Call to PSTN from terminal at home domain xx.3.6 Call to PSTN from terminal at roaming domain. Well, this is what I was trying to say in the phone conference. Regards, ..//Steve

1 0

Re: Use of IRR by Gateways
by Francois Audet 29 Mar '00

29 Mar '00

> BTW, this is an example of why it is important for > contributors and editors > to avoid using the passive tense in Recommendations. They > should also be > conscious of the verbs they use, e.g., "shall" is the ITU's > only normative > verb, "is" is not. It depends what the definition of "is" is ;^)

1 0

Initial CFP: IP Telecom Services Workshop 2000
by IPTS 2000 29 Mar '00

29 Mar '00

[Please accept our apologies for multiple copies of this call.] ------------- PRELIMINARY CALL FOR PAPERS --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 submission deadline: June 16, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. The IPTS 2000 Program Committee invites submission of papers on substantial, original and previously unpublished research in IP telecom services, including, but not limited to: - service architectures (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC) - service creation environments - protocols, standards and interoperability (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.) - service programming languages - service management - billing, fault tolerance, monitoring - novel services We welcome papers describing original research; position papers describing research interests in the field, work in progress, or future directions of research; project or system descriptions. IMPORTANT DATES June 16, 2000 Submission deadline July 21, 2000 Notification of acceptance August 25, 2000 Final version of papers September 11, 2000 IPTS 2000 PAPER SUBMISSIONS Papers must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. They must be written in English, not exceeding 6 pages including figures, tables and references in 10-12 point font on 8.5x11-inch (US letter) paper. The first page must include an abstract of up to 200 words, keywords, and email address of the corresponding author. All papers must be submitted electronically unless specifically approved by the Workshop Co-Chairs. Submissions in PostScript or PDF format should be sent to mailto:ipts2000@research.att.com. Authors of accepted papers are expected to present their contribution at the workshop. The proceedings will be published in hardcopy and on the web. REVIEW PROCEDURE All submissions will be subject to academic peer review by the IPTS 2000 Program Committee under the chairmanship of the Workshop Co-Chairs. Each paper will receive three written reviews, and reviews will be returned to the authors. The Workshop Co-Chairs have final authority over the review process and all decisions relating to acceptance of papers. Review criteria include originality of ideas, technical soundness, significance of results, and quality of presentation. CONFERENCE VENUE AND RELATED EVENTS IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Details about Fall 2000 VON can be found at http://pulver.com. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com) WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000

1 0

New web site Packetizer.com
by Paul E. Jones 26 Mar '00

26 Mar '00

Folks, Paul Long and I have combined the H.323 information from our personal web sites at a new domain, http://www.packetizer.com/. This not-for-profit site is devoted to packet-switched conversational protocols, serving the end-user, engineer, and executive, although the focus is on the engineer. For obvious reasons (if you know anything at all about us), we will initially have much more information on H.323, but we intend to gather information on other protocols including SIP, MGCP, and H.248, if only as links to other online resources. Contributors Wanted This is a cooperative effort. Besides announcing the site, this email invites _your_ input. If you have any information regarding these or other packet-switched conversational protocols that you can share and would be of interest to others, please forward it to us so that we can make it public on this web site. We will attribute the work to you unless you request us not to. We provide the web space, bandwidth, organization, indexing, and focus; you provide information that is in the public domain or whose copyright you or your organization own and does not contain trade secrets. We don't want to get sued; you don't want to get fired. :-) Your contribution can be as simple as a single tip for solving a particularly nasty implementation issue or clarification of some aspect of a standard or as involved as a complete tutorial on a particular protocol. See the list below for ideas. Conversely, if there is something that you would like to see, please let us know. Maybe we can find someone to write something up or maybe we can maintain a "wish list" on the site for future contributions. Contributions Here is a list of the types of contributions for which we are looking. It is likely that you already have things like this lying around somewhere that you had to put together for your own use or use within your organization. Let's share! - Summary - Primer - Tutorial - Implementation guide - Implementation notes - Cheat sheet - Glossary - Protocol comparisons - Links to other online resources - Description of how to participate, e.g., how to subscribe to the email reflectors and location of reflector archives - List of standards organization(s) working in an area, with contact and membership info - Diagrams - FAQ - Upcoming event sponsored by your company or institution, e.g., seminar or panel discussion Best Regards, Paul E. Jones Editor of the H.323 Recommendation

1 0

[Mobility]:Ideas from phone conference on scenarios
by Stephen Terrill 23 Mar '00

23 Mar '00

Hi All, After the phone conference today, I think that we need to cover the following for the "All-H.323 Scenario). A(home) -> B(home), A & B from same domain A(home) -> B(home), A & B from different domain A(home) -> B(roaming), A & B from same domain A(home) -> B(roaming), A & B from different domain A(roaming) -> B(home), A & B from same domain A(roaming) -> B(home), A & B from different domain A(roaming) -> B(roaming), A & B from same domain A(roaming) -> B(roaming), A & B from different domain This could be represented as follows in the document. xx.1 Registraion xx.1.1 Registration from Home domain xx.1.2 Registration from romaing domain xx.2 Location Update xx.2.1 xx.3 Call establishment xx.3.1 Call originating from terminal at home domain xx.3.2 Call originating from terminal at roaming domain xx.3.3 Call terminating to terminal at home domain xx.3.4 Call terminating to terminal at roaming domain xx.3.5 Call to PSTN from terminal at home domain xx.3.6 Call to PSTN from terminal at roaming domain. Well, this is what I was trying to say in the phone conference. Regards, ..//Steve

1 0

AW: Doubt about CallLinkage structure in IRR message
by <Karl Klaghofer> 23 Mar '00

23 Mar '00

I agree with Aseem. D.392 from Geneva had this new field correctly qualified as OPTIONAL in any message it appears (including IRR). Besides H.323v3 Impl Guide, this error slipped in during editing phase also to H.225.0v4 and needs to be corrected here as well. Regards, Karl Klaghofer Siemens > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [SMTP:paul.jones@ties.itu.int] > Gesendet am: Mittwoch, 22. März 2000 03:23 > An: Aseem Agarwal > Cc: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com; Klaghofer > Karl ICN SIB NL D1 > Betreff: Re: Doubt about CallLinkage structure in IRR message > > Aseem, > > That is definitely a typographical error-- the callLinkage field should > definitely contain the OPTIONAL modifier. I will make a correction to > this > and make mention of it at the next Question 13/16 meeting. > > Thanks for pointing that out. > > Best Regards, > Paul > > ----- Original Message ----- > From: "Aseem Agarwal" <aseem(a)trillium.com> > To: <paul.jones(a)ties.itu.int> > Cc: <h323implementors(a)imtc.org> > Sent: Tuesday, March 21, 2000 7:15 PM > Subject: Doubt about CallLinkage structure in IRR message > > > > Hi Paul, > > Implementers' Guide for H.225V3 (H323V3_IG_0002.zip) has added > > CallLinkage structure to perCallInfo in IRR as a mandatory IE. > > > > Since the Call Linkage is an optional feature, it should be an > > optional IE. Is this a mistake or there is a reason behind it? > > Kindly clarify. > > > > thanks, > > aseem(a)trillium.com > > > > > > -------------------------------------------------------------------------- > - > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > -------------------------------------------------------------------------- > -

2 1

FW: [H.323 Mob] Mar 23: Conference Bridge Info
by Jaakko Sundquist 23 Mar '00

23 Mar '00

Hello all, Mr. Thibault called me asking for the conference bridge number, so I'm sending it to the list. I hope Mr. Thibault gets this in time (also I did not find Mr. Thibaults email-address, so I'm sending this to the whole list). ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ -----Original Message----- From: EXT Senthil Sengodan [mailto:senthil.sengodan@NOKIA.COM] Sent: 21. March 2000 4:48 To: ITU-SG16(a)mailbag.cps.intel.com Subject: [H.323 Mob] Mar 23: Conference Bridge Info Folks, The following is the conference call bridge details for the upcoming H.323 mobility ad-hoc group call. As has been done for the previous calls, the conference bridge is hosted/sponsored by IMTC to help expedite the H.323 mobility work. Date: March 23, 2000 Time: 8:00 AM to 10:30 AM (Pacific Standard Time (PST)) Conference call Bridge # +1 (916)-356-9200 Reservation Number = 1-297557 Passcode = 8291124 Note: Once you call into the conference call bridge number, first enter the reservation number first digit and then wait for the voice prompt to enter the passcode and then enter the complete passcode in order to join the conference call. - Senthil -----Original Message----- From: EXT Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Sunday, March 19, 2000 3:53 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Mob ah hoc group meeting on 23 March Hi mob members Please note that there is a conf call for 23 March at 8 a.m. Pacific Standard Time, 4 p.m. UK time. Can Senthil Sengodan (Nokia) please arrange for the conference bridge and supply details for the dialling number etc. The agenda is as indicated before: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H: MD011 (Nokia) MD012 (AT&T) MD013 (Intel) 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call I will put the contributions MD011 (from Jaakko Sundquist), MD012 (from Radhika Roy), and MD013 (from Vineet Kumar) onto the server tomorrow. Paul

1 0