- sg16-avd - lists.packetizer.com

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