- sg16-avd - lists.packetizer.com

Re: Mob ad hoc group progress
by Jaakko Sundquist 06 Apr '00

06 Apr '00

Hi all, Comments to Radhika's posting below... Hi, Everyone: We are again not in sink what is going on with respect to progress of our work. Let me try again. That is just what I was trying to say... We have talked about Nokia's contribution MD-011. We have taught that this provides a reference to start with. In that contribution, we have Figure 1: Intra-zone all H.323 scenario. We have decided that we will go one step at a time. First of all the scenario is called all-H.323 scenario. The … [View More]figures just try to explain what kind of call models that scenario involves. What we have decided is to go one scenario at a time (not one "call model" at a time). Furthermore, it was evident in the last teleconference that the cases illustrated in the figures were not adequate and they need to be enhanced. Now what does this Figure 1 provides us? We are NOT sure unless we explain in detail what this scenario means to us. We cannot go to the next step unless we analyze what the scenario of Figure 1 provides us. It may or may not provide new insights from H.323 mobility point of view, but it is our starting point. We have to complete it first before we go for the next step. In this simple case, a mobile entity will move from its home network to a foreign network. This also requires mobility management: Change in network point of attachment and its possible impact in H.323 system. This is just what I mean. What do you mean by the above text? First of all I don't know what you mean by home and foreign network. Are you saying that inside one zone there are multiple networks (so that moving from the home network to a visited network is possible while all the time being located inside the same zone)? You are right in saying that we need to analyze this call model also, but first we need to identify the different cases for the user's location, i.e. both users at home domain, user-A at home domain & user-B in a visited domain, etc. Related to the above, we have already defined the terms Home Administrative Domain, Visited Administrative Domain and Serving Administrative Domain in the draft H.323 Annex H. I think that these definitions are very good (thanks to Milo, you see that we do agree on some things once in a while ;-) and they clearly bind the subscription of a user (or a subscriber) to a Domain. My opinion is that this means that the Administrative Domains are the areas that divide the H.323 system into home and visited areas from the point of view of the user. In other words, I wouldn't necessarily even define terms, such as, Home Zone or Home Gatekeeper, because the above definitions already bind the home of a user to the whole domain, not a particular zone. If we want to define the term Home Zone, I think it should mean ANY zone inside the Home Administrative Domain, similarly a definition for the Home Gatekeeper could be made. Based on the above, we can assume that when a user is in his/her Home Administrative Domain, the HLF that contains his/her information is also inside that Domain and inter-domain communications are not needed for the Mobility Management of that user. Similarly, if the user is in a Visited Administrative Domain, inter-domain communications are needed for the Serving Administrative Domain to contact the user's HLF. This will also lead to different location management cases for e.g. the intra-zone all-H.323 call model. Once we complete Figure 1, we will go for the next one: Figure 2 Inter-Zone all H.323 scenario. Of course, this is a complicated one to provide better scenario for mobility management: Change in network point attachment + Change in zone (logical) point of attachment as well. I think that this is a good way for an individual to work, but personally I would like to see contributions that address more of these call models at a time. We can, of course, deal with the contributions in the order that Radhika is proposing, I have nothing against that. A side note: We have defined VLF and HLF. VLF may be assumed to be co-located within the GK. But let people explain the interactions including VLF and HLF the way they prefer in their contributions. The contributions themselves will justify how VLF and HLF should perform their functions. Let us not mandate anything beforehand unless things are explained in the contributions. One thing I would like to ask the ad hoc group members, is that should we assume at this point that the VLF is co-located with the gatekeeper (as a "composite network element" illustrated in Figure 3 of the draft H.323 Annex H). I think this could be a good assumption in the first version of Annex H, because it seems that most of us are thinking that way already. It would only mean that we wouldn't have to specify anything for the reference point E, but leave it open in the first version of the annex, similarly as was done with reference point B in the H.225.0 Annex G. Other composite network elements could also be identified for the first version of the annex. I think that this kind of grouping could conciderably simplify our work for the first version by reducing the number of interfaces that we need to specify. We should probably encourage contributions proposing the composite network elements and perhaps discuss these contributions in a teleconference (maybe not the next, but the one after that). - Jaakko [View Less]

1 0

Third party initiated pause and rerouting, share with voice, etc.
by Francois Audet 05 Apr '00

05 Apr '00

Hi all, I spotted a number of issues concerning third party initiated pause and rerouting, H.323 Annex F, the new "share with voice" capability in H.323v4, and of course, everybody's favorite: fast start. * How do we do third party inititated pause and re-routing for a call initiated with fast start for a non-Annex F endpoint? * Reading H.323v4 suggest that the way to do this is sending the null Terminal Capability Set in a tunnelled H.245 message, or alternatively in a newly-… [View More]

1 0

Re: Your Business Achievements
by bilco90＠VENTURE.CO.JP 05 Apr '00

05 Apr '00

1 0

Re: Mob ad hoc group progress
by Jaakko Sundquist 05 Apr '00

05 Apr '00

Hi all, Once again there seems to be quite a lot of confusion about the terms we are using. First of all, we did not make it altogether clear in the last teleconference, what is meant by a scenario. My contribution on the issue tried to group both the "call scenarios" and the "location management scenarios" into one set of scenarios. We did notice during the teleconference that this was not an adequate approach and now some of the problems occuring in this email discussion reflect that. For … [View More]example, when Radhika is talking about starting with the intra-zone scenario, I'm not quite sure what he is meaning. I understand that the "call scenario" he is talking about, is the one in which both terminals are registered to the same gatekeeper. However, this "call scenario" in itself does not really bring anything new to H.323 unless there is something that we need to address with the "location management scenarios". Now, while the "call scenario" does indeed fall into the category of intra-zone communications, the "location management scenario" for finding the address of the B-subscriber of the call might not, i.e. the VLF and HLF that need to be contacted may not be located in the same zone or even domain. Furthermore, we haven't even decided that the VLF and HLF should be a part of any zone. I know that most of us actually think that the VLF is always located with the gatekeeper, but so far we haven't made that decision and certainly we haven't coupled the HLF functionality always with the gatekeeper. Thus it is quite unclear what is meant by intra-zone "location management scenarios" and I would suggest that we do not even try to define this term. Instead intra vs inter domain "location management scenarios" make much more sence. (Note that I'm using the terms "call scenario" and "location management scenario" quite freely here. If we want to use such terms, they definitely must be clearly defined.) Also, I would like to point out that talking about intra-zone, inter-zone, etc. scenarios, is actually not what was originally meant by a scenario. The idea to introduce scenarios into the H.323 Mobility work came from Tiphon, where 5 different scenarios are identified. These scenarios do not take into account, whether the call (or other connection) takes place inside one zone (intra-zone), between two zones (inter-zone) or between domains (inter-domain). The scenarios in Tiphon simply state which network types are involved in the connection, e.g. Tiphon scenario 1 is the VoIP-to-SCN scenario, Tiphon scenario 2 is the SCN-to-VoIP scenario, etc. These were the kind of scenarios I thought we were trying to identify in the last teleconference. Of cource, each of this kind of scenarios may involve calls that are intra-zone, inter-zone or inter-domain calls, but we shouldn't call (no pun intended) these different call models as scenarios. We have now chosen the all-H.323 scenario as the first one to examine (although we didn't even know what it means). In my mind this means that: * We only examine call cases, in which no gateways are included. * We examine gatekeeper discovery, registration and location updating cases, in which the user is accessing the H.323 system either in his/her home network (e.g. domain) or a visited network (e.g. domain). * We examine call establishment and call release cases, in which the A-subscriber is either in his/her home network (domain) or in a visited network (domain). * We examine call establishment and call release cases, in which the B-subscriber is either in his/her home network (domain) or in a visited network (domain). Note that the call can be intra-zone, inter-zone or inter-domain irrespective of whether the B-subscriber is in home or visited network. * We examine mid-call scenarios (e.g. some supplementary services), in which the user (either A- or B-subscriber) is either in his/her home network or in a visited network. * In the context of H.323 Annex H we do not address the inteworking functionalities (IWFs) between the HLF/VLF/AuF and some non-H.323 network, unless some other document (such as H.246 Annex E) proposes additions to H.323 Annex H. (Note that, when we start work on some other scenarios in the future, we probably will have to take the IWFs into account.) Other issues that need to be addressed are at least the definitions for the home/visited network/domain/zone/gatekeeper, because it seems to me that some members are already using some of these terms in ways that already point to certain solutions, on which we have not yet agreed. I will try to work out a suitable contribution for the next teleconference to clarify these issues properly. If you have some comments to this mail, please respond. I know that this is a long posting with quite a lot of issues in it and I'm sure that I haven't explained myself too clearly in all parts of it, so please ask. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ -----Original Message----- From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 04. April 2000 15:31 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Paul: Thanks for clarifications. In the last conf call, we even cannot complete the simple intra-zone (intra-network, inter-network) scenarios first. You are right that we should concentrate on the scenarios (Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction, Call release). Definitely, we can go further: Inter-Zone (intra-domain) scenarios as well if we can agree on the first one. AT&T contributions already contain many of those aspects. Hope to bring new contributions explaining further in both scenarios. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Sunday, April 02, 2000 3: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 > [View Less]

1 0

Re: Force remote to start H.245 session?
by Paul Long 04 Apr '00

04 Apr '00

Chris, I think you see my point, then. Now that I think about it, an EP _is_ required to at least send its TCS, if it has not already, if it receives an H.245 request message. Specifically, it cannot send the TCSAck until it has sent its own TCS, according to the following: 8.2/H.323v3: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent." And then there's the following. I think … [View More]it means that if an EP receives TCS without already having sent TCS itself, it shall do so now. Is that your understanding? 8.2/H.323v3: "An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure." So if an EP initiates H.245 procedures, the remote is forced to also perform H.245 procedures. Okay, that's what I was looking for. Maybe it just means that it has to perform the cap exchange. You know, both sides don't really need to initiate the MSD. It's enough that the side that first wanted to use H.245 procedures has performed it, so TCS alone is enough of a prelude to get the H.245 session up and running. Do you think this needs clarification text? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, April 03, 2000 8:00 AM To: Paul Long Subject: Re: Force remote to start H.245 session? 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 [View Less]

2 3

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

04 Apr '00

The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. 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 of Lucent has provided 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 … [View More]

1 0

Re: Mob ad hoc group progress
by Roy, Radhika R, ALARC 04 Apr '00

04 Apr '00

Paul: Thanks for clarifications. In the last conf call, we even cannot complete the simple intra-zone (intra-network, inter-network) scenarios first. You are right that we should concentrate on the scenarios (Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction, Call release). Definitely, we can go further: Inter-Zone (intra-domain) scenarios as well if we can agree on the first one. AT&T … [View More]contributions already contain many of those aspects. Hope to bring new contributions explaining further in both scenarios. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Guram Paul-LPG019 [SMTP:lpg019@EMAIL.MOT.COM] > Sent: Sunday, April 02, 2000 3: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 > [View Less]

1 0

Updated notice of the Osaka meeting
by Sakae OKUBO 04 Apr '00

04 Apr '00

/// Corrections to the notice dated Tue, 4 Apr 2000 01:35:36 +0900 /// /// /// /// 1) Dale Skran's new coordinates /// /// Sonus Networks /// /// 4400 Route 9 South /// /// Suite 1000 /// /// Freehold, NJ 07748 /// ///… [View More] +1 732 409 5107 (voice) /// /// +1 732 409 5172 (fax) /// /// dskran(a)sonusnet.com /// /// /// /// 2) 1. Date /// /// /// /// 15 (Monday) - 19 (Friday) March 2000 ==> 15-19 May 2000 /// /// /// /// 3) 3. 3) - Issue white papers for: /// /// H.450.8 ==> H.450.9 /// /// /// /// 4) Attached application form, deadline for registration /// /// 24 May ==> 24 April /// /// /// /// An updated text and an updated attachment follow. Apologies /// /// for demanding your error resilient reading and thanks for /// /// kind advice from several members. /// 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 Sonus Networks 4400 Route 9 South Suite 1000 Freehold, NJ 07748 USA Tel: +1 732 409 5107 Fax: +1 732 409 5172 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: 4 April 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) May 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.9 [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/Info_ITU-T_Osaka_r1.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 ---------- [View Less]

1 0

AW: Correction to the notice of Osaka meeting
by <Karl Klaghofer> 04 Apr '00

04 Apr '00

Dear Mr. Okubo, There is a small typo in section 3) of the Q.13/16 Topics for the meeting ".... - Issue white papers for: ...... * H.450.8 [may have been issued already] ...." This should instead read H.450.9 Call Completion (H.450.8 is the Names Suppl Service and has already been decided in Geneva), Regards, Karl Klaghofer Siemens karl.klaghofer(a)icn.siemens.de

1 0

Correction to the notice of Osaka meeting
by Sakae OKUBO 03 Apr '00

03 Apr '00

/// Correction to the notice posted Tue, 4 Apr 2000 01:35:36 +0900 /// /// /// /// 1. Date /// /// /// /// 15 (Monday) - 19 (Friday) March 2000 ==> 15-19 May 2000 /// 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 … [View More]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: 4 April 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) May 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 ---------- [View Less]

1 0