- sg16-avd - lists.packetizer.com

Soliciting contributions for the Beijing meeting
by OKUBO Sakae 16 Apr '04

16 Apr '04

Dear Q.F,G,K,2-5/16 experts, As we need final approval of the SG16 management for the subject meeting, please register your contributions at an early occasion to Mr. Paul Jones <paulej(a)packetizer.com> even if the deadlines are set as follows: /// Registration of the document: by 23:59 UTC, 30 April 2004 /// /// Distribution of the document: by 23:59 UTC, 4 May 2004 /// Please be reminded that we need sufficient number of participants and contributions for the justification of holding Rapporteur meetings. Now I can expect sufficient number of participants in Beijing, the next is the number of contributions. Please also note the following plea from Mr. Lehmann, Rapporteur for Q.K/16 (mobility). Please respond to him promptly, by the end of Monday 19 April at the latest, when he will decide if he can hold Q.K meeting in Beijing. At 07:21 -0500 04/04/02, OKUBO Sakae wrote: >*** forwarded to those who are interested in Q.K (mobility) works *** >*** on behalf of Mr. Leo Lehmann <Leo.Lehmann(a)bakom.admin.ch> *** > >Dear experts, > >We are planning to have a Rapporteur meeting in Beijing, China >during the week of May 11-14, 2004. > >With respect to Q.K (Mobility Management) I have collected very less >essential contributions. So far I can only report about the >discussions And meetings, which I had with 3GPP regarding the >Liaison "mobility between H.323 muti media systems and GPRS/IMT2000 >networks". I have not received any further contributions or interest >from experts regarding any of the Q.K work tasks: > >- Specification of mobility handling (terminal, user) between H.323 >environments and GPRS/ IMT2000 networks >- Specification of service mobility with respect to roaming of user >profiles, mobile Multimedia collaboration applications and services >- Specification of Handover procedures where active sessions can be >maintained during location changes >- Specification of Interworking with NGN networks to support >generalised mobility handling >- Presence >or any further work task. > >Due to this fact I would like to ask you urgently to send me some >input until April 13, 2004. Q.K can only be successful if it >receives contribution from various experts. > >If I receive no further input until this date I have to consider to >inform the SG16 management and the TSB that Q.K proposes to cancel >the Q.K meeting in Beijing. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

Test - please ignore
by Paul E. Jones 16 Apr '04

16 Apr '04

1 0

Re: Request for AVD number
by Paul E. Jones 06 Apr '04

06 Apr '04

Bob, Please use AVD-2425. I assume this will be addressed to Questions 2 and 3, but if different, please let me know. Thanks, Paul ----- Original Message ----- From: "Robert R. Gilman" <rrg(a)avaya.com> To: "Paul E. Jones" <paulej(a)PACKETIZER.COM> Sent: Monday, April 05, 2004 6:04 PM Subject: Request for AVD number > Paul- > Please assign an AVD number for the Beijing meeting for: > Proposal for a Generic Capability for Nx64K Circuit Relay > over IP > Thanks. > -Bob > ---------------------------------------------------- > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > >

1 0

Fwd:Re: Meeting of Q.1 in Beijing
by OKUBO Sakae 06 Apr '04

06 Apr '04

*** forwarded to those who are interested in Q.1/16 works *** >Date: Mon, 05 Apr 2004 21:45:41 +0200 >To: flaiani(a)aethra.com >From: Patrick Luthi <patrick.luthi(a)ties.itu.int> >Subject: Re: Meeting of Q.1 in Beijing >Cc: "Q.1/16" <tsg16q1(a)itu.int> >X-OriginalArrivalTime: 05 Apr 2004 19:45:56.0835 (UTC) >FILETIME=[9CF79B30:01C41B46] >Sender: owner-tsg16q1(a)itu.int >Reply-To: Patrick Luthi <patrick.luthi(a)ties.itu.int> >X-Biglobe-VirusCheck: Tue, 06 Apr 2004 04:54:05 +0900 > >Dear Mr. Flaiani, > >Thank you for your feedback and for your continuing interest in Q.1 >matters! I am forwarding your message to the Q.1 e-mail reflector >since it seems that your mail didn't make it before. > >Best regards, > >Patrick Luthi >Rapporteur for Q.1/16 > >At 18:28 04/02/2004 +0200, you wrote: > >>Roberto Flaiani >> >>02/04/2004 15.35 >> >> To: "Q.1/16" <tsg16q1(a)itu.int> >> cc: >> Subject: Meeting of Q.1 in Beijing >> >>Dear experts, >>I' d like to express Aethra's preference to progress Q1 work by >>correspondence until the next study group meeting. >>Given the very limited number of contributions currently on the >>table it appears hard to justify sending people with the required >>specific expertise to a physical meeting; handling the matter by >>e-mail we will not incur the risk of missing some critical piece of >>advise. >> We also share the concern that with a too limited participation >>the foundation for declaring consensus would be severely undermined. >>Best regards. >> >>Roberto Flaiani >>AETHRA

1 0

Request for Contributions to Q5/16 meeting in Beijing
by Robert R. Gilman 05 Apr '04

05 Apr '04

All- This is the first real meeting of the new Q5 NAT/Firewall Traversal question, and I'd like to solicit contributions to get the work started (but see also D-408 from the Geneva meeting). It seems especially appropriate to begin with discussions of requirements and architectures, and some examination of the existing body of work. Requirements might cover: - authentication of sources and sinks of traffic - authorization of sources/destinations to send/receive traffic. - network/realm topologies to be supported. - architectural principles - trust models - application scenarios - how to insure end-to=end privacy and integrity of application data, while permitting firewalls to authenticate the flows. - what we can require/use from existing firewalls (especially from the ubiquitous home firewalls.) - how to extend existing telephony protocols to free the firewall from knowledge of extraneous details of the protocols. I'm sure there are areas I've left out (like requirements for of any firewall control/request protocols.) At this stage, the field is wide open, so we need not limit ourselves to the above list. Another aspect of this work, I believe, is the need to involve the builders of firewalls. I don't believe we can be successful unless we can create a win/win situation for both the server and endpoint vendors and the firewall vendors. If any of you have contacts in the firewall market, please extend a personal invitation for them to join us. I'm looking forward to seeing you in Beijing. Thanks. -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868

1 0

Re: Document number
by Paul E. Jones 04 Apr '04

04 Apr '04

Roni, I have assigned AVD-2419 for you. Paul ----- Original Message ----- From: "Even, Roni" <roni.even(a)polycom.co.il> To: <paulej(a)packetizer.com> Sent: Sunday, April 04, 2004 5:07 AM Subject: Document number > Hi Paul, > I would like to get an AVD number for a contribution. > The title will be NAT traversal for H.323 signaling > Thanks > Roni > > ************************************* > Roni Even > VP Product Planning > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* >

1 0

Visa notification for the Beijing meeting
by OKUBO Sakae 03 Apr '04

03 Apr '04

Dear all, I have forwarded a lit of 22 requests of visa notification letter to the meeting host. Please return acknowledgement to the following when you have received your telefax: To: Ms. Hong Jiang <jianghong(a)catr.com.cn> Cc: Ms.Yaqin Shen <shenyaqin(a)catr.com.cn>, CCSA<ccsacontact(a)ccsa.org.cn>, Sakae Okubo <sokubo(a)waseda.jp> If anyone is planning to attend the Beijing meeting and needs the visa notification letter from the host, please advise me as soon as possible but not later than 15 April. The meeting host will respond to your request as much as practical. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

Request for contributions for Q.K/16 meeting in Beijing
by OKUBO Sakae 02 Apr '04

02 Apr '04

*** forwarded to those who are interested in Q.K (mobility) works *** *** on behalf of Mr. Leo Lehmann <Leo.Lehmann(a)bakom.admin.ch> *** Dear experts, We are planning to have a Rapporteur meeting in Beijing, China during the week of May 11-14, 2004. With respect to Q.K (Mobility Management) I have collected very less essential contributions. So far I can only report about the discussions And meetings, which I had with 3GPP regarding the Liaison "mobility between H.323 muti media systems and GPRS/IMT2000 networks". I have not received any further contributions or interest from experts regarding any of the Q.K work tasks: - Specification of mobility handling (terminal, user) between H.323 environments and GPRS/ IMT2000 networks - Specification of service mobility with respect to roaming of user profiles, mobile Multimedia collaboration applications and services - Specification of Handover procedures where active sessions can be maintained during location changes - Specification of Interworking with NGN networks to support generalised mobility handling - Presence or any further work task. Due to this fact I would like to ask you urgently to send me some input until April 13, 2004. Q.K can only be successful if it receives contribution from various experts. If I receive no further input until this date I have to consider to inform the SG16 management and the TSB that Q.K proposes to cancel the Q.K meeting in Beijing. Best regards Leo Lehmann Raporteur for Q.K/16

1 0

Fwd:Re: WG: Meeting of Q.1
by OKUBO Sakae 02 Apr '04

02 Apr '04

*** forwarded to experts who are interested in Q.1 related works *** >Date: Fri, 02 Apr 2004 12:33:02 +0200 >To: Sebestyen Istvan <istvan.sebestyen(a)siemens.com> >From: Patrick Luthi <patrick.luthi(a)ties.itu.int> >Subject: Re: WG: Meeting of Q.1 >Cc: "Q.1/16" <tsg16q1(a)itu.int> >X-OriginalArrivalTime: 02 Apr 2004 10:33:19.0351 (UTC) >FILETIME=[EA53D070:01C4189D] >Sender: owner-tsg16q1(a)itu.int >Reply-To: Patrick Luthi <patrick.luthi(a)ties.itu.int> >X-Biglobe-VirusCheck: Fri, 02 Apr 2004 19:38:33 +0900 > >Dear Mr. Sebestyen, > >Thank you for your feedback and for sharing your interest in Q.1 >matters! I am forwarding your message to the Q.1 e-mail reflector. > >Best regards, > >Patrick Luthi >Rapporteur for Q.1/16 > >At 11:54 04/02/2004 +0200, you wrote: >>Dear Mr. Luthi, >> >>Since it has been asked.. >> >>I regret to inform you, that I will not be able to participate in >>your Rapporteur's meeting. As you may know the IMTC Forum is just >>the following week in San Jose, and I will be very busy with the >>IMTC Board meeting and the Forum preparation. >> >>Of course any suggested changes to the H.320 series of standards >>are very important to us. For these long time ago established, very >>stable standards any - even well justified - changes can be very >>critical to the installed base, and interworking is a top issue. >>Because of the importance, and certainly for us less urgency on the >>matter (as we deal with a stable technology) my personal preference >>would be to discuss this subject in the November 2004 SG16 meeting. >>Anyway whatever decision will be made, it is always the SG that >>makes the final decision, and we certainly reserve the right to >>intervene at that level in November if we feel so. >> >>So, whether you convene a physical meeting, or do it it >>electronically over your reflector, or the ITU-T web conferencing >>facilities, I wish you good work and lot of progress. However, if >>it was done electronically, which would be my preference, we would >>like to participate. >> >>Kind regards, >>Istvan Sebestyen >> >> >>-----Ursprungliche Nachricht----- >>Von: OKUBO Sakae >>Gesendet: Freitag, 2. April 2004 03:00 >>An: itu-sg16(a)external.cisco.com >>Betreff: Re: Meeting of Q.1 >> >> >>*** forwarded to experts who are interested in Q.1 related works *** >> >>At 19:14 +0200 04/04/01, Patrick Luthi wrote: >>>Dear Mr. Sun, >>> >>>Thank you for your message and for sharing your plans to submit >>>contributions to progress the work of Q.1. >>> >>>So far, your contributions are the first ones that have been offered >>>for this upcoming meeting. I am waiting until April 7, as I said in >>>my e-mail, to see how many contributions are coming, and how many >>>different member organizations plan to send representatives. >>> >>>As you may already know, under the ITU-T rules, we must have a >>>significant number of both contributions and member organizations >>>wanting to attend in order to justify an interim experts meeting. >>>The reason for this is to ensure that the result of such meeting >>>represents a true consensus of interested ITU-T members. >>> >>>In the past, Q.1 has rarely held interim Rapporteur meetings >>>(despite tentative plans at SG meetings) because of the absence of a >>>substantial number of contributions; there were only 2 such meetings >>>in the last 4 years and most of the work has been done during the SG >>>meetings. If we do not meet in Beijing, the work of Q.1 will >>>progress by e-mail correspondence, and you will have an opportunity >>>to present your contributions both on the e-mail reflector (at any >>>time of your choosing) and at the next meeting of Q.1 (at latest >>>during the November meeting of SG16 in Geneva). >>> >>>I very much hope that there will be enough contributions and >>>attendees to hold a meeting in Beijing. We will know by April 7. I >>>was personally hoping to visit Beijing for the meeting. >>> >>>I will keep you and the other Q.1 experts informed about the result >>>and the final decision as soon as possible after April 7. >>> >>>I am looking forward to collaborating with you and would like to >> >thank you for your continuing interest in Q.1 matters. >>> >>>Best regards, >>> >>>Patrick Luthi >>>Rapporteur for Q.1/16

1 0

Re: Meeting of Q.1
by OKUBO Sakae 01 Apr '04

01 Apr '04

*** forwarded to experts who are interested in Q.1 related works *** At 19:14 +0200 04/04/01, Patrick Luthi wrote: >Dear Mr. Sun, > >Thank you for your message and for sharing your plans to submit >contributions to progress the work of Q.1. > >So far, your contributions are the first ones that have been offered >for this upcoming meeting. I am waiting until April 7, as I said in >my e-mail, to see how many contributions are coming, and how many >different member organizations plan to send representatives. > >As you may already know, under the ITU-T rules, we must have a >significant number of both contributions and member organizations >wanting to attend in order to justify an interim experts meeting. >The reason for this is to ensure that the result of such meeting >represents a true consensus of interested ITU-T members. > >In the past, Q.1 has rarely held interim Rapporteur meetings >(despite tentative plans at SG meetings) because of the absence of a >substantial number of contributions; there were only 2 such meetings >in the last 4 years and most of the work has been done during the SG >meetings. If we do not meet in Beijing, the work of Q.1 will >progress by e-mail correspondence, and you will have an opportunity >to present your contributions both on the e-mail reflector (at any >time of your choosing) and at the next meeting of Q.1 (at latest >during the November meeting of SG16 in Geneva). > >I very much hope that there will be enough contributions and >attendees to hold a meeting in Beijing. We will know by April 7. I >was personally hoping to visit Beijing for the meeting. > >I will keep you and the other Q.1 experts informed about the result >and the final decision as soon as possible after April 7. > >I am looking forward to collaborating with you and would like to >thank you for your continuing interest in Q.1 matters. > >Best regards, > >Patrick Luthi >Rapporteur for Q.1/16 > >At 11:34 04/01/2004 +0800, sun.zhibin(a)zte.com.cn wrote: > >>Dear Mr. Luthi, >> >>During January SG16 meeting, ZTE Corp. made two contributions about >>the use of HSD for >>the second video stream and a new digital channel aggregation >>procedure. I would like to provide >>some papers to further describe and discuss these two contributins >>during this Rapportuer >>meeting. >> >>So, a Rapporteur meeting of Q.1 is necessary in Beijing during the >>week of May >> 11-14, 2004. I hope to meet every expert of Q.1 in Beijing. >> >>All of you are welcome to China, a beautiful oriental country. >> >>Best regards, >> >>Sun Zhibin >> >>sun.zhibin(a)zte.com.cn >> >> >> >>Patrick Luthi <patrick.luthi(a)ties.itu.int> >>$B!F(BA$B7c]a�c!b(BY owner-tsg16q1(a)itu.int >> >>2004-03-30 15:45 >>$B"s!=!DGa(Be$B!I(B $B!FS(BPatrick Luthi >> >> $B�p7c]a�c!b(BY "Q.1/16" <tsg16q1(a)itu.int> >> $B!D(BL$B!0(Bl$B!b(BY "Rapporteurs WP2":; >> �$BUa(BO$B/a#:(B Q.1/16 Rapporteur meeting >> >> >>Dear experts, >> >>Q.D.F,G, 2-5/16 are planning to have a Rapporteur meeting in Beijing, China >>during the week of May 11-14, 2004. >> >>Q.1 had tentatively planned to hold interim meetings if needed before the >>November SG16 meeting, but, since I have not heard of any potential >>contributions or interest from experts to attend such meeting, I would like >>to announce that Q.1 will not meet at this time. Nevertheless, there will >>be other opportunities for Q.1 to meet later this year. >> >>Please let me know by April 7, 2004 if you believe that there is a need for >>Q.1 to hold a Rapporteur meeting in May. After that deadline, I will inform >>the SG16 management and the TSB that Q.1 will not be meeting. >> >> Best regards, >> >> Patrick Luthi >> Rapporteur for Q.1/16 >>

1 0

Additional Review of H.248.31
by OKUBO Sakae 01 Apr '04

01 Apr '04

Dear WP2/16 experts, The subject draft Recommendation has been judged needing additional review for the LM Ericsson's comment in response to Last Call. The proposed changes are as follows: ---------- 6.1.4 Jitter Buffer Type PropertyID: type (0x000b) Description: Indicates the jitter buffer type. When the jitter buffer is adaptive, then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. Type: Enumeration Possible values: "U" (0x0001) Unknown (Default) "N" (0x0002) Non adaptive "A" (0x0003) Adaptive Defined In: LocalControlDescriptor Characteristics: Read/Write ---------- ==> ---------- 6.1.4 Jitter Buffer Type PropertyID: type (0x000b) Description: Indicates the jitter buffer type. When the jitter buffer is adaptive, then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. Type: Enumeration Possible values: "NO" (0x0000) No Jitter Buffer (Default) "N" (0x0001) Non-adaptive "A" (0x0002) Adaptive Defined In: LocalControlDescriptor Characteristics: Read/Write ---------- Your review is requested before the deadline of 21 April. The full text including the above revision is placed at the avc-site: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/AAP-AR/H.248.31_post_… ftp://avguest:Avguest@ftp3.itu.int/avc-site/0401_Gen/AAP-AR/H.248.31_post_AAP.zip -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

Notice of the Beijing meeting (11-14 May 2004)
by OKUBO Sakae 01 Apr '04

01 Apr '04

*** This notice and the host's information as attached will be *** *** placed at <http://ftp3.itu.ch/av-arch/avc-site/0405_Bei/>. *** To Experts of ITU-T SG16 Questions F, G, K, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. M. Matsumoto, Vice-Chairman of SG16 <mmatsumoto(a)waseda.jp> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> Mr. L. Jiang, MII <jianglt(a)public.bta.net.cn> Ms. Y. Shen, MII <shenyaqin(a)catr.com.cn> Mr. C. Hansen, Rapporteur for Q.B/16 <chris.hansen(a)INTEL.COM>, Mr. P. Luthi, Rapporteur for Q.1/16 <patrick.luthi(a)TANDBERG.NO> De S-H. Jeong Rapporteur for Q.F/16 <shjeong(a)hufs.ac.kr> M. Euchner Rapporteur for Q.G/16 <Martin.Euchner(a)siemens.com> L. Lehmann Rapporteur for Q.K/16 <Leo.Lehmann(a)bakom.admin.ch> P. Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> C. Groves Rapporteur for Q.3/16 <Christian.Groves(a)ericsson.com.au> S. Okubo Rapporteur for Q.4/16 <sokubo(a)waseda.jp> R. Gilman Rapporteur for Q.5/16 <rrg(a)avaya.com> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Beijing, China Date: 31 March 2004 ------------------------------------------------------------------- Dear experts of Questions F, G, K, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in Beijing, China at the kind invitation of China Academy of Telecommunications Research of MII and China Communications Standards Association. Details of the meeting are contained herein. Please note that Q.B/16 and Q.1/16 may meet concurrently and we will have joint sessions with these Questions in that case. 1. Date ^^^^^^^ 11 (Tuesday) - 14 (Friday) May 2004 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ GUANGZHOU HOTEL No.A3, Xi Dan Heng Er Tiao, Xicheng District, Beijing, China Tel: +86 10 66078866 Fax: +86 10 66085998 Post Code: 100031 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for: * Annex N H.323 * H.priority * H.trans.cont 3) Q.G/16 Security of Multimedia Systems and Services - Progress work for: * H.235 Annex G * other study items in the living list (TD-71/WP2, January 2004) 4) Q.K/16 Mobility for Multimedia Systems and Services - Further elaboration TD-53/WP2 (January 2004) - Mobility aspects of presence service; co-ordination with Q.2/16 - Study of new service features - Follow up workplan 5) Q.2/16 Multimedia over packet networks using H.323 systems - Progress work for: * H.460.tppr * H.460.trans * H.460.relreq * H.gaam * H.323 Annexes I & N * H.323 Annexes Dv3, Gv2, Ov2 * H.sms * H.presence 6) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Progress work for: * H.248-subseries * H.245 v11 * H.341 7) Q.4/16 Video and data conferencing using Internet-supported services - H.350-series maintenance - Addition to H.350-series - Presence use scenarios - Study of new service features 8) Q.5/16 Control of NAT and Firewall Traversal for Multimedia Systems - Progress NAT/firewall traversal methods 9) Interaction with other groups - NGN - Others 10) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 30 April 2004 /// /// Distribution of the document: by 23:59 UTC, 4 May 2004 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Paul Jones <paulej(a)packetizer.com>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 30 April 2004 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note: Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.F, G, K, 2-5/16 Rapporteur Meeting {Date}| | Beijing, 11-14 May 2004 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ Note: A template for the AVD document can be found at: <http://ftp3.itu.ch/av-arch/avc-site/0405_Bei/AVD-template.doc> This may be modified and used for the purpose of document submission at this meeting. 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Tuesday 4 May 2004 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: itu-sg16(a)external.cisco.com To subscribe: Send e-mail to majordomo(a)cisco.com In the body of the message, put: subscribe itu-sg16 Please avoid the use of reflector when your document is voluminous. 5) Input documents can be retrieved from /0405_Bei directory of the ftp site once Mr. Jones has an opportunity to put them into place. The documents will also be available through the following URLs: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0405_Bei/ 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop and 802.11b wireless card in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by China Academy of Telecommunications Research of MII and China Communications Standards Association. Please refer to the participants' information document kindly prepared by the host, which is available at: <http://ftp3.itu.int/av-arch/avc-site/0405_Bei/Participants-info.zip> 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the Meeting Registration / Hotel Room Reservation Form provided by the host in the participants' information document to Ms. Jiang Hong <jianghong(a)catr.com.cn> with copy to Ms.Yaqin Shen <shenyaqin(a)catr.com.cn> and CCSA <ccsacontact(a)ccsa.org.cn> by 28 April 2004. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ You are recommended to stay at GUANGZHOU HOTEL, the meeting place. For room reservation, please indicate the dates of your stay in the Meeting Registration / Hotel Room Reservation Form. We are looking forward to meeting with you in Beijing. Sincerely yours, Seong-ho JEONG Martin EUCHNER Robert GILMAN Paul JONES (document manager of this meeting) Christian GROVES Sakae OKUBO (meeting organizer of this meeting) Leo LEHMANN ----------

1 0

Reminder - Visa Notification for the Beijing meeting (11-14 May)
by OKUBO Sakae 31 Mar '04

31 Mar '04

Dear Q.F,G,K,2-5/16 experts, So far I have received requests from the following persons: D Lindbergh, K J Boyle II, R R Gilman, M Euchner, H L Fourie, R Even, R Flaiani, A Schwarz, B Samvasivan, L Lehmann, A Ruditsky, C D Wilmot, J Tegeler, M Pierce, E Horvath, J-P Blin, C Groves. If you have sent me your request but are not listed here, or if you are coming to Beijing but have not yet responded to the attached message, please advise me by the end of this week. As a separate course of action, I will send out the Beijing meeting notice in a couple of days. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <Yokosuka Research Park> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* >Date: Thu, 18 Mar 2004 10:53:12 -0500 (EST) >To: tsg16q1(a)ITU.INT, itu-sg16(a)external.cisco.com >From: OKUBO Sakae <okubo(a)mxz.mesh.ne.jp> >CC: jianghong(a)catr.com.cn, shenyaqin(a)catr.com.cn, chris.hansen(a)INTEL.COM >Subject: Visa Notification for the Beijing meeting (11-14 May) >X-OriginalArrivalTime: 20 Mar 2004 20:21:58.0156 (UTC) >FILETIME=[FE9B04C0:01C40EB8] >X-Biglobe-VirusCheck: Sun, 21 Mar 2004 05:29:25 +0900 > >Dear WP2/16 experts, > >This is a message to those who intend to attend the Beijing >Rapporteur meeting. > >According to the advice of the meeting host, please send me the >following information in text form for your receiving the visa >notification from the meeting host MII (even if you are not sure at >present) by the end of Friday, 2 April: > >----------------------------------------------------------------- >1 Surname: >2 Given name: >3 Nationality: >4 Occupation: >5 Passport type and No.: >6 Intended date of entry: >7 Number of entries (Single/Double/Multiple): >8 Duration of each stay: >9 Company name: >10 Company Address: >11 TEL: , FAX: , E-mail: >----------------------------------------------------------------- > >I will forward all the requests to the meeting host, Ms. Jiang Hong, >collectively so that you can receive the visa notification by >telefax. > >For your information, the visa application form is available at the >following site: > > http://www.fmprc.gov.cn/eng/ljzg/3647/3648/default.htm > >Here is the description of the meeting host necessary for your >completing the form: > > - Purpose of journey and place to visit in China ==> Attend the >ITU-T SG16 expert-meeting, Beijing > > - Company or person to visit in China, name(s), address and phone >no. ==> Mr.Wen Ku, The MII of China, No.13 West Chan An Ave. Beijing >100804, P.R.China Tel:+86-10-62304735 > >Please note that I am not collecting this form, though I mentioned >so in my previous progress report. The above items in text form are >sufficient for requesting the visa notification letter. > >-- >Best regards, > >OKUBO Sakae >e-mail: sokubo(a)waseda.jp >Visiting Professor >Graduate School of Science and Engineering >Waseda University >******************************************************************* ><Yokosuka Research Park> > Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 > 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 > 239-0847 Japan ><Nishi-Waseda> > 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 > 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 > 169-0051 Japan >******************************************************************* >My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not >working any more. If they remain in your address book, could you >please replace them with <sokubo(a)waseda.jp>?

1 0

Fwd:Q.1/16 Rapporteur meeting
by OKUBO Sakae 30 Mar '04

30 Mar '04

*** FYI *** >Date: Tue, 30 Mar 2004 09:45:49 +0200 >To: "Q.1/16" <tsg16q1(a)itu.int> >From: Patrick Luthi <patrick.luthi(a)ties.itu.int> >Subject: Q.1/16 Rapporteur meeting >Cc: "Rapporteurs WP2":; >X-Biglobe-VirusCheck: Tue, 30 Mar 2004 16:45:57 +0900 > >Dear experts, > >Q.D.F,G, 2-5/16 are planning to have a Rapporteur meeting in >Beijing, China during the week of May 11-14, 2004. > >Q.1 had tentatively planned to hold interim meetings if needed >before the November SG16 meeting, but, since I have not heard of any >potential contributions or interest from experts to attend such >meeting, I would like to announce that Q.1 will not meet at this >time. Nevertheless, there will be other opportunities for Q.1 to >meet later this year. > >Please let me know by April 7, 2004 if you believe that there is a >need for Q.1 to hold a Rapporteur meeting in May. After that >deadline, I will inform the SG16 management and the TSB that Q.1 >will not be meeting. > > Best regards, > > Patrick Luthi > Rapporteur for Q.1/16

1 0

Re: Fwd:XML namespace identifiers in ITU-T Recommendations
by OKUBO Sakae 27 Mar '04

27 Mar '04

Dear WP2/16 experts, At 01:35 -0500 04/03/26, OKUBO Sakae wrote: >TSAG document on the subject matter will be placed at the Beijing >meeting directory of avc-site by Mr. Paul Jones. Your review is >requested. This document is now available at: http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/AVD-2418.zip Please note that the list of Beijing meeting documents is: http://avguest@ftp3.itu.int/av-arch/avc-site/0405_Bei/0504_Bei.html -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

Fwd:XML namespace identifiers in ITU-T Recommendations
by OKUBO Sakae 26 Mar '04

26 Mar '04

Dear WP2/16 experts, TSAG document on the subject matter will be placed at the Beijing meeting directory of avc-site by Mr. Paul Jones. Your review is requested. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>? >From: simao.campos(a)itu.int >To: okubo(a)giti.waseda.ac.jp, mmatsumoto(a)waseda.jp >Subject: XML namespace identifiers in ITU-T Recommendations >Date: Wed, 24 Mar 2004 09:21:31 +0100 >X-OriginalArrivalTime: 24 Mar 2004 08:21:33.0040 (UTC) >FILETIME=[0414BF00:01C41179] >X-Biglobe-VirusCheck: Wed, 24 Mar 2004 17:21:43 +0900 > >Dear Sakae, Mitsuji: > >I would appreciate if you could call the attention of the experts to the >following document in TSAG coming from SG 17, >------------------------------------------------------------- >System : DMS >Group : itu-t >updated : 2004-03-23 23:58:07 >title : [ TD 0334 ] Recommended namespace identifiers for use in >ITU-T Recommendations >url : >www.itu.int/md/meetingdoc.asp?parent=T01-TSAG-040712-TD-GEN-0334&type=mitems > >------------------------------------------------------------- > >As this might have impact in our current/future work. If there are any >problem or suggested modifications, it would be useful to hear them so that >we can act accordingly in TSAG (this will be in July). > >Cheers, >Simao > >===================================================================== >Sim黍 Ferraz de Campos Neto Counsellor, ITU-T SG 16 >International Telecommunication Union Tel: +41-22-730-6805 >Place des Nations Fax: +41-22-730-5853 >Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int >On the web: www.itu.int/ITU-T/studygroups/com16 >===================================================================== > ***** Practice random kindness and senseless acts of beauty ***** >===================================================================== >

1 0

Visa Notification for the Beijing meeting (11-14 May)
by OKUBO Sakae 18 Mar '04

18 Mar '04

Dear WP2/16 experts, This is a message to those who intend to attend the Beijing Rapporteur meeting. According to the advice of the meeting host, please send me the following information in text form for your receiving the visa notification from the meeting host MII (even if you are not sure at present) by the end of Friday, 2 April: ----------------------------------------------------------------- 1 Surname: 2 Given name: 3 Nationality: 4 Occupation: 5 Passport type and No.: 6 Intended date of entry: 7 Number of entries (Single/Double/Multiple): 8 Duration of each stay: 9 Company name: 10 Company Address: 11 TEL: , FAX: , E-mail: ----------------------------------------------------------------- I will forward all the requests to the meeting host, Ms. Jiang Hong, collectively so that you can receive the visa notification by telefax. For your information, the visa application form is available at the following site: http://www.fmprc.gov.cn/eng/ljzg/3647/3648/default.htm Here is the description of the meeting host necessary for your completing the form: - Purpose of journey and place to visit in China ==> Attend the ITU-T SG16 expert-meeting, Beijing - Company or person to visit in China, name(s), address and phone no. ==> Mr.Wen Ku, The MII of China, No.13 West Chan An Ave. Beijing 100804, P.R.China Tel:+86-10-62304735 Please note that I am not collecting this form, though I mentioned so in my previous progress report. The above items in text form are sufficient for requesting the visa notification letter. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <Yokosuka Research Park> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

RE: H.245 User Input Indication question
by Paul Long 16 Mar '04

16 Mar '04

Paul, The CHOICE, UserInputIndication.userInputSupportIndication.basicString, means that a UII transmitter must only send 0-9, * and #. The attached email explains the rationale. This codepoint does not mean that transmitters must send these but can also send others because that would be redundant with 6.2.8/H.323v2: "H.323 terminals shall support the transmission of user input characters 0-9, '*', and '#'. Transmission of other characters is optional." Paul -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, March 16, 2004 12:48 PM To: Dave Lindbergh Cc: itu-sg16(a)external.cisco.com; Mike Nilsson Subject: Re: H.245 User Input Indication question Dave, Thanks for looking into this. Hopefully, Mike might have some recollection as to what this was intended for. It has been there for quite some time. Paul ----- Original Message ----- From: Dave Lindbergh To: Dave Lindbergh Cc: Paul E. Jones ; itu-sg16(a)external.cisco.com ; Mike Nilsson ; Paul Long Sent: Tuesday, March 16, 2004 1:32 PM Subject: Re: H.245 User Input Indication question Paul, I've just looked at H.245, and I can't figure it out either. I suggest that once we figure it out (or decide to deprecate it, if we can't figure it out), we add some text to H.245 to clarify this. Sorry. --Dave At 11:57 AM 3/16/2004, Dave Lindbergh wrote: At 11:53 AM 3/16/2004, Paul E. Jones wrote: Dave, So, I'm still confused. "are supported" means: a) The device may ONLY send that subset of characters? b) The device must support that subset, but may send others? Neither (but closer to b). It means the device DOES support that subset. It might also support others, might not. There's no "must" or "shall" about it - it's a statement about what the device actually does. Also, any insight into what the "userInputSupportedIndication" element is for within "UserInputIndication"? I'll try to look into that later today. --Dave Thanks, Paul ----- Original Message ----- From: Dave Lindbergh To: Paul E. Jones Cc: itu-sg16(a)external.cisco.com ; Mike Nilsson ; Paul Long Sent: Tuesday, March 16, 2004 11:48 AM Subject: Re: H.245 User Input Indication question Hi Paul, My recollection is that "are supported" was meant to indicate that the device can send those characters. (I think UII can send anything in the ASCII, and perhaps the Unicode, set.) The purpose of the "are supported" bit is to allow an automatic menu generator to limit the kinds of input it requests to what the far-end terminal can actually send. (weak example: "Press # for Customer Service" vs "Type SERVICE for Customer Service")...in fact people have used UII to do things like text chat, which is difficult with only a phone keypad. --Dave At 11:40 AM 3/16/2004, Paul E. Jones wrote: Folks, I have a question regarding H.245 User Input Indication. In section B.14.6, it states: "The boolean basicString, when true, indicates that the characters 0-9, * and # are supported." My question is whether that those characters are supported means that it is the only valid characters that may be transmitted? Or is it also valid to transmit A,B,C,D, for example? In other words, does this wording simply indicate the minimum set of characters that must be supported or is the wording intended to specify the complete set of characters that may be used with "basicString". H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and that the characters 0-9, * and # must be supported and others are optional. However, it does not speak to whether endpoints must advertise support for basicString, IA5String, etc. A second question: can somebody explain why there is a CHOICE of "userInputSupportIndication" inside the UserInputIndication message? Would we not always advertise capabilities via the UserInputCapability only? Is the intent of having the "userInputSupportIndication" for changing capabilities outside of a normal capability exchange. Any clarification you can provide would be most appreciated. Thanks, Paul ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

Re: H.245 User Input Indication question
by Paul E. Jones 16 Mar '04

16 Mar '04

Dave, Thanks for looking into this. Hopefully, Mike might have some recollection as to what this was intended for. It has been there for quite some time. Paul ----- Original Message ----- From: Dave Lindbergh To: Dave Lindbergh Cc: Paul E. Jones ; itu-sg16(a)external.cisco.com ; Mike Nilsson ; Paul Long Sent: Tuesday, March 16, 2004 1:32 PM Subject: Re: H.245 User Input Indication question Paul, I've just looked at H.245, and I can't figure it out either. I suggest that once we figure it out (or decide to deprecate it, if we can't figure it out), we add some text to H.245 to clarify this. Sorry. --Dave At 11:57 AM 3/16/2004, Dave Lindbergh wrote: At 11:53 AM 3/16/2004, Paul E. Jones wrote: Dave, So, I'm still confused. "are supported" means: a) The device may ONLY send that subset of characters? b) The device must support that subset, but may send others? Neither (but closer to b). It means the device DOES support that subset. It might also support others, might not. There's no "must" or "shall" about it - it's a statement about what the device actually does. Also, any insight into what the "userInputSupportedIndication" element is for within "UserInputIndication"? I'll try to look into that later today. --Dave Thanks, Paul ----- Original Message ----- From: Dave Lindbergh To: Paul E. Jones Cc: itu-sg16(a)external.cisco.com ; Mike Nilsson ; Paul Long Sent: Tuesday, March 16, 2004 11:48 AM Subject: Re: H.245 User Input Indication question Hi Paul, My recollection is that "are supported" was meant to indicate that the device can send those characters. (I think UII can send anything in the ASCII, and perhaps the Unicode, set.) The purpose of the "are supported" bit is to allow an automatic menu generator to limit the kinds of input it requests to what the far-end terminal can actually send. (weak example: "Press # for Customer Service" vs "Type SERVICE for Customer Service")...in fact people have used UII to do things like text chat, which is difficult with only a phone keypad. --Dave At 11:40 AM 3/16/2004, Paul E. Jones wrote: Folks, I have a question regarding H.245 User Input Indication. In section B.14.6, it states: "The boolean basicString, when true, indicates that the characters 0-9, * and # are supported." My question is whether that those characters are supported means that it is the only valid characters that may be transmitted? Or is it also valid to transmit A,B,C,D, for example? In other words, does this wording simply indicate the minimum set of characters that must be supported or is the wording intended to specify the complete set of characters that may be used with "basicString". H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and that the characters 0-9, * and # must be supported and others are optional. However, it does not speak to whether endpoints must advertise support for basicString, IA5String, etc. A second question: can somebody explain why there is a CHOICE of "userInputSupportIndication" inside the UserInputIndication message? Would we not always advertise capabilities via the UserInputCapability only? Is the intent of having the "userInputSupportIndication" for changing capabilities outside of a normal capability exchange. Any clarification you can provide would be most appreciated. Thanks, Paul ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

Re: H.245 User Input Indication question
by Dave Lindbergh 16 Mar '04

16 Mar '04

At 11:53 AM 3/16/2004, Paul E. Jones wrote: >Dave, > >So, I'm still confused. "are supported" means: > a) The device may ONLY send that subset of characters? > b) The device must support that subset, but may send others? Neither (but closer to b). It means the device DOES support that subset. It might also support others, might not. There's no "must" or "shall" about it - it's a statement about what the device actually does. >Also, any insight into what the "userInputSupportedIndication" element is >for within "UserInputIndication"? I'll try to look into that later today. --Dave > >Thanks, >Paul > >----- Original Message ----- >From: <mailto:lindbergh@92f1.com>Dave Lindbergh >To: <mailto:paulej@PACKETIZER.COM>Paul E. Jones >Cc: <mailto:itu-sg16@external.cisco.com>itu-sg16(a)external.cisco.com ; ><mailto:mike.nilsson@BT.COM>Mike Nilsson ; ><mailto:plong@PACKETIZER.COM>Paul Long >Sent: Tuesday, March 16, 2004 11:48 AM >Subject: Re: H.245 User Input Indication question > >Hi Paul, > >My recollection is that "are supported" was meant to indicate that the >device can send those characters. (I think UII can send anything in the >ASCII, and perhaps the Unicode, set.) > >The purpose of the "are supported" bit is to allow an automatic menu >generator to limit the kinds of input it requests to what the far-end >terminal can actually send. (weak example: "Press # for Customer Service" >vs "Type SERVICE for Customer Service")...in fact people have used UII to >do things like text chat, which is difficult with only a phone keypad. > >--Dave > >At 11:40 AM 3/16/2004, Paul E. Jones wrote: >>Folks, >> >>I have a question regarding H.245 User Input Indication. In section >>B.14.6, it states: >> >> "The boolean basicString, when true, indicates that the characters >> 0-9, * and # are supported." > >> >>My question is whether that those characters are supported means that it >>is the only valid characters that may be transmitted? Or is it also >>valid to transmit A,B,C,D, for example? In other words, does this >>wording simply indicate the minimum set of characters that must be >>supported or is the wording intended to specify the complete set of >>characters that may be used with "basicString". >> >>H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and >>that the characters 0-9, * and # must be supported and others are >>optional. However, it does not speak to whether endpoints must advertise >>support for basicString, IA5String, etc. >> >>A second question: can somebody explain why there is a CHOICE of >>"userInputSupportIndication" inside the UserInputIndication >>message? Would we not always advertise capabilities via the >>UserInputCapability only? Is the intent of having the >>"userInputSupportIndication" for changing capabilities outside of a >>normal capability exchange. >> >>Any clarification you can provide would be most appreciated. >> >>Thanks, >>Paul >> > >---------- >Dave Lindbergh >Polycom, Inc. >100 Minuteman Road >Andover MA 01810 USA >Voice: +1 978 292 5366 >Email: lindbergh(a)92F1.com >H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 1

Re: H.245 User Input Indication question
by Dave Lindbergh 16 Mar '04

16 Mar '04

At 11:53 AM 3/16/2004, Paul E. Jones wrote: >Dave, > >So, I'm still confused. "are supported" means: > a) The device may ONLY send that subset of characters? > b) The device must support that subset, but may send others? Neither (but closer to b). It means the device DOES support that subset. It might also support others, might not. There's no "must" or "shall" about it - it's a statement about what the device actually does. >Also, any insight into what the "userInputSupportedIndication" element is >for within "UserInputIndication"? I'll try to look into that later today. --Dave > >Thanks, >Paul > >----- Original Message ----- >From: <mailto:lindbergh@92f1.com>Dave Lindbergh >To: <mailto:paulej@PACKETIZER.COM>Paul E. Jones >Cc: <mailto:itu-sg16@external.cisco.com>itu-sg16(a)external.cisco.com ; ><mailto:mike.nilsson@BT.COM>Mike Nilsson ; ><mailto:plong@PACKETIZER.COM>Paul Long >Sent: Tuesday, March 16, 2004 11:48 AM >Subject: Re: H.245 User Input Indication question > >Hi Paul, > >My recollection is that "are supported" was meant to indicate that the >device can send those characters. (I think UII can send anything in the >ASCII, and perhaps the Unicode, set.) > >The purpose of the "are supported" bit is to allow an automatic menu >generator to limit the kinds of input it requests to what the far-end >terminal can actually send. (weak example: "Press # for Customer Service" >vs "Type SERVICE for Customer Service")...in fact people have used UII to >do things like text chat, which is difficult with only a phone keypad. > >--Dave > >At 11:40 AM 3/16/2004, Paul E. Jones wrote: >>Folks, >> >>I have a question regarding H.245 User Input Indication. In section >>B.14.6, it states: >> >> "The boolean basicString, when true, indicates that the characters >> 0-9, * and # are supported." > >> >>My question is whether that those characters are supported means that it >>is the only valid characters that may be transmitted? Or is it also >>valid to transmit A,B,C,D, for example? In other words, does this >>wording simply indicate the minimum set of characters that must be >>supported or is the wording intended to specify the complete set of >>characters that may be used with "basicString". >> >>H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and >>that the characters 0-9, * and # must be supported and others are >>optional. However, it does not speak to whether endpoints must advertise >>support for basicString, IA5String, etc. >> >>A second question: can somebody explain why there is a CHOICE of >>"userInputSupportIndication" inside the UserInputIndication >>message? Would we not always advertise capabilities via the >>UserInputCapability only? Is the intent of having the >>"userInputSupportIndication" for changing capabilities outside of a >>normal capability exchange. >> >>Any clarification you can provide would be most appreciated. >> >>Thanks, >>Paul >> > >---------- >Dave Lindbergh >Polycom, Inc. >100 Minuteman Road >Andover MA 01810 USA >Voice: +1 978 292 5366 >Email: lindbergh(a)92F1.com >H.320, H.323 video by arrangement ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

Re: H.245 User Input Indication question
by Paul E. Jones 16 Mar '04

16 Mar '04

Dave, So, I'm still confused. "are supported" means: a) The device may ONLY send that subset of characters? b) The device must support that subset, but may send others? Also, any insight into what the "userInputSupportedIndication" element is for within "UserInputIndication"? Thanks, Paul ----- Original Message ----- From: Dave Lindbergh To: Paul E. Jones Cc: itu-sg16(a)external.cisco.com ; Mike Nilsson ; Paul Long Sent: Tuesday, March 16, 2004 11:48 AM Subject: Re: H.245 User Input Indication question Hi Paul, My recollection is that "are supported" was meant to indicate that the device can send those characters. (I think UII can send anything in the ASCII, and perhaps the Unicode, set.) The purpose of the "are supported" bit is to allow an automatic menu generator to limit the kinds of input it requests to what the far-end terminal can actually send. (weak example: "Press # for Customer Service" vs "Type SERVICE for Customer Service")...in fact people have used UII to do things like text chat, which is difficult with only a phone keypad. --Dave At 11:40 AM 3/16/2004, Paul E. Jones wrote: Folks, I have a question regarding H.245 User Input Indication. In section B.14.6, it states: "The boolean basicString, when true, indicates that the characters 0-9, * and # are supported." My question is whether that those characters are supported means that it is the only valid characters that may be transmitted? Or is it also valid to transmit A,B,C,D, for example? In other words, does this wording simply indicate the minimum set of characters that must be supported or is the wording intended to specify the complete set of characters that may be used with "basicString". H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and that the characters 0-9, * and # must be supported and others are optional. However, it does not speak to whether endpoints must advertise support for basicString, IA5String, etc. A second question: can somebody explain why there is a CHOICE of "userInputSupportIndication" inside the UserInputIndication message? Would we not always advertise capabilities via the UserInputCapability only? Is the intent of having the "userInputSupportIndication" for changing capabilities outside of a normal capability exchange. Any clarification you can provide would be most appreciated. Thanks, Paul ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

H.245 User Input Indication question
by Paul E. Jones 16 Mar '04

16 Mar '04

Folks, I have a question regarding H.245 User Input Indication. In section B.14.6, it states: "The boolean basicString, when true, indicates that the characters 0-9, * and # are supported." My question is whether that those characters are supported means that it is the only valid characters that may be transmitted? Or is it also valid to transmit A,B,C,D, for example? In other words, does this wording simply indicate the minimum set of characters that must be supported or is the wording intended to specify the complete set of characters that may be used with "basicString". H.323 Section 6.2.8 simply says that "alphaNumeric" must be supported and that the characters 0-9, * and # must be supported and others are optional. However, it does not speak to whether endpoints must advertise support for basicString, IA5String, etc. A second question: can somebody explain why there is a CHOICE of "userInputSupportIndication" inside the UserInputIndication message? Would we not always advertise capabilities via the UserInputCapability only? Is the intent of having the "userInputSupportIndication" for changing capabilities outside of a normal capability exchange. Any clarification you can provide would be most appreciated. Thanks, Paul

2 1

Results of the Last Call that finished on 14 March
by OKUBO Sakae 16 Mar '04

16 Mar '04

Dear WP2/16 experts, The outcome of this Last Call can be found at: http://www.itu.int/ITU-T/studygroups/com16/aap/table-sg16aap.html Draft Recommendations generated by WP2/16 have been judged as follows: *** Additional Review (AR) *** New H.235 V3 Amendment 1 (including corrigendum) Based on the Avaya's comments, a revised draft has been put for additional review until 5 April 2004. In case you should have any comments to this revised text, please submit them to TSB in due time. The text is available at: http://www.itu.int/itudoc/itu-t/aap/sg16aap/recaap/h235a1v3/ar-text.html This Editor's text has also been placed at the following site for your convenience: http://avguest@ftp3.itu.int/av-arch/avc-site/0401_Gen/AAP-AR/h235a1v3_ww9_m… ftp://avguest:Avguest@ftp3.itu.int/avc-site/0401_Gen/AAP-AR/h235a1v3_ww9_meu.zip Proposed changes are summarized as follows: Relative to the version that has undergone AAP last call review, the following changes are incorporated due to to last call comments: - Unique Initial Value (IV) insured between one endpoint and the other. See 3rd bullet of clause H.7. This change should improve the security of the security profile 1 (SP1). - Change the length of initVect to 12 octets in consequence of above change. See Table H.1/235. *** Last Call Judgement (LJ) *** New H.248.31 (Adaptive Jitter Buffer Package) Comments have been provided by Ericcson. It is expected that these will be judged as editorial, and H.248.31 will be declared as AT (Approved with typographical corrections) at the next opportunity - beginning of April. *** Approved (A) *** Rev H.320 (Narrow-band visual telephone systems and terminal equipment) Rev H.221 (Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices) Rev H.230 (Frame-synchronous control and indication signals for audiovisual systems) Rev H.242 (System for communication between AV terminals using channels up to 2 Mbit/s) New H.241 Corrigendum New H.222.0 Amd. 3 (carriage of H.264 streams over H.222.0) New H.460.9 Annex B (Extended reporting) New H.460.10 (H.460.cpc) (Call Party Category) New H.460.11 (H.460.delayed) (Delayed Call Establishment) New H.460.12 (H.460.gci) (Glare Control Indication) New H.460.13 (H.460.hold) (Called User Release Control) New H.460.14 (H.460.mlpp) (Multilevel Precedence and Preemption) New H.460.15 (H.460.suspend) (TCP Channel Suspension) New Corrigendum 1 to H.248.1 Version 2 (Gateway Control Protocol) New Corrigendum 1 to H.248.3 (User Interface elements and action packages) New Corrigendum 1 to H.248.4 (Transport over SCTP) New Corrigendum 1 to H.248.7 (Generic announcement package) New Amendment 1 to H.248.8 (Error codes and service change reason description) New Corrigendum 1 to H.248.16 (Enhanced digit collection packages and procedures) New Corrigendum 1 to H.248.17 (Line test packages) New H.248.19 (Decomposed MCU, Audio, Video and Data Conferencing Packages) New H.248.21 (Semi-permanent Connection Handling Package) New Corrigendum 1 to H.248.23 (Enhanced Alerting packages) New Corrigendum 1 to H.248.25 (Basic CAS Packages) New Corrigendum 1 to H.248.26 (Enhanced analog lines packages) New H.248.28 (International CAS Packages) New H.248.30 (RTCP XR Packages) New H.350.6 (H.350.6 Directory Services Architecture for Call Forwarding and Preferences) New H.360 (ex H.qosarch) (QoS Architecture) -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* <Yokosuka Research Park> Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan <Nishi-Waseda> 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not working any more. If they remain in your address book, could you please replace them with <sokubo(a)waseda.jp>?

1 0

Fw: Rapporteur meeting in Beijing
by Paul E. Jones 12 Mar '04

12 Mar '04

FYI ----- Original Message ----- From: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP> To: "Kevin Boyle" <kboyle(a)NORTELNETWORKS.COM>; <tsg16q1(a)ITU.INT> Cc: <jianghong(a)catr.com.cn>; <shenyaqin(a)catr.com.cn> Sent: Friday, March 12, 2004 9:34 PM Subject: RE: Rapporteur meeting in Beijing > Dear Mr. Boyle and all, > > At 14:45 -0500 04/03/01, Kevin Boyle wrote: > >US Citizens traveling to China require a visa which will only be > >issued for business purposes with a formal invitation from a Chinese > >business contact. Will the MII be issuing such invitations? If so, > >how do we go about getting one? > > This is a progress report on the "formal invitation" required for the > visa. MII (Ministry of Information Industry) will issue the Visa > Notification (equivalent to invitation letter) to each participant. > The process will be as follows: > > 1/ Each possible participant provides necessary information by > filling in the visa application form. I will distribute the form with > the following items already filled in: > > - Purpose of journey and place to visit in China > - Company or person to visit in China, name(s), address and phone no. > > At the moment I am awaiting these pieces of information from the meeting host. > > Please note that even though we use the visa application form for > conveying information necessary for the "invitation", you need actual > visa application to the Chinese authority in your country. > > 2/ Each possible participant sends the filled in form together with > his/her fax number information to myself by a certain date > (tentatively the end of this month). > > 3/ I will send them collectively to the meeting host. > > 4/ MII telefaxes the visa notification to each possible participant. > > Please stay tuned on this mailing list for the step 1 above. > > -- > Best regards, > > OKUBO Sakae > e-mail: sokubo(a)waseda.jp > Visiting Professor > Graduate School of Science and Engineering > Waseda University > ******************************************************************* > <Yokosuka Research Park> > Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 > 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 > 239-0847 Japan > <Nishi-Waseda> > 29-7 Waseda University Bldg. Tel: +81 3 5286 9841 > 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 > 169-0051 Japan > ******************************************************************* > My addresses <okubo(a)giti.or.jp>, <sokubo(a)mn.waseda.ac.jp> are not > working any more. If they remain in your address book, could you > please replace them with <sokubo(a)waseda.jp>? >

1 0