- sg16-avd - lists.packetizer.com

Outcome of the SG16 meeting (26 July - 5 August 2005)
by OKUBO Sakae 06 Aug '05

06 Aug '05

Dear experts, The subject SG16 meeting has concluded with consent and approval of the documents as listed after my signature. An interim Rapporteur meeting will be planned during 28 November - 2 December 2005 (place is yet to be decided). Please see the following meeting report for the detailed outcome: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/WP2_report_050805. zip ftp://ftp3.itu.int/avc-site/2005-2008/0507_Gen/WP2_report_050805.zip user: avguest password: Avguest -- 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 ****************************************************************** <Recommendations for Consent> Draft new Corrigendum 4 to H.222.0 | ISO/IEC 13818-1 "Information Technology - Generic Coding Of Moving Pictures And Associated Audio Information: Systems" Draft new H.221 Amendment 1 "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices" Draft new H.230 Amendment 1 "Frame-synchronous control and indication signals for audiovisual systems" Draft revised H.239 Draft revised H.241 "Extended video procedures and control signals for H.300 series terminals" Draft new H.242 Amendment 1 "System for establishing communication between audiovisual terminals using digital channels up to 2 Mbit/s" Draft revised H.243 "Procedures for establishing communication between three or more audiovisual terminals using digital channels up to 1920 kbit/s" Draft revised H.324 "Terminal for low bit-rate multimedia communication" Draft revised H.245 "Control protocol for multimedia communication" Draft new H.246 Amendment 1 "Interworking of H-Series multimedia terminals with H-Series multimedia terminals and voice/voiceband terminals on GSTN and ISDN" Draft new H.460.17 "Tunneling RAS through H.225.0" Draft new H.460.20 "Location Number for H.323" Draft revised H.248.1 version 3 "Gateway Control Protocol" Draft Revision 1 of H.248.8 "Error Codes and Service Change Reasons" Draft new H.248.36 "Hanging Termination Detection Package" Draft new H.248.37 "IP NAPT Traversal Package" Draft new H.460.18 "Traversal of H.323 signalling across Firewalls and NATs" Draft new H.460.19 "Firewall and NAT traversal procedures for media in H.323 systems" Draft new F.741 (ex F.AvoD) "Service description and requirements for Audiovisual on Demand services" Draft new F.742 (ex F.DL) "Service description and requirements for distance learning services" Draft new F.733 (ex F.MMCIP) "Service description and requirements for multimedia conference services over IP networks" Draft new F.724 (ex F.VTIP) "Service description and requirements for videotelephony services over IP networks" Draft new Rec. H.235.0 "Security framework for H-series (H.323 and other H.245-based) multimedia systems" (for Consent) Draft new Rec. H.235.1 "Baseline Security Profile" (for Consent) Draft new Rec. H.235.2 "Signature Security Profile" (for Consent) Draft new Rec. H.235.3 "Hybrid Security Profile" (for Consent) Draft new Rec. H.235.4 "Direct and Selective Routed Call Security" (for Consent) Draft for new Rec. H.235.5 "Framework for secure authentication in RAS using weak shared secrets" (for Consent) Draft new Rec. H.235.6 "Voice encryption profile with native H.235/H.245 key management" (for Consent) Draft new Rec. H.235.7 "Usage of the MIKEY Key Management Protocol for the Secure Real Time Transport Protocol (SRTP) within H.235" (for Consent) Draft new Rec. H.235.8 "Key Exchange for SRTP using secure Signalling Channels" (for Consent) Draft new Rec. H.235.9 "Security Gateway Support for H.323" (for Consent) ========== <Documents for Approval> Draft revised Implementors' Guide for T.120-series Draft revised 3.7.3 H.323-Series Implementors$B%f(B Guide Draft revised H-Series Supplement 4 "Repository of generic parameters for ITU-T Recommendations H.460.x sub-series" Draft new Supplement 2 to the H-Series: H.248 Sub-Series: Packages Guide Release 7 Draft New Technical Paper "The Requirements for Network Address Translator and Firewall Traversal of H.323 Multimedia Systems" Draft New Technical Paper "Firewall and NAT traversal Problems in H.323 Systems" Draft new H.235 Version 3 (2003) Implementors$B%f(B Guide "Security and encryption for H-series (H.323 and other H.245-based) multimedia terminals" (for Approval) Draft new Technical Paper on Usage of the H.510 protocol for the support of H.323 based Multimedia Services within GPRS/IMT2000 networks ==========

1 0

GenericInformation field in contribution D.162
by Albert Wong 29 Jul '05

29 Jul '05

Hi, Sasha and experts, Regarding to the presentation of the contribution D.162 at the Q.2 meeting today, I searched too quickly to the ASN.1 structure. Instead, the issues that I found to adding the proposed GenericInformation field to UserInputIndication and EndSessionCommand messages should not have "SEQUENCE OF". Reasons are: - as GenericInformation is equivalent to GenericMessage or similar to GenericCapability, indeed no other CHOICE structure using it has "SEQUENCE OF" - The use of GenericInformation in UserInputIndication and EndSessionCommand messages are also expected to be declared in TerminalCapabilitySet. Since each GenericInformation message has its own messageIdentifier, if "SEQUENCE OF" exists, the same message can have more than one modes simultaneously, causing confusion and potentially interoperability problem. If more than one modes are expected, a nested GenericParameter could be specified. Therefore, I think it is not suitable to use "SEQUENCE OF" for the proposed GenericInformation in UserInputIndication and EndSessionCommand messages. Please let me know if you have the same view. Best Regards, Albert. --- Albert Wong Principal Engineer Dilithium Networks TEL: +1 707 792 3901 FAX: +1 707 795 3744 MOB: +1 415 299 7907 <mailto:albert.wong@dilithiumnetworks.com> albert.wong(a)dilithiumnetworks.com Communications for a Borderless World This electronic message contains information from Dilithium Networks Pty Ltd which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

1 0

V.152, 7.1.1: Clarification on Reserve Properties Mechanism for H.248-controlled VBDoIP
by Albrecht.Schwarz＠alcatel.de 29 Jul '05

29 Jul '05

Dear Q11 colleagues, based on the discussion on D203,204 in the morning Q11 session, I've drafted a text proposal for review. Regards Albrecht (See attached file: Alcatelx6b T05-SG16-050726-D V.152clarification.doc)

1 0

H.248.36 pre-comments; Re: H.248.1v3 additions and issues (Wednesday 27/07/05)
by Albrecht.Schwarz＠alcatel.de 28 Jul '05

28 Jul '05

FYI, just in advance of the meeting discussion, some comments (see change bars). Albrecht Comments by ALCATEL (A. Schwarz, July 27, 2005): 1. definition proposal for "hanging Termination" 2. further applicability statement (See attached file: T05-SG16-050726-TD-WP2-0124 Draft new H.248.36_CommentsALCATEL.doc) "Tom-PT Taylor" <taylor(a)nortel.c To: Christian Groves <christian.groves(a)ericsson.com> om> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Marianne Picha <mpicha(a)lucent.com>, "Benitez, Mariana (Annie)" <anniebp(a)lucent.com>, "Arturo Martin De Nicolas (AC/EED)" 28.07.2005 09:20 <arturo.martin-de-nicolas(a)ericsson.com>, "'Lin Yangbo'" <linyangbo(a)huawei.com> Subject: Re: H.248.1v3 additions and issues (Wednesday 27/07/05) According to my notes, we made the following decisions yesterday which are reflected in the attachment: - D-142 accepted subject to corrections. - D-143, D-144 no impact for differing reasons. - D-145 accepted with the change that the default logic is AND as stated in D-142. Also may have potential problem with token collision. - D-146 rejected in favour of adding EOL (CR and/or LF) to quotedString=

1 0

FW: ITU-T SG 16 request for registration of new SDP att-field ("T38VendorInfo")(Completed)
by simao.campos＠itu.int 26 Jul '05

26 Jul '05

For your information. Simao -----Original Message----- From: IANA [mailto:iana@iana.org] Sent: 25 July 2005 21:15 To: 'Hiroshi Tamura' Cc: Campos, Simao; sob(a)harvard.edu; Frost, Isabelle Subject: RE: ITU-T SG 16 request for registration of new SDP att-field ("T38VendorInfo")(Completed) Dear Hiroshi Tamura, Please accept our apologies for the delay in processing your request. It took an unusally long time for one of our experts to respond to our inquiry regarding your request. We have registered the SDP att-field "T38VendorInfo". See the following: http://www.iana.org/assignments/sdp-parameters Thank you, Michelle Cotton IANA > > > > -----Original Message----- > > > > From: simao.campos(a)itu.int [mailto:simao.campos@itu.int] > > > > Sent: Monday, January 24, 2005 4:15 AM > > > > To: iana(a)iana.org > > > > Cc: sob(a)harvard.edu; tamura(a)toda.ricoh.co.jp; > > > > webmaster(a)iana.org; Isabelle.Frost(a)itu.int > > > > Subject: ITU-T SG 16 request for registration of new SDP > > > > att-field > > > > ("T38VendorInfo") > > > > > > > > To: > > > > Internet Assigned Numbers Authority > > > > 4676 Admiralty Way, Suite 330 > > > > Marina del Rey, CA 90292 > > > > USA > > > > > > > > +1-310-823-9358 (phone) > > > > +1-310-823-8649 (facsimile) > > > > > > > > > > > > Dear Sirs > > > > > > > > Recently, an Amendment was approved to ITU-T Rec.T.38 and a new > > > > SDP att-field called "T38VendorInfo" was defined, necessitating > > > > its registration in your database. > > > > > > > > This request was initially communicated via a Liaison Statement > > > > sent to statements(a)ietf.org on 01/Dec/2004, and in this message > > > > I would like to check what is the status of our request, as I > > > > was not able to locate a "tracker" tool in the IANA website. I > > > > also verified in http://www.iana.org/assignments/sdp-parameters > > > > that the said field is not yet available, hence it hopefully is already under processing. > > > > > > > > I would appreciate to know when could this registration be ready. > > > > > > > > For easier reference, I added below the specific information of > > > > the requested registration (between --START and --END). > > > > > > > > Your prompt feedback will be deeply appreciated, and we remain > > > > at your disposal for any subsequent clarification needed. > > > > > > > > Best regards, > > > > Simão Campos > > > > Counsellor, ITU-T SG 16 Secretariat ("Multimedia"). > > > > > > > > > > > > ===================================================================== > > > > Simão Ferraz de Campos Neto Counsellor, ITU-T SG 6&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 > > > > ***** > > > > ================================================================ > > > > ===== > > > > > > > > --START > > > > Subject: Request of SDP att-field registration > > > > > > > > Contact Name: Hiroshi Tamura > > > > Email address: tamura(a)toda.ricoh.co.jp > > > > Telephone number: +81-3-3777-8124 > > > > Attribute-Name: T38VendorInfo > > > > Long-Form attribute name in English: Vendor Information > > > > Type of attribute: media level > > > > Whether the attribute value is subject to the charset attribute: no > > > > One paragraph explanation: > > > > This attribute is specified for use with ITU-T Recommendation > > > > T.38 Annex > > > D. > > > > It indicates the vendor information, the values of which are > > > > defined in ITU-T Recommendation T.35. > > > > Specification of appropriate values: > > > > Att-value = t35country-code SP t35extention SP manufacturer-code > > > > t35country-code = 1*(DIGIT) t35extention = 1*(DIGIT) > > > > manufacturer-code = 1*(DIGIT) ;optional > > > > Reference to the specification: ITU-T Rec. T.38 Annex D > > > > --END > > > > > > >

1 0

FW: ITU-T SG 16 request for registration of new SDP att-field ("T38VendorInfo")(Completed)
by simao.campos＠itu.int 26 Jul '05

26 Jul '05

For your information. Simao -----Original Message----- From: IANA [mailto:iana@iana.org] Sent: 25 July 2005 21:15 To: 'Hiroshi Tamura' Cc: Campos, Simao; sob(a)harvard.edu; Frost, Isabelle Subject: RE: ITU-T SG 16 request for registration of new SDP att-field ("T38VendorInfo")(Completed) Dear Hiroshi Tamura, Please accept our apologies for the delay in processing your request. It took an unusally long time for one of our experts to respond to our inquiry regarding your request. We have registered the SDP att-field "T38VendorInfo". See the following: http://www.iana.org/assignments/sdp-parameters Thank you, Michelle Cotton IANA > > > > -----Original Message----- > > > > From: simao.campos(a)itu.int [mailto:simao.campos@itu.int] > > > > Sent: Monday, January 24, 2005 4:15 AM > > > > To: iana(a)iana.org > > > > Cc: sob(a)harvard.edu; tamura(a)toda.ricoh.co.jp; > > > > webmaster(a)iana.org; Isabelle.Frost(a)itu.int > > > > Subject: ITU-T SG 16 request for registration of new SDP > > > > att-field > > > > ("T38VendorInfo") > > > > > > > > To: > > > > Internet Assigned Numbers Authority > > > > 4676 Admiralty Way, Suite 330 > > > > Marina del Rey, CA 90292 > > > > USA > > > > > > > > +1-310-823-9358 (phone) > > > > +1-310-823-8649 (facsimile) > > > > > > > > > > > > Dear Sirs > > > > > > > > Recently, an Amendment was approved to ITU-T Rec.T.38 and a new > > > > SDP att-field called "T38VendorInfo" was defined, necessitating > > > > its registration in your database. > > > > > > > > This request was initially communicated via a Liaison Statement > > > > sent to statements(a)ietf.org on 01/Dec/2004, and in this message > > > > I would like to check what is the status of our request, as I > > > > was not able to locate a "tracker" tool in the IANA website. I > > > > also verified in http://www.iana.org/assignments/sdp-parameters > > > > that the said field is not yet available, hence it hopefully is already under processing. > > > > > > > > I would appreciate to know when could this registration be ready. > > > > > > > > For easier reference, I added below the specific information of > > > > the requested registration (between --START and --END). > > > > > > > > Your prompt feedback will be deeply appreciated, and we remain > > > > at your disposal for any subsequent clarification needed. > > > > > > > > Best regards, > > > > Simão Campos > > > > Counsellor, ITU-T SG 16 Secretariat ("Multimedia"). > > > > > > > > > > > > ===================================================================== > > > > Simão Ferraz de Campos Neto Counsellor, ITU-T SG 6&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 > > > > ***** > > > > ================================================================ > > > > ===== > > > > > > > > --START > > > > Subject: Request of SDP att-field registration > > > > > > > > Contact Name: Hiroshi Tamura > > > > Email address: tamura(a)toda.ricoh.co.jp > > > > Telephone number: +81-3-3777-8124 > > > > Attribute-Name: T38VendorInfo > > > > Long-Form attribute name in English: Vendor Information > > > > Type of attribute: media level > > > > Whether the attribute value is subject to the charset attribute: no > > > > One paragraph explanation: > > > > This attribute is specified for use with ITU-T Recommendation > > > > T.38 Annex > > > D. > > > > It indicates the vendor information, the values of which are > > > > defined in ITU-T Recommendation T.35. > > > > Specification of appropriate values: > > > > Att-value = t35country-code SP t35extention SP manufacturer-code > > > > t35country-code = 1*(DIGIT) t35extention = 1*(DIGIT) > > > > manufacturer-code = 1*(DIGIT) ;optional > > > > Reference to the specification: ITU-T Rec. T.38 Annex D > > > > --END > > > > > > >

1 0

Re: ABOUT F.VTIP
by Zhang Qing 21 Jul '05

21 Jul '05

Dear Gunnar Hellstrom, Very thanks for your comments. About your reminded questions, I have some opinion as below for your reference. "1.Scope collision with F.703 Multimedia Conversation Service Description..." Here is a clarification for scope description about F.703 and F.VTIP. F.703 describes a general requirements of multimedia conversation service, many conversation services are covered in it, such as videotelephony, etc. And for each specific service, for example videotelephony service, it is necessary to describe the detailed requirement. So F.720 describes the sub-general requirements of videotelephony service, then F.721 for ISDN, F.723 for PSTN videotelephony service respectively, and F.VTIP intends to describe the requirements of IP videotelephony service. "2. The real time text medium is missing in the definition..." I agree that real time text medium is very important for people with hearing or speech disabilities. In F.VTIP, the IP videotelephony service is divided into basic and enhanced service, the real time text medium has been included in enhanced IP videotelephony service, I'm considering how to emphasize these features in F.VTIP. Sincerely thanks again for your kind advice. Best Regards, Qing Zhang > > ----- Original Message ----- > From: "Gunnar Hellstrom" <gunnar.hellstrom(a)omnitor.se> > To: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP>; "zhangqing" <q_zhang(a)huawei.com> > Cc: <itu-sg16(a)external.cisco.com> > Sent: Wednesday, July 20, 2005 5:48 AM > Subject: RE: ABOUT F.VTIP > > > Dear Qing Zhang, > > I have read the F.VTIP draft and have a couple of questions/comments: > > 1. Scope collision with F.703 Multimedia Conversation Service Description. > -------------------------------------------------------------------------- > It is not earlier habit of F.70x Recommendations to be network type specific. They describe multimedia service requirements in general terms, from the human point of view regardless of network type. F.703 already defines and describes the Video Telephony service and should be interpreted to define it on both circuit switched and IP networks. I think having an IP specific definition of Video Telephony in the F.70x series creates confusion. > Today, we also have an emphasis of evening out network influence on service experience in the NGN activities. > I suggest that you drop the IP specifics in this draft and merge it as an update to F.703. > > 2. The real time text medium is missing in the definition. > ---------------------------------------------------------- > In F.703 there is a service defined called "total conversation". It is a very impotant superset of video telephony created by adding real time conversational text medium to video telephony. The text is transmitted with the same flow as it is typed in order to give the call participants a good feeling of being in contact. No irritating waiting for the other one to complete a sentence, it all can be read by the participants as it is produced. > This addition has been driven by requirements from people with hearing or speech disabilities, but the feature has very general value. > > SG16 has been quite aware of the need to take accessibility for people with disabilities in account when creating Recommendations. This trend is finally spreading to other groups, and F.703 and other mainstream Recommendations with accessibility included form very important references in the work with deployment of accessible mainstream services. > > If advice no 1 to merge your document with F.703 is not followed, I suggest that IP total conversation is added to the F.VTIP draft with a description similar to the one for total conversation and the text medium in F.703. > I suggest that you declare three media to be normal for IP Video telephony; video, text and audio. > > Best regards > > Gunnar Hellström > ------------------------------------------- > Gunnar Hellström > Omnitor AB > Renathvägen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom(a)Omnitor.se > -------------------------------------------- > > >>-----Original Message----- >>From: zhangqing [mailto:q_zhang@huawei.com] >>Sent: Tuesday, July 12, 2005 6:09 PM >>To: OKUBO Sakae >>Cc: itu-sg16(a)external.cisco.com >>Subject: ABOUT F.VTIP >> >> >>Dear Mr. Okubo and all, >> >>Attached file is the new edition of F.VTIP. >> >>I appreciate the comments from Mr.Okubo and Mr. Blin >>Jean-Pierre, more comments and suggestions are solicited. >> >>Best regards, >> >>Qing Zhang >>Huawei Technologies Co., Ltd >>Tel : +86-755-89650436 >>Fax : +86-755-89651312 >>Mobile: +86-13316881228 >>E-mail: q_zhang(a)huawei.com >> >>----- Original Message ----- >>From: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP> >>To: <itu-sg16(a)external.cisco.com> >>Sent: Tuesday, July 12, 2005 10:49 AM >>Subject: SG16 meeting during 26 July - 5 August >> >> >>> Dear WP2/16 experts, >>> >>> Here are two pieces of information and request toward the upcoming >>> SG16 meeting. >>> >>> 1/ Q.5 Rapporteur >>> >>> Very unfortunately Mr. Bob Gilman advised the SG16 management of his >>> resignation from Q.5 Rapporteur and we reluctantly have to accept >>> this. As an emergency measure we have asked Mr. Paul Jones to lead >>> the Q.5 works at the upcoming SG16 meeting. >>> >>> Using this opportunity I would like to thank Bob not only for his >>> excellent leadership in the NAT/firewall traversal issue as >>> Rapporteur, but also for his valuable contributions to the H.323, >>> H.235 and other SG16 topics as expert since around 1999. >>> >>> 2/ Documents for the meeting >>> >>> Since this meeting is of Study Group level, all the documents are >>> handled by TSB, not by a Rapporteur. >>> >>> However, you may wish to upload your documents to the avc-site for >>> advance review by the experts. In that case, place your document at: >>> >>> ftp://ftp3.itu.int/avc-site/Incoming/ >>> user: avguest >>> password: Avguest >>> >>> or email it to me, then I will move it to: >>> >>> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen >>> ftp://ftp3.itu.int/avc-site/2005-2008/0507_Gen >>> user: avguest >>> password: Avguest >>> >>> -- >>> 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 >>> ****************************************************************** >> > > >

1 0

RE: ABOUT F.VTIP
by Gunnar Hellstrom 19 Jul '05

19 Jul '05

Dear Qing Zhang, I have read the F.VTIP draft and have a couple of questions/comments: 1. Scope collision with F.703 Multimedia Conversation Service Description. -------------------------------------------------------------------------- It is not earlier habit of F.70x Recommendations to be network type specific. They describe multimedia service requirements in general terms, from the human point of view regardless of network type. F.703 already defines and describes the Video Telephony service and should be interpreted to define it on both circuit switched and IP networks. I think having an IP specific definition of Video Telephony in the F.70x series creates confusion. Today, we also have an emphasis of evening out network influence on service experience in the NGN activities. I suggest that you drop the IP specifics in this draft and merge it as an update to F.703. 2. The real time text medium is missing in the definition. ---------------------------------------------------------- In F.703 there is a service defined called "total conversation". It is a very impotant superset of video telephony created by adding real time conversational text medium to video telephony. The text is transmitted with the same flow as it is typed in order to give the call participants a good feeling of being in contact. No irritating waiting for the other one to complete a sentence, it all can be read by the participants as it is produced. This addition has been driven by requirements from people with hearing or speech disabilities, but the feature has very general value. SG16 has been quite aware of the need to take accessibility for people with disabilities in account when creating Recommendations. This trend is finally spreading to other groups, and F.703 and other mainstream Recommendations with accessibility included form very important references in the work with deployment of accessible mainstream services. If advice no 1 to merge your document with F.703 is not followed, I suggest that IP total conversation is added to the F.VTIP draft with a description similar to the one for total conversation and the text medium in F.703. I suggest that you declare three media to be normal for IP Video telephony; video, text and audio. Best regards Gunnar HellstrÃ¶m ------------------------------------------- Gunnar HellstrÃ¶m Omnitor AB RenathvÃ¤gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- >-----Original Message----- >From: zhangqing [mailto:q_zhang@huawei.com] >Sent: Tuesday, July 12, 2005 6:09 PM >To: OKUBO Sakae >Cc: itu-sg16(a)external.cisco.com >Subject: ABOUT F.VTIP > > >Dear Mr. Okubo and all, > >Attached file is the new edition of F.VTIP. > >I appreciate the comments from Mr.Okubo and Mr. Blin >Jean-Pierre, more comments and suggestions are solicited. > >Best regardsï¼OE > >Qing Zhang >Huawei Technologies Co., Ltd >Tel : +86-755-89650436 >Fax : +86-755-89651312 >Mobile: +86-13316881228 >E-mail: q_zhang(a)huawei.com > >----- Original Message ----- >From: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP> >To: <itu-sg16(a)external.cisco.com> >Sent: Tuesday, July 12, 2005 10:49 AM >Subject: SG16 meeting during 26 July - 5 August > > >> Dear WP2/16 experts, >> >> Here are two pieces of information and request toward the upcoming >> SG16 meeting. >> >> 1/ Q.5 Rapporteur >> >> Very unfortunately Mr. Bob Gilman advised the SG16 management of his >> resignation from Q.5 Rapporteur and we reluctantly have to accept >> this. As an emergency measure we have asked Mr. Paul Jones to lead >> the Q.5 works at the upcoming SG16 meeting. >> >> Using this opportunity I would like to thank Bob not only for his >> excellent leadership in the NAT/firewall traversal issue as >> Rapporteur, but also for his valuable contributions to the H.323, >> H.235 and other SG16 topics as expert since around 1999. >> >> 2/ Documents for the meeting >> >> Since this meeting is of Study Group level, all the documents are >> handled by TSB, not by a Rapporteur. >> >> However, you may wish to upload your documents to the avc-site for >> advance review by the experts. In that case, place your document at: >> >> ftp://ftp3.itu.int/avc-site/Incoming/ >> user: avguest >> password: Avguest >> >> or email it to me, then I will move it to: >> >> http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen >> ftp://ftp3.itu.int/avc-site/2005-2008/0507_Gen >> user: avguest >> password: Avguest >> >> -- >> 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 >> ****************************************************************** >

1 0

FW: I-D ACTION:draft-ma-h323-sip-conf-requirement-00.txt
by simao.campos＠ITU.INT 18 Jul '05

18 Jul '05

Dear colleagues, For your information. Best regards Simao -----Original Message----- From: i-d-announce-bounces(a)ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts(a)ietf.org Sent: Wednesday, July 13, 2005 16:50 To: i-d-announce(a)ietf.org Subject: I-D ACTION:draft-ma-h323-sip-conf-requirement-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for the interworking between IPv4-based H.323 system and IPv6-based SIP conference system Author(s) : Y. Ma, et al. Filename : draft-ma-h323-sip-conf-requirement-00.txt Pages : 13 Date : 2005-7-13 H.323 conference system is well defined and widely deployed today. It is important for SIP UA, both IPv4 and IPv6, to access H.323 conference system. This document defines an architecture for a SIP UA to access H.323 conference system. The requirements for the elements in this architecture are examined. Also the transition scenario for IPv6 SIP UA to access IPv4 H.323 conference system is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ma-h323-sip-conf-requirement-0 0.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ma-h323-sip-conf-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ma-h323-sip-conf-requirement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

H.460.ma
by Sasha Ruditsky 18 Jul '05

18 Jul '05

Hi The latest draft of H.460.ma is attached. I expect that the final submission to the Geneva meeting will only contain minor editorial changes from this. Sasha

1 0