- sg16-avd - lists.packetizer.com

Fwd: Hotel availability in May 2003 is tight
by OKUBO Sakae 17 Jan '03

17 Jan '03

forwarded to WP2/16 experts >From: simao.campos(a)itu.int >To: [...] >Subject: Hotel availability in May 2003 is tight >Date: Thu, 16 Jan 2003 17:08:10 +0100 >Importance: high >X-Priority: 1 >X-OriginalArrivalTime: 16 Jan 2003 16:08:12.0886 (UTC) >FILETIME=[786C6F60:01C2BD79] > >Dear colleagues, > >it has been brought to my attention that room availability during our SG 16 >meeting in 20-30 May 2003 is tight. I am not aware of the reason, as no >exceptional events are taking place. Hence, it is advisable that delegates >make their hotel reservations as soon as possible. > >I would be most grateful should you be able to send this to the email lists >that you find appropriate, so that our delegates will maximize the chances >to get a suitable hotel room. > >Best regards, >Simao > >===================================================================== >Simao 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 ***** >===================================================================== -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Fwd: Hotel availability in May 2003 is tight
by OKUBO Sakae 16 Jan '03

16 Jan '03

forwarded to WP2/16 experts >From: simao.campos(a)itu.int >Subject: Hotel availability in May 2003 is tight >Date: Thu, 16 Jan 2003 17:08:10 +0100 >Importance: high > >Dear colleagues, > >it has been brought to my attention that room availability during >our SG 16 meeting in 20-30 May 2003 is tight. I am not aware of the >reason, as no exceptional events are taking place. Hence, it is >advisable that delegates make their hotel reservations as soon as >possible. > >I would be most grateful should you be able to send this to the >email lists that you find appropriate, so that our delegates will >maximize the chances to get a suitable hotel room. > >Best regards, >Simao > >===================================================================== >Sim $B5P (B 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 ***** >===================================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Requirements for H.ldap
by OKUBO Sakae 13 Jan '03

13 Jan '03

Dear Mr. Johnson and other experts who are interested in H.ldap, One of the action points from the previous SG16 meeting in October 2002 is to make a requirement capture as recorded in the meeting report COM16-R25: "At the WP2 review session, it was suggested to formulate a requirements capture that would serve a check at the final stage of standardization. We can find a good precedent in D.281 for H.248.MCU." I have tried a draft as attached based on the following materials: - AVD-2199 Directory Services Architecture for Multimedia Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges - D271 Directory Services Architecture for Multimedia Conferencing (Cisco Systems, Inc.) - COM16-R25 Report of WP2/16, October 2002 - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002 Your additions, deletions, reorganization, improved wordings etc are very much welcome. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 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 ******************************************************************* Draft AVD-2279 Source: TBD Title: Requirements for H.ldap "Directory Services Architecture for Multimedia Conferencing" Date: 11 January 2003 Purpose: Proposal H.ldap will be able to support the following requirements as seen from the human user, gatekeeper and terminal configuration. The list will also serve as a checklist to verify that the proposed specification will support listed items. Some of the features are marked as advanced features and will be part of the future extension. 1. General 1/ Service administrators need call servers that are aware of enterprise directories, to avoid duplication of account management processes. Users need directories to locate other users with whom they wish to communicate. All of these processes should pull their information from canonical data sources in order to reduce redundant processes and ensure information accuracy. [AVD-2199] 2/ H.ldap should accommodate H.320, H.324, SIP or other call signaling protocols concurrently with or subsequently to H.323, subject to decision of the group. [COM16-R25] 3/ The fact that recent videoconferencing products are mostly of H.323/H.320 hybrid should be taken into account. [COM16-R25] 4/ Standards should include information to facilitate implementation in addition to normative specifications. [COM16-R25] 5/ It should be possible to create very large-scale distributed directories. These could include white pages "portals" that allow searching for users across multiple institutions. In this application, each enterprise directory would register itself with (or be unknowingly discovered by) a directory of directories that is capable of searching across multiple LDAP directories. [AVD-2199] 2. Object Classes 1/ Enable endpoint information to be associated with people (or resources such as conference rooms). [AVD-2199] 2/ Enable online searchable "white pages" where dialing information (e.g. H.323 URL) can be found, along with other "traditional" directory information about a user, such as name, address, telephone, email, etc. [AVD-2199] 3/ Enable all endpoint information to be stored in a canonical data source (the Directory), rather than local to the gatekeeper, so that endpoints can be managed through manipulations of an enterprise directory, rather than by direct entry into the gatekeeper. [AVD-2199] 4/ Store enough information about endpoint configuration so that correct configuration settings can be documented to end users on a per-endpoint basis, as a support tool. [AVD-2199] 5/ Include H.323 zone information - such as the zone administrators, network identity of the gatekeeper and resources associated with the zone. [AVD-2199] 6/ Be able to support multiple instances of endpoints per user. [AVD-2199] 7/ Enable a "whois" functionality for H.323 zones, so that one may query the network and find contact information for a particular H.323 zone, and published resources associated with the zone. [AVD-2199] 8/ Be extendable as necessary. [AVD-2199] Defining a minimum in the standard with provision of an extension mechanism has been a good practice. [COM16-R25] Careful consideration is needed for what should be in the standard and what should be left for extension. [COM16-R25] 9/ Be able to encompass H.32x, SIP or other related conferencing protocols in the future. [D271] 3. Security, authentication and authorization 1/ It is important that the H.323 LDAP infrastructure support not only H.235 Annex D (hop-by-hop authentication) and Annex E (end-to-end authentication) modes, but that an organization could shift from one mode to the other without reconstructing the schema. [AVD-2199] 2/ Associate authentication information with a user and enable both endpoint and gatekeeper access to that information, in order to support H.235 Annexes D and E. [AVD-2199] 3/ It should allow both endpoint-centric and user-centric authentication. [AVD-2199] Authentication credentials, such as certificate or user ID / password for station and that for user can be separate. This separation allows for flexibility in the implementation of security architectures. [COM16-R25] 4/ It should be possible to use the directory to manage the services that are authorized for each endpoint or user once authentication is achieved. [D271] ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Reminder: San Jose Rapporteur's Meeting - February
by Paul E. Jones 10 Jan '03

10 Jan '03

Folks, I just want to send out this reminder to folks who might be interested in attending the Rapporteur's meeting for Questions 2,3,4,5,D,F, and G to be held next month in San Jose. (This is focused on H.323, H.248/Megaco, and related multimedia work). The announcement for the meeting can be found here: http://standard.pictel.com/ftp/avc-site/0302_San/Notice_San-Jose_0302.txt Also, if you sent me an e-mail to register for the meeting and you did not get an acknowledgement from me, please send it again. Unfortunately, my hard drive crashed on my file server and I may have lost a few pieces of mail. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

RESEND: ITU-T Q.D,F,G,2-5 Rapporteur's Meeting Announcement
by Paul E. Jones 06 Jan '03

06 Jan '03

Folks, Some people apparently did not receive a copy of the meeting announcement sent out last month on December 16/17. Therefore, I am sending the announcement again for the benefit of those who may not have seen it. Best Regards, Paul ========================================================================= To Experts of ITU-T SG16 Questions D, F, G, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> De T Taylor Rapporteur for Q.D/16 <taylor(a)nortelnetworks.com> M Buckley Rapporteur for Q.F/16 <mikebuckley(a)44comms.com> M Euchner Rapporteur for Q.G/16 <Martin.Euchner(a)siemens.com> P Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> T Anderson Rapporteur for Q.3/16 <tlatla(a)verizon.net> S Okubo Rapporteur for Q.4/16 <okubo(a)giti.waseda.ac.jp> E Horvath Rapporteur for Q.5/16 <ernst.horvath(a)siemens.com> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in San Jose, California Date: 16 December 2002 ------------------------------------------------------------------- Dear experts of Questions D, F, G, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in San Jose, California at Cisco Systems. Details of the meeting are contained herein. 1. Date ^^^^^^^ 11 (Tuesday) - 14 (Friday) February 2003 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ Cisco Systems, Inc. Gateway Conference Center Building J 255 West Tasman Drive San Jose, CA 94134 USA Tel: +1 408 526 4000 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.D/16 Interoperability of Multimedia Systems and Services - Develop roadmap for future activity on interoperability - Progress work on vocabulary - Cooperate in the development of recommendations on systems 3) Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for: * H.qos.arch * Review Annex N H.323 * Review and issue draft H.mmclass * Review and issue draft H.priority 4) Q.G/16 Security of Multimedia Systems and Services - Progress work on * H.235 Version 3 * H.235 Annex G (SRTP Usage) * H.SETS (Security for Emergency Telecommunications) * H.324 security enhancements & H.235 Annex C - Maintenance of * Revised H.233/H.234 (Circuit-switched A/V security) * H.235 Annex F (Hybrid Security Profile) * H.530 (Mobility Security) - Other items of interest with security impact 5) Q.2/16 Multimedia over packet networks using H.323 systems - Progress work on: * H.323 Annex N (QoS) * H.323 Annex O (I-net protocols) * Annex I/H.323 * H.225.0v5 * H.323v5 * H.460.tppr * Annex A/H.460.1 - Discuss plans for future work 6) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Progress work on * H.246AnxCv2 * H.248AnxF * H.248.19 * H.341v2 - Begin work on * MoIP for H.248 * other new work. 7) Q.4/16 Video and data conferencing using Internet-supported services - Produce requirement capture for H.ldap - Produce draft H.ldap - Produce issue list for H.ldap - Describe other service scenarios - Elaborate workplan 8) Q.5/16 Mobility for Multimedia Systems and Services - Progress work for: * H.500 * H.550 * other mobility related topics 9) Interaction with other groups 10) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 31 January 2003 /// /// Distribution of the document: by 23:59 UTC, 4 February 2003 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo <okubo(a)giti.waseda.ac.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 31 January 2003 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.D, F, G, 2-5/16 Rapporteur Meeting {Date}| | San Jose, 11-14 February 2003 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Tuesday 4 February 2003 or before) by posting them at either of the following: - Uploading via FTP The FTP area for SG16 documents is presently being moved. The new location will be advised on the e-mail reflector as soon as the transition of ftp site has been completed. - Intel e-mail reflector e-mail address: itu-sg16(a)echo.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0302_San directory of the ftp site once Mr. Okubo has an opportunity to put them into place. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop, Ethernet card, and Ethernet cable in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by Cisco Systems on the San Jose campus. San Jose Cisco campus map: http://www.cisco.com/warp/public/687/Directory/campus.html Directions to Building J from the San Jose Airport: o When exiting the San Jose Airport, make a left onto Route 87 (Guadalupe Parkway). o Go north on Route 87 to N. First Street. o Turn left onto N. First Street. o Take N. First Street approximately 2.4 miles to Tasman Drive. o Take a right on E. Tasman and cross over First Street. o Building J is in a group of buildings on the right just before you get to Vista Montana Ave. o Approximate distance from the San Jose Airport is 4 miles Directions to Building J from the San Francisco Airport: o Take Highway 101 south towards San Jose. o Take the 237 East exit towards Alviso/Milpitas. o Take the Zanker Exit. o Take a right on Zanker. o Take a left on Tasman. o Building J is in a group of buildings on the right just before you get to Vista Montana Ave. o Approximate distance from the San Jose Airport is 35 miles Transportation to and from the meeting facilities is the responsibility of the attendee. However, several area hotels offer a shuttle service to and from the San Jose airport, as well as to and from the Cisco campus. (Please see section 7 below for a partial listing.) Attendees will have access to the Internet via an Ethernet connection. Attendees are requested to bring an Ethernet cable at least 7 meters in length. 802.11b wireless access will not be available. Power outlets will be provided at each seat for use with laptop computers. The power outlets will be standard US connections at 110 volts. Attendees are required to bring any adapters, as necessary. 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Paul E. Jones <paulej(a)packetizer.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ There are no hotels specifically reserved for this meeting, as hotel space in San Jose is usually plentiful. Even so, it is a good idea to reserve your room in advance. For those who wish to have some suggestions, here are a few of the nearby hotels: Beverly Heritage Hotel 1820 Barber Lane Milpitas, CA 95035 http://www.beverlyheritage.com/ Tel: +1 408 943 9080 Crown Plaza 777 Bellew Drive Milpitas, CA 95035 http://www.sixcontinentshotels.com/h/d/CP/hd/sfomp Tel: +1 408 321 9500 Hilton Garden Inn 30 Ranch Drive Milpitas, CA 95035 http://www.hiltongardeninn.com/en/gi/hotels/index.jhtml?ctyhocn=SJCMHGI Tel: +1 408 719 1313 Sheraton San Jose 1801 Barber Lane Milpitas, CA 95035 http://www.starwood.com/sheraton/search/hotel_detail.html?propertyID=670 Tel: +1 408 943 0600 All of the above hotels offer shuttle service to and from the San Jose airport, as well as shuttle service to and from the Cisco campus. Please check with the hotel for specific details and/or to make arrangements for transportation. We are looking forward to meeting with you in San Jose. Sincerely yours, Tom TAYLOR Mike BUCKLEY Martin EUCHNER Paul JONES (meeting manager of this meeting) Terry ANDERSON Sakae OKUBO (document manager of this meeting) Ernst HORVATH ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Contributions to the San Jose meeting
by OKUBO Sakae 04 Jan '03

04 Jan '03

Dear Q.D,F,G,2-5/16 experts, At 23:59 -0500 02/12/16, Paul E. Jones wrote: >3) 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 February 2003 or before) by posting > them at either of the following: > > - Uploading via FTP > The FTP area for SG16 documents is presently being moved. > The new location will be advised on the e-mail reflector as soon > as the transition of ftp site has been completed. The ftp site migration from PictureTel to ITU is yet to be completed (expectedly by mid January) and Polycom kindly continues the support of PictureTel site until then. The documents for the February meeting in San Jose are available at: using browser http://standard.pictel.com/ftp/avc-site/0302_San/ using ftp tool ftp://standard.pictel.com/avc-site/0302_San/ An initial list of contributions (liaison statements) is attached at the end of this message. For your input to the meeting, please upload your contribution to ftp://standard.pictel.com/avc-site/Incoming/ after obtaining an AVD or TD number from myself. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* Documents for the San Jose meeting (11-14 February 2003) AVD-2xxx Question(s) Title Source AVD-2260 F, 3, 11 Liaison on Rec. M.2301 and its relationship to Study Group 16 work ITU-T SG 4 AVD-2261 All Liaison statement on the ITU-T NGN 2004 Project ITU-T SG 13 AVD-2262 All Liaison statement on the ITU-T IP Project ITU-T SG 13 AVD-2263 All LS on Proposal for deletion of Q.14/13 ITU-T SG 13 AVD-2264 F Response to SG 12 on Comments on the initial draft of Y.qosar ITU-T SG 13 AVD-2265 F Response to SG 16 on $B!H (BLS reply to SG 13 on SG 13 work on Y.qosar $B!I (B ITU-T SG 13 AVD-2266 F Guidance on Packet Measurements ITU-T SG 13 AVD-2267 D, F, 2, 3, 4, 5 Draft Recommendation Y.1530 (November 2002) ITU-T SG 13 AVD-2268 I, 2 In response to the information about H.246 Annex C regarding the support of the International Emergency Preference Scheme (IEPS) calls ITU-T SG 11 AVD-2269 All SG11 Involvement in NGN 2004 project ITU-T SG 11 AVD-2270 D, 2 Progress on the new Syntax language based mechanism for the support of PSTN/ISDN services signaling over IP-based networks ITU-T SG 11 AVD-2271 F Liaison response on signalling requirements for IP-QoS ITU-T SG 11 AVD-2272 F Response to Consent of draft new Recommendation M.2301 (ex-M.23ip) ITU-T SG 13 AVD-2273 F Response to Liaison statement on call for model submission for the assessment of voice transmission quality from protocol analysis information in IP networks ITU-T SG 13 AVD-2274 F Response to Cooperation on measurement/monitoring of end-to-end Quality ITU-T SG 13 AVD-2275 2, 3, F Response to Progress of the discussion on generic end-to-end QoS service requirements ITU-T SG 13 AVD-2276 G, I SG2 work on Security, Telecommunications Disaster Recovery and Emergency Telecommunications ITU-T SG 2 AVD-2277 C, I Liaison Statement on Revised E.106 ITU-T SG 2 AVD-2278 F Response to $B!H (BLS _ Comments on Draft Recommendation E.QSC $B!I (B ITU-T SG 2 ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Rapporteur meeting in February 2003
by Even, Roni 24 Dec '02

24 Dec '02

Paul, The least we will need is to have Stephan's draft in some agreed upon stage like after WG last call before we put in H.225. We had some interop problem in H.263 due to different payload. BTW it will be dynamic PT Roni > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Tuesday, December 24, 2002 4:06 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: Rapporteur meeting in February 2003 > > > Roni, > > It is possible to specify the use of H.264 without an RFC. > Even today, > there is not RFC for G.723.1... though it has been in the > works for several > years. All we would need is an agreed-upon payload format and to ask > Henning to assign a PT value or decide on the use of a > dynamic PT value. We > can insert the payload format into H.225.0 if we want and use > that until the > RFC is available. > > Paul > > ----- Original Message ----- > From: "Even, Roni" <roni.even(a)POLYCOM.CO.IL> > To: <ITU-SG16(a)echo.jf.INTEL.COM> > Sent: Friday, December 20, 2002 11:35 AM > Subject: Re: Rapporteur meeting in February 2003 > > > > Hi, > > I want to pint out that in order to use H.264 in H.323 and > H.320 we need a > > final version of H.264 and an RFC describing the RTPformat. > So having > H.264 > > in May will not make it usable in a standrad mode unless we > can progress > on > > all fronts. > > Roni Even > > > > -----Original Message----- > > From: Gary Sullivan > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Sent: 18/12/2002 03:17 > > Subject: Re: Rapporteur meeting in February 2003 > > > > Istvan et al, > > > > The current plan is for JVT to meet in Pattaya with MPEG. > WP3 will then > > either be in Pattaya on or > > about the 15th of March or soon thereafter elsewhere. > > > > The previous plan was drafted under the expectation that we > would need > > to deliver FDIS text in > > mid-February as an interim editing output on the MPEG side. > > We now plan to allow more time for editing and final technical > > double-check, so FDIS text is not needed > > that soon. Although technical freeze was declared last > week, FDIS is > > not going to happen until March now > > so that we can have a more mature document. This lessens > the schedule > > pressure on the MPEG side > > somewhat. We can benefit from that extra time by doing the same > > thing on the ITU side and aligning text delivery and final technical > > double-check in both organizations. > > This will still enable ITU-T decision no later than May, > which is what > > it probably would have been anyway > > regardless of whether we did consent somwhat earlier. > > > > Best Regards, > > > > -Gary > > > > -----Original Message----- > > From: Sebestyen Istvan ICN M SR 3 > [mailto:istvan.sebestyen@SIEMENS.COM] > > Sent: Monday, December 16, 2002 6:46 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: AW: Rapporteur meeting in February 2003 > > > > > > So, how then are the plans concretely? > > > > On March 11-15, 2003 there is an MPEG Meeting in Pattaya. > So, H.264 goes > > to FDIS. > > But: > > > > 1) When and where is the JVT Meeting? > > 2) When and where is the WP3 Meeting? > > > > Kind regards, > > Istvan > > > > > > -----Urspr?ngliche Nachricht----- > > Von: Gary Sullivan [mailto:garysull@microsoft.com] > > Gesendet: Montag, 16. Dezember 2002 12:05 > > An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM > > Betreff: RE: Rapporteur meeting in February 2003 > > > > > > Yes, we are planning for WP3 consent for H.264/AVC sometime between > > March 15 and March 30. > > This will let us consent a better draft and coordinate > better with the > > ISO/IEC approval process. > > > > Best Regards, > > > > -Gary S. > > _____ > > > > From: Sebestyen Istvan ICN M SR 3 > > [mailto:istvan.sebestyen@SIEMENS.COM] > > Sent: Mon 12/16/2002 2:32 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: AW: Rapporteur meeting in February 2003 > > > > > > Dear Mr. Okubo, > > > > Thanks. > > For mid February also a one day WP3 meeting in Geneva was planned to > > make > > "consent" for H.264. Has that also gone away? > > > > Regards, > > Istvan Sebestyen > > > > -----Ursprungliche Nachricht----- > > Von: OKUBO Sakae [ mailto:okubo@MXZ.MESH.NE.JP > > <mailto:okubo@MXZ.MESH.NE.JP> ] > > Gesendet: Montag, 16. Dezember 2002 05:12 > > An: ITU-SG16(a)echo.jf.INTEL.COM > > Betreff: Fwd: Rapporteur meeting in February 2003 > > > > > > Dear Q.D,F,G,1-5/16 experts, > > > > The conclusion last week in Awajishima, Japan, was that > Q.6/WP3 would > > not meet as a whole next February. So we will meet in San > Jose during > > 11-14 February 2003 according to 2/ below. Mr. Jones will issue the > > meeting notice very soon. > > > > At 16:23 +0900 02/12/07, OKUBO Sakae wrote: > > >[...] > > >Rapporteurs have been seeking the best place to hold this meeting. > > >This is to report the progress. > > > > > >1/ As default, we will meet in Geneva to handle video > related topics > > >with Q.6 experts who will meet there for WP3 consent of H.264. > > > > > >2/ In case Q.6 and WP3 should not meet at that time > depending on the > > >interim achievements, Q.D,F,G,1-5/16 will meet in the US, > San Jose or > > >Raleigh, thanks to the offer of Cisco. > > > > > >3/ Q.6 is now working in Japan and will have a definite answer next > > >Friday if they meet in Geneva during the mentioned week next > > >February. So our final decision will be made at that time. Please > > >stay tuned on this mailinglist. > > > > > >4/ For this Rapporteur meeting, Paul Jones acts as meeting > organizer, > > >and myself as document manager. > > > > -- > > Best regards, > > > > OKUBO Sakae > > e-mail: okubo(a)giti.waseda.ac.jp > > ******************************************************************* > > YRP Office > > Global Information and Telecommunication Institute (GITI) > > Waseda University > > YRP Ichibankan 312 Tel: +81 468 47 5406 > > 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 > > 239-0847 Japan > > > > GITI Headquarter > > 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 > > ******************************************************************* > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: Rapporteur meeting in February 2003
by Even, Roni 23 Dec '02

23 Dec '02

Hi, I want to pint out that in order to use H.264 in H.323 and H.320 we need a final version of H.264 and an RFC describing the RTPformat. So having H.264 in May will not make it usable in a standrad mode unless we can progress on all fronts. Roni Even -----Original Message----- From: Gary Sullivan To: ITU-SG16(a)echo.jf.INTEL.COM Sent: 18/12/2002 03:17 Subject: Re: Rapporteur meeting in February 2003 Istvan et al, The current plan is for JVT to meet in Pattaya with MPEG. WP3 will then either be in Pattaya on or about the 15th of March or soon thereafter elsewhere. The previous plan was drafted under the expectation that we would need to deliver FDIS text in mid-February as an interim editing output on the MPEG side. We now plan to allow more time for editing and final technical double-check, so FDIS text is not needed that soon. Although technical freeze was declared last week, FDIS is not going to happen until March now so that we can have a more mature document. This lessens the schedule pressure on the MPEG side somewhat. We can benefit from that extra time by doing the same thing on the ITU side and aligning text delivery and final technical double-check in both organizations. This will still enable ITU-T decision no later than May, which is what it probably would have been anyway regardless of whether we did consent somwhat earlier. Best Regards, -Gary -----Original Message----- From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Monday, December 16, 2002 6:46 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 So, how then are the plans concretely? On March 11-15, 2003 there is an MPEG Meeting in Pattaya. So, H.264 goes to FDIS. But: 1) When and where is the JVT Meeting? 2) When and where is the WP3 Meeting? Kind regards, Istvan -----Urspr?ngliche Nachricht----- Von: Gary Sullivan [mailto:garysull@microsoft.com] Gesendet: Montag, 16. Dezember 2002 12:05 An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM Betreff: RE: Rapporteur meeting in February 2003 Yes, we are planning for WP3 consent for H.264/AVC sometime between March 15 and March 30. This will let us consent a better draft and coordinate better with the ISO/IEC approval process. Best Regards, -Gary S. _____ From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Mon 12/16/2002 2:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 Dear Mr. Okubo, Thanks. For mid February also a one day WP3 meeting in Geneva was planned to make "consent" for H.264. Has that also gone away? Regards, Istvan Sebestyen -----Ursprungliche Nachricht----- Von: OKUBO Sakae [ mailto:okubo@MXZ.MESH.NE.JP <mailto:okubo@MXZ.MESH.NE.JP> ] Gesendet: Montag, 16. Dezember 2002 05:12 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Fwd: Rapporteur meeting in February 2003 Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

FS-VDSL Focus Group
by John Magill 23 Dec '02

23 Dec '02

(My apologies if you receive this more than once.) Colleagues, As you probably know a new Full Service -VDSL Focus Group has been established under SG16. (see: http://www.itu.int/ITU-T/studygroups/com16/fs-vdsl/index.html for more information) To give SG16 delegates visibility of the draft Recommendations being prepared by the Focus Group, a new FTP site and email reflector have been established. These are open to both ITU-T members and Focus Group members. Full details are available at: http://www.itu.int/ITU-T/studygroups/com16/fs-vdsl/edh-info.html including details of how to join the email reflector and access the FTP site. On the FTP site you will find folders for each of the proposed Recommendations. These will be used to post the latest drafts as the work progresses. Current drafts resulting from the recent Focus Group meeting in Paris are available now. Also on the FTP site is a folder containing a number of informative White Papers on FS-VDSL. Those interested in the work of the Focus Group are encouraged to join the email reflector and review the draft Recommendations. Comments on the drafts are requested as soon as possible. There will be an editing meeting for the draft system architecture Recommendation in Turin, Italy, during 14-17 January 2003. We have SG16 permission to have a Rapporteur meeting at this time if sufficient interest exists, and there will also be a planned Rapporteur meeting in Toronto, 4-6 March 2003, which will also cover the OAM&P Recommendation. In addition it is currently proposed to convert the Operator Requirements Specification (Part 1) into an ITU-T Supplement to accompany the Recommendations. The latest published version of Part 1 is available at: http://www.itu.int/ITU-T/studygroups/com16/fs-vdsl/fgts.html Please contact me if you have any comments or questions on any aspect of the work. Other relevant contacts are: Associate Rapporteur for architecture Recommendation (Q.B) - Stephane Py <stephane.py(a)rd.francetelecom.com> Associate Rapporteur for OAM&P Recommendation (Q.C) - Peter Adams <p.f.adams(a)btopenworld.com> Best regards John Magill Vice-Chairman SG16 & FS-VDSL Focus Group --------------------------------------------------- John Magill Consultant Probecom Ltd. Tel: +44 1666 510105 Fax: +44 8700 527645 Email: johnmagill(a)probecom.co.uk --------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Job Opportunity for H.323/SIP Protocol Engineer
by Voip 4U 19 Dec '02

19 Dec '02

Location: Based in Sunnyvale, CA Responsibilities: Participate in system architecture conception and design. Software implementation, unit testing and documentation. Major development work will be H.323, SIP & MGCP based. Interworking with other industry products. General Requirements: Bachelor�s Degree required in Computer Science. At least 5 years of directly relevant experience developing telecommunication products. Ability to document completed designs with detailed engineering software specifications. A solid understanding of software engineering principles relative to multithreaded operating systems, Socket programming, process scheduling, IPC and concurrency in redundant distributed systems, Knowledge of debuggers, system utilities, scripting language, data structures. Experience with writing software for embedded system. Ability to document completed designs with detailed engineering software specifications. Qualifications: Knowledge of Firewalls, Qos, NAT is essential In addition to those mentioned above: Direct experience with telephony and VoIP protocols: H.323, SIP, MGCP, MEGACO/H.248, RTP. Experience in designing H.323 protocol stack is a big plus. (experience of openh323 is also good) UNIX application development Languages: C, C++ OS: Solaris, Linux --------------------------------- Do you Yahoo!? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com Yahoo! Mail Plus - Powerful. Affordable. Sign up now

1 0

Re: [h323forum] Re: Codec negotiation question
by Denise Shull 18 Dec '02

18 Dec '02

Trying to not 'plug' any company or technology in this arena, however, I am doing a consulting project for a company that schedules the packets - versus prioritizing them. They are in beta mode but their tests reveal a very effective method for delivering video with greatly reduced latency and jitter. It would be useful to be able to have input from this group both on the idea and on their technology specifically. Regards, Denise Denise K. Shull SHULL ADVISORS, LLC Strategic Application of Meeting Technologies 646-498-6403 www.videooverip.biz -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 16, 2002 8:04 PM To: Paul Long; h323forum(a)mail.imtc.org; ITU-SG16(a)echo.jf.INTEL.COM Subject: [h323forum] Re: Codec negotiation question Paul, Do you mean RFC 2508? In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical. Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item? Paul ----- Original Message ----- From: "Paul Long" <plong(a)packetizer.com> To: <h323forum(a)mail.imtc.org> Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question > Robert, > > Excellent point. I hadn't thought of that. I wonder what happened to > cRTP. Anybody know? That would sure help. > > Paul > > > > > On Mon, 16 Dec 2002 12:53:34 -0500 > > "Paul Long" <plong(a)packetizer.com> wrote: > > > > > I know lots of folks would like a means of expressing exact > > > packetization, but isn't the solution trivial? All you need is a > small > > > FIFO and a few lines of code to re-packetize according to any > internal > > > requirements. Just write incoming frames regardless of size, e.g., > > > 30fpp, to the FIFO, and read whatever size frames you want, e.g., > 80fpp > > > from the FIFO (only read if there are at least X fpp in the FIFO). > > > > DSP hardware is not the only reason for wanting to have the remote > > endpoint send larger packets. We have many clients on long haul > internet > > links (300ms+ ping times), often with a slow tail circuit (ISDN or > even > > modem) and you REALLY want the other end to send more than one G.723.1 > > frame per packet to reduce the significant overhead that there is in > the > > RTP. > > > > > > > > > > It is unfortunate but true that there is no way of expressing a > > > minimum > > > > acceptable number of frames per packet. > > > > > > > > Regards, > > > > Chris > > > > > > > > Paul Long wrote: > > > > > Davide, > > > > > > > > > > There is nothing in the standard that requires the acceptance > of an > > > OLC > > > > > or precludes terminating the call for any reason whatsoever so > both > > > EPs > > > > > are technically compliant. > > > > > > > > > > Packetization in TCS and OLC expresses the _maximum_ frames per > > > packet, > > > > > but several vendors don't understand this simple concept and > > > continue > > > > > to produce products that expect an exact packetization. There > is a > > > good > > > > > chance that that is why EP A is rejecting the OLC. It wants the > > > channel > > > > > opened at exactly 80fpp, although there is no way to express > this > > > in > > > > > H.323. IMO, if this is the reason, that product is broken. > > > > > > > > > > Paul > > > > > > > > > > > > > > >>Hi all, > > > > >> > > > > >>I have a question about a codec negotiation. > > > > >>During H.245 negotiation, endpoint A (master) exports g711A-law > > > with > > > > > > > > > > packetization 80, endpoint B (slave) exports g711A-law with > > > > > packetization 30. After that, endpoint A opens a channel with > > > > > packetization = 20 ms. Endpoint B acknoledges the OLC and tries > to > > > open > > > > > a channel with packetization = 30 ms. > > > > > > > > > >>Here Endpoint A rejects the OLC and the call is disengaged. > > > > >> > > > > >>Does anybody can tell me which endpoint dosn't behave according > to > > > > > > > > > > the H323 standard? > > > > > > > > > >>Thank you in advance. > > > > >> > > > > >>Davide > > > > > > > > > > > > > > > --- > > > > > You are currently subscribed to h323forum as: cwp@isdn- > comms.co.uk > > > > > To unsubscribe send a blank email to %%email.unsub%% > > > > > > > > > > > > > -- > > > > Dr Chris Purvis -- Development Manager > > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down > Road > > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > > Phone: +44 1344 899 007 > > > > Fax: +44 1344 899 001 > > > > > > > > > --- > > > You are currently subscribed to h323forum as: equival(a)equival.com.au > > > To unsubscribe send a blank email to %%email.unsub%% > > > > > > ---------- > > Robert Jongbloed Equivalence Pty. Ltd. > > Architect Open Phone Abstraction Library (OPAL) & OpenH323 > > Open Source Telecommunication Protocol Libraries > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Quicknet's revolutionary MicroTelco Services offers > > LOW WORLDWIDE RATES ANY TIME OF THE DAY with > > No monthly fees! No monthly minimums! No connection fees! > > US rates as low as 2.9 cents a minute! To see more rates, > > visit www.microtelco.com > > > > > > ****LIVE VIDEO CONFERENCE NOW AVAILABLE***** > > CUseeMe v5.0 software is an affordable easy-to-use software > > application providing live visual communication between friends, > > family and colleagues worldwide. To learn more, visit, > > www.cuseemeworld.com > > --- > You are currently subscribed to h323forum as: paulej(a)packetizer.com > To unsubscribe send a blank email to %%email.unsub%% > --- You are currently subscribed to h323forum as: deniseshull(a)sbcglobal.net To unsubscribe send a blank email to leave-h323forum-30418E(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

4 6

AW: Rapporteur meeting in February 2003
by Sebestyen Istvan ICN M SR 3 18 Dec '02

18 Dec '02

Gary, thanks for the clarification. Few remaining questions: 1) What does the "technical freeze" actually mean? No new technical contributions? Or only corrections on technologies, if any, if e.g. requirements are not fulfilled or editorial, typographical changes? 2) What is the purpose of a consent meeting in March? Will there be a "last call" immediately afterwards? Is the Mai SG Meeting planned to process the expected comments received? Or, the last call would go out only after the May meeting? In that case why the March Meeting? Kind regards, Istvan -----Ursprüngliche Nachricht----- Von: Gary Sullivan [mailto:garysull@microsoft.com] Gesendet: Mittwoch, 18. Dezember 2002 02:17 An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM Betreff: RE: Rapporteur meeting in February 2003 Istvan et al, The current plan is for JVT to meet in Pattaya with MPEG. WP3 will then either be in Pattaya on or about the 15th of March or soon thereafter elsewhere. The previous plan was drafted under the expectation that we would need to deliver FDIS text in mid-February as an interim editing output on the MPEG side. We now plan to allow more time for editing and final technical double-check, so FDIS text is not needed that soon. Although technical freeze was declared last week, FDIS is not going to happen until March now so that we can have a more mature document. This lessens the schedule pressure on the MPEG side somewhat. We can benefit from that extra time by doing the same thing on the ITU side and aligning text delivery and final technical double-check in both organizations. This will still enable ITU-T decision no later than May, which is what it probably would have been anyway regardless of whether we did consent somwhat earlier. Best Regards, -Gary -----Original Message----- From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Monday, December 16, 2002 6:46 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 So, how then are the plans concretely? On March 11-15, 2003 there is an MPEG Meeting in Pattaya. So, H.264 goes to FDIS. But: 1) When and where is the JVT Meeting? 2) When and where is the WP3 Meeting? Kind regards, Istvan -----Ursprüngliche Nachricht----- Von: Gary Sullivan [mailto:garysull@microsoft.com] Gesendet: Montag, 16. Dezember 2002 12:05 An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM Betreff: RE: Rapporteur meeting in February 2003 Yes, we are planning for WP3 consent for H.264/AVC sometime between March 15 and March 30. This will let us consent a better draft and coordinate better with the ISO/IEC approval process. Best Regards, -Gary S. _____ From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Mon 12/16/2002 2:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 Dear Mr. Okubo, Thanks. For mid February also a one day WP3 meeting in Geneva was planned to make "consent" for H.264. Has that also gone away? Regards, Istvan Sebestyen -----Ursprungliche Nachricht----- Von: OKUBO Sakae [ mailto:okubo@MXZ.MESH.NE.JP <mailto:okubo@MXZ.MESH.NE.JP> ] Gesendet: Montag, 16. Dezember 2002 05:12 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Fwd: Rapporteur meeting in February 2003 Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Rapporteur meeting in February 2003
by Gary Sullivan 17 Dec '02

17 Dec '02

Istvan et al, The current plan is for JVT to meet in Pattaya with MPEG. WP3 will then either be in Pattaya on or about the 15th of March or soon thereafter elsewhere. The previous plan was drafted under the expectation that we would need to deliver FDIS text in mid-February as an interim editing output on the MPEG side. We now plan to allow more time for editing and final technical double-check, so FDIS text is not needed that soon. Although technical freeze was declared last week, FDIS is not going to happen until March now so that we can have a more mature document. This lessens the schedule pressure on the MPEG side somewhat. We can benefit from that extra time by doing the same thing on the ITU side and aligning text delivery and final technical double-check in both organizations. This will still enable ITU-T decision no later than May, which is what it probably would have been anyway regardless of whether we did consent somwhat earlier. Best Regards, -Gary -----Original Message----- From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Monday, December 16, 2002 6:46 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 So, how then are the plans concretely? On March 11-15, 2003 there is an MPEG Meeting in Pattaya. So, H.264 goes to FDIS. But: 1) When and where is the JVT Meeting? 2) When and where is the WP3 Meeting? Kind regards, Istvan -----Ursprüngliche Nachricht----- Von: Gary Sullivan [mailto:garysull@microsoft.com] Gesendet: Montag, 16. Dezember 2002 12:05 An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM Betreff: RE: Rapporteur meeting in February 2003 Yes, we are planning for WP3 consent for H.264/AVC sometime between March 15 and March 30. This will let us consent a better draft and coordinate better with the ISO/IEC approval process. Best Regards, -Gary S. _____ From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Mon 12/16/2002 2:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 Dear Mr. Okubo, Thanks. For mid February also a one day WP3 meeting in Geneva was planned to make "consent" for H.264. Has that also gone away? Regards, Istvan Sebestyen -----Ursprungliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@MXZ.MESH.NE.JP] Gesendet: Montag, 16. Dezember 2002 05:12 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Fwd: Rapporteur meeting in February 2003 Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Q. D/16 Meeting In San Jose
by Tom-PT Taylor 17 Dec '02

17 Dec '02

Q. D/16 will meet in San Jose only if there are contributions to the question. If people intend to submit such contributions, I would appreciate notice by January 20. I will make the decision on whether to hold the meeting on that date. Please see TD 42 (WP 2/16) from the meeting in Geneva, 5-15 February 2002, for suggestions on contribution topics. This document is available in the TIES directory at http://ties.itu.int/u/tsg16/sg16/td/Geneva-5-02-2002/wp2/ Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

ITU-T Q.D,F,G,2-5 Rapporteur's Meeting Announcement
by Paul E. Jones 16 Dec '02

16 Dec '02

To Experts of ITU-T SG16 Questions D, F, G, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> De T Taylor Rapporteur for Q.D/16 <taylor(a)nortelnetworks.com> M Buckley Rapporteur for Q.F/16 <mikebuckley(a)44comms.com> M Euchner Rapporteur for Q.G/16 <Martin.Euchner(a)siemens.com> P Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> T Anderson Rapporteur for Q.3/16 <tlatla(a)verizon.net> S Okubo Rapporteur for Q.4/16 <okubo(a)giti.waseda.ac.jp> E Horvath Rapporteur for Q.5/16 <ernst.horvath(a)siemens.com> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in San Jose, California Date: 16 December 2002 ------------------------------------------------------------------- Dear experts of Questions D, F, G, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in San Jose, California at Cisco Systems. Details of the meeting are contained herein. 1. Date ^^^^^^^ 11 (Tuesday) - 14 (Friday) February 2003 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ Cisco Systems, Inc. Gateway Conference Center Building J 255 West Tasman Drive San Jose, CA 94134 USA Tel: +1 408 526 4000 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.D/16 Interoperability of Multimedia Systems and Services - Develop roadmap for future activity on interoperability - Progress work on vocabulary - Cooperate in the development of recommendations on systems 3) Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for: * H.qos.arch * Review Annex N H.323 * Review and issue draft H.mmclass * Review and issue draft H.priority 4) Q.G/16 Security of Multimedia Systems and Services - Progress work on * H.235 Version 3 * H.235 Annex G (SRTP Usage) * H.SETS (Security for Emergency Telecommunications) * H.324 security enhancements & H.235 Annex C - Maintenance of * Revised H.233/H.234 (Circuit-switched A/V security) * H.235 Annex F (Hybrid Security Profile) * H.530 (Mobility Security) - Other items of interest with security impact 5) Q.2/16 Multimedia over packet networks using H.323 systems - Progress work on: * H.323 Annex N (QoS) * H.323 Annex O (I-net protocols) * Annex I/H.323 * H.225.0v5 * H.323v5 * H.460.tppr * Annex A/H.460.1 - Discuss plans for future work 6) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Progress work on * H.246AnxCv2 * H.248AnxF * H.248.19 * H.341v2 - Begin work on * MoIP for H.248 * other new work. 7) Q.4/16 Video and data conferencing using Internet-supported services - Produce requirement capture for H.ldap - Produce draft H.ldap - Produce issue list for H.ldap - Describe other service scenarios - Elaborate workplan 8) Q.5/16 Mobility for Multimedia Systems and Services - Progress work for: * H.500 * H.550 * other mobility related topics 9) Interaction with other groups 10) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 31 January 2003 /// /// Distribution of the document: by 23:59 UTC, 4 February 2003 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo <okubo(a)giti.waseda.ac.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 31 January 2003 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.D, F, G, 2-5/16 Rapporteur Meeting {Date}| | San Jose, 11-14 February 2003 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Tuesday 4 February 2003 or before) by posting them at either of the following: - Uploading via FTP The FTP area for SG16 documents is presently being moved. The new location will be advised on the e-mail reflector as soon as the transition of ftp site has been completed. - Intel e-mail reflector e-mail address: itu-sg16(a)echo.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0302_San directory of the ftp site once Mr. Okubo has an opportunity to put them into place. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop, Ethernet card, and Ethernet cable in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by Cisco Systems on the San Jose campus. San Jose Cisco campus map: http://www.cisco.com/warp/public/687/Directory/campus.html Directions to Building J from the San Jose Airport: o When exiting the San Jose Airport, make a left onto Route 87 (Guadalupe Parkway). o Go north on Route 87 to N. First Street. o Turn left onto N. First Street. o Take N. First Street approximately 2.4 miles to Tasman Drive. o Take a right on E. Tasman and cross over First Street. o Building J is in a group of buildings on the right just before you get to Vista Montana Ave. o Approximate distance from the San Jose Airport is 4 miles Directions to Building J from the San Francisco Airport: o Take Highway 101 south towards San Jose. o Take the 237 East exit towards Alviso/Milpitas. o Take the Zanker Exit. o Take a right on Zanker. o Take a left on Tasman. o Building J is in a group of buildings on the right just before you get to Vista Montana Ave. o Approximate distance from the San Jose Airport is 35 miles Transportation to and from the meeting facilities is the responsibility of the attendee. However, several area hotels offer a shuttle service to and from the San Jose airport, as well as to and from the Cisco campus. (Please see section 7 below for a partial listing.) Attendees will have access to the Internet via an Ethernet connection. Attendees are requested to bring an Ethernet cable at least 7 meters in length. 802.11b wireless access will not be available. Power outlets will be provided at each seat for use with laptop computers. The power outlets will be standard US connections at 110 volts. Attendees are required to bring any adapters, as necessary. 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Paul E. Jones <paulej(a)packetizer.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ There are no hotels specifically reserved for this meeting, as hotel space in San Jose is usually plentiful. Even so, it is a good idea to reserve your room in advance. For those who wish to have some suggestions, here are a few of the nearby hotels: Beverly Heritage Hotel 1820 Barber Lane Milpitas, CA 95035 http://www.beverlyheritage.com/ Tel: +1 408 943 9080 Crown Plaza 777 Bellew Drive Milpitas, CA 95035 http://www.sixcontinentshotels.com/h/d/CP/hd/sfomp Tel: +1 408 321 9500 Hilton Garden Inn 30 Ranch Drive Milpitas, CA 95035 http://www.hiltongardeninn.com/en/gi/hotels/index.jhtml?ctyhocn=SJCMHGI Tel: +1 408 719 1313 Sheraton San Jose 1801 Barber Lane Milpitas, CA 95035 http://www.starwood.com/sheraton/search/hotel_detail.html?propertyID=670 Tel: +1 408 943 0600 All of the above hotels offer shuttle service to and from the San Jose airport, as well as shuttle service to and from the Cisco campus. Please check with the hotel for specific details and/or to make arrangements for transportation. We are looking forward to meeting with you in San Jose. Sincerely yours, Tom TAYLOR Mike BUCKLEY Martin EUCHNER Paul JONES (meeting manager of this meeting) Terry ANDERSON Sakae OKUBO (document manager of this meeting) Ernst HORVATH ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: [h323forum] Re: Codec negotiation question
by Paul E. Jones 16 Dec '02

16 Dec '02

Paul, Do you mean RFC 2508? In any case, Robert's point is indeed valid. This is where having a specialize GW that multiplexes the RTP streams for delivery over the long-haul is something practical. Perhaps we could take that up as a work item with SG16? It would be reasonable to specify how such an Gateway might function in order to trunk a large number of active calls over long distance. Anyone interested in such a work item? Paul ----- Original Message ----- From: "Paul Long" <plong(a)packetizer.com> To: <h323forum(a)mail.imtc.org> Sent: Monday, December 16, 2002 7:49 PM Subject: [h323forum] Re: Codec negotiation question > Robert, > > Excellent point. I hadn't thought of that. I wonder what happened to > cRTP. Anybody know? That would sure help. > > Paul > > > > > On Mon, 16 Dec 2002 12:53:34 -0500 > > "Paul Long" <plong(a)packetizer.com> wrote: > > > > > I know lots of folks would like a means of expressing exact > > > packetization, but isn't the solution trivial? All you need is a > small > > > FIFO and a few lines of code to re-packetize according to any > internal > > > requirements. Just write incoming frames regardless of size, e.g., > > > 30fpp, to the FIFO, and read whatever size frames you want, e.g., > 80fpp > > > from the FIFO (only read if there are at least X fpp in the FIFO). > > > > DSP hardware is not the only reason for wanting to have the remote > > endpoint send larger packets. We have many clients on long haul > internet > > links (300ms+ ping times), often with a slow tail circuit (ISDN or > even > > modem) and you REALLY want the other end to send more than one G.723.1 > > frame per packet to reduce the significant overhead that there is in > the > > RTP. > > > > > > > > > > It is unfortunate but true that there is no way of expressing a > > > minimum > > > > acceptable number of frames per packet. > > > > > > > > Regards, > > > > Chris > > > > > > > > Paul Long wrote: > > > > > Davide, > > > > > > > > > > There is nothing in the standard that requires the acceptance > of an > > > OLC > > > > > or precludes terminating the call for any reason whatsoever so > both > > > EPs > > > > > are technically compliant. > > > > > > > > > > Packetization in TCS and OLC expresses the _maximum_ frames per > > > packet, > > > > > but several vendors don't understand this simple concept and > > > continue > > > > > to produce products that expect an exact packetization. There > is a > > > good > > > > > chance that that is why EP A is rejecting the OLC. It wants the > > > channel > > > > > opened at exactly 80fpp, although there is no way to express > this > > > in > > > > > H.323. IMO, if this is the reason, that product is broken. > > > > > > > > > > Paul > > > > > > > > > > > > > > >>Hi all, > > > > >> > > > > >>I have a question about a codec negotiation. > > > > >>During H.245 negotiation, endpoint A (master) exports g711A-law > > > with > > > > > > > > > > packetization 80, endpoint B (slave) exports g711A-law with > > > > > packetization 30. After that, endpoint A opens a channel with > > > > > packetization = 20 ms. Endpoint B acknoledges the OLC and tries > to > > > open > > > > > a channel with packetization = 30 ms. > > > > > > > > > >>Here Endpoint A rejects the OLC and the call is disengaged. > > > > >> > > > > >>Does anybody can tell me which endpoint dosn't behave according > to > > > > > > > > > > the H323 standard? > > > > > > > > > >>Thank you in advance. > > > > >> > > > > >>Davide > > > > > > > > > > > > > > > --- > > > > > You are currently subscribed to h323forum as: cwp@isdn- > comms.co.uk > > > > > To unsubscribe send a blank email to %%email.unsub%% > > > > > > > > > > > > > -- > > > > Dr Chris Purvis -- Development Manager > > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down > Road > > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > > Phone: +44 1344 899 007 > > > > Fax: +44 1344 899 001 > > > > > > > > > --- > > > You are currently subscribed to h323forum as: equival(a)equival.com.au > > > To unsubscribe send a blank email to %%email.unsub%% > > > > > > ---------- > > Robert Jongbloed Equivalence Pty. Ltd. > > Architect Open Phone Abstraction Library (OPAL) & OpenH323 > > Open Source Telecommunication Protocol Libraries > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Quicknet's revolutionary MicroTelco Services offers > > LOW WORLDWIDE RATES ANY TIME OF THE DAY with > > No monthly fees! No monthly minimums! No connection fees! > > US rates as low as 2.9 cents a minute! To see more rates, > > visit www.microtelco.com > > > > > > ****LIVE VIDEO CONFERENCE NOW AVAILABLE***** > > CUseeMe v5.0 software is an affordable easy-to-use software > > application providing live visual communication between friends, > > family and colleagues worldwide. To learn more, visit, > > www.cuseemeworld.com > > --- > You are currently subscribed to h323forum as: paulej(a)packetizer.com > To unsubscribe send a blank email to leave-h323forum-27407I(a)mail.imtc.org > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

AW: Rapporteur meeting in February 2003
by Sebestyen Istvan ICN M SR 3 16 Dec '02

16 Dec '02

Dear Mr. Okubo, Thanks. For mid February also a one day WP3 meeting in Geneva was planned to make "consent" for H.264. Has that also gone away? Regards, Istvan Sebestyen -----Ursprungliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@MXZ.MESH.NE.JP] Gesendet: Montag, 16. Dezember 2002 05:12 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Fwd: Rapporteur meeting in February 2003 Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

AW: Rapporteur meeting in February 2003
by Sebestyen Istvan ICN M SR 3 16 Dec '02

16 Dec '02

So, how then are the plans concretely? On March 11-15, 2003 there is an MPEG Meeting in Pattaya. So, H.264 goes to FDIS. But: 1) When and where is the JVT Meeting? 2) When and where is the WP3 Meeting? Kind regards, Istvan -----Ursprüngliche Nachricht----- Von: Gary Sullivan [mailto:garysull@microsoft.com] Gesendet: Montag, 16. Dezember 2002 12:05 An: Sebestyen Istvan ICN M SR 3; ITU-SG16(a)echo.jf.INTEL.COM Betreff: RE: Rapporteur meeting in February 2003 Yes, we are planning for WP3 consent for H.264/AVC sometime between March 15 and March 30. This will let us consent a better draft and coordinate better with the ISO/IEC approval process. Best Regards, -Gary S. _____ From: Sebestyen Istvan ICN M SR 3 [mailto:istvan.sebestyen@SIEMENS.COM] Sent: Mon 12/16/2002 2:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Rapporteur meeting in February 2003 Dear Mr. Okubo, Thanks. For mid February also a one day WP3 meeting in Geneva was planned to make "consent" for H.264. Has that also gone away? Regards, Istvan Sebestyen -----Ursprungliche Nachricht----- Von: OKUBO Sakae [ mailto:okubo@MXZ.MESH.NE.JP <mailto:okubo@MXZ.MESH.NE.JP> ] Gesendet: Montag, 16. Dezember 2002 05:12 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Fwd: Rapporteur meeting in February 2003 Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Fwd: Rapporteur meeting in February 2003
by OKUBO Sakae 15 Dec '02

15 Dec '02

Dear Q.D,F,G,1-5/16 experts, The conclusion last week in Awajishima, Japan, was that Q.6/WP3 would not meet as a whole next February. So we will meet in San Jose during 11-14 February 2003 according to 2/ below. Mr. Jones will issue the meeting notice very soon. At 16:23 +0900 02/12/07, OKUBO Sakae wrote: >[...] >Rapporteurs have been seeking the best place to hold this meeting. >This is to report the progress. > >1/ As default, we will meet in Geneva to handle video related topics >with Q.6 experts who will meet there for WP3 consent of H.264. > >2/ In case Q.6 and WP3 should not meet at that time depending on the >interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or >Raleigh, thanks to the offer of Cisco. > >3/ Q.6 is now working in Japan and will have a definite answer next >Friday if they meet in Geneva during the mentioned week next >February. So our final decision will be made at that time. Please >stay tuned on this mailinglist. > >4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, >and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Fwd: AAP Comments during last call on H245v9
by OKUBO Sakae 13 Dec '02

13 Dec '02

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" This is to forward Mr. Anderson's announcement, which should have been distributed through this reflector but looks not having gone through. Please also note that you can find the mentioned Avaya's comments in Word form at the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/lc1_H245_Avaya.zip """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" >Date: Fri, 13 Dec 2002 18:20:24 -0500 >From: Terry L Anderson <tlatla(a)verizon.net> >X-Accept-Language: en-us, en >To: ITU SG-16 <ITU-SG16(a)mailbag.cps.intel.com>, tsg16q3@itu.int,tsgwp2@itu.int >Subject: AAP Comments during last call on H245v9 >X-Authentication-Info: Submitted using SMTP AUTH PLAIN at >out002.verizon.net from [138.89.124.43] at Fri, 13 Dec 2002 17:20:35 >-0600 >X-OriginalArrivalTime: 13 Dec 2002 23:15:45.0551 (UTC) >FILETIME=[908EF9F0:01C2A2FD] >Sender: owner-tsg16q3(a)itu.int >Reply-To: Terry L Anderson <tlatla(a)verizon.net> >X-Biglobe-VirusCheck: Sat, 14 Dec 2002 08:21:17 +0900 > >A new version of H.245 (version 9) was consented at the October >Study Group 16 meeting in Geneva. One official comment was submitted >by Avaya against H.245 V9 during the last call period. According to >ITU procedures we need to resolve this issue and then have an >"additional review" (a second last call) before it can be considered >approved. > >The issue raised by Avaya concerned the use of encrypted media >channels for MoIP and included specific suggestions for additional >ASN.1 items and description in H.245 to support this. The changes >are not extensive. > >From the comment: > >>Introduction >>As it now stands, version 9 of H.245 does not permit the >>specification of encryption of media channels using the new >>Modem-over-IP (MoIP) data types RedundancyEncoding, >>MultiplePayloadStream, and FECdata. Inasmuch as these types of >>channels can be subject to eavesdropping, and can carry the same >>information as other audio or data channels, it seems appropriate >>to provide the means to encrypt them. > >The issue and suggested changes have been discussed by several of >parties involved with the MoIP work (Paul Jones, Cisco, Martin >Euchner and Sasha Ruditsky along with Bob Gilman from Avaya) and >they support the suggested changes. > >As rapporteur, I am proposing that adopt the suggested changes and >submit the revised version for the Additional Review at the next >review period (I believe in January) unless there are objections >from others. Any discussion should be sent to the >ITU-SG16(a)mailbag.cps.intel.com reflector. I am including the >tsg16q3 and tsg16wp2 lists in this message so that all interested >parties are aware of the process. If I do not see any objections by >17:00 UT a week from today, Dec 20, we will proceed with the >additional review of the text as revised. > >For those with TIES logins, the Avaya comment document can be accessed at: > http://www.itu.int/itudoc/itu-t/aap/sg16aap/recaap/h245v9/lcc/index.html > >For any that may not, I will summarize the changes below: >1. Annex A (page 47) >Add the new data types RedundancyEncoding, MultiplePayloadStream, >and FECdata to H235Media. This will permit the specification of >encryption for these data types in the same way it is specified for >other media types. > >As follows: >H235Media ::=SEQUENCE >{ > encryptionAuthenticationAndIntegrity >EncryptionAuthenticationAndIntegrity, > mediaType CHOICE > { > nonStandard NonStandardParameter, > videoData VideoCapability, > audioData AudioCapability, > data DataApplicationCapability, > ..., > redundancyEncoding RedundancyEncoding, > multiplePayloadStream MultiplePayloadStream, > fec FECData > }, > > ... >} >---------------------------------------- >2. Annex B, Section B.3.1 (page 108) >Add a description of the use of H235Media in DataType to indicate >that the channel is to be encrypted. > >As follows: >A dataType of h235Media is used to specify encryption of the logical >channel; the actual >data type is indicted within H235Media, along with the encryption >specification. >----------------------------------------- >3. Annex B, Section B.3.1 (page 111) >Add a description of the use of redundancyEncoding for media >encryption when the dataType specifies multiple payload types within >the channel. > >As follows: >When encryption is specified for a channel carrying multiple >payloads, redundancy encoding using RFC 2198 is used to preserve the >actual payload types transmitted. The Encapsulating payload type is >set to the value specified in the syncFlag field of the >encryptionSync element. > >-- >------------------------------------------------------- >Terry L Anderson tlatla(a)verizon.net >Voice: +1 908.766.4463 Mobile: +1 908.342.9595 >http://www.gti.net/tla >------------------------------------------------------- -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

AAP comments during last call on H245v9
by Terry L Anderson 13 Dec '02

13 Dec '02

A new version of H.245 (version 9) was consented at the October Study Group 16 meeting in Geneva. One official comment was submitted by Avaya against H.245 V9 during the last call period. According to ITU procedures we need to resolve this issue and then have an "additional review" (a second last call) before it can be considered approved. The issue raised by Avaya concerned the use of encrypted media channels for MoIP and included specific suggestions for additional ASN.1 items and description in H.245 to support this. The changes are not extensive. From the comment: > Introduction > As it now stands, version 9 of H.245 does not permit the specification > of encryption of media channels using the new Modem-over-IP (MoIP) > data types RedundancyEncoding, MultiplePayloadStream, and FECdata. > Inasmuch as these types of channels can be subject to eavesdropping, > and can carry the same information as other audio or data channels, it > seems appropriate to provide the means to encrypt them. The issue and suggested changes have been discussed by several of parties involved with the MoIP work (Paul Jones, Cisco, Martin Euchner and Sasha Ruditsky along with Bob Gilman from Avaya) and they support the suggested changes. As rapporteur, I am proposing that adopt the suggested changes and submit the revised version for the Additional Review at the next review period (I believe in January) unless there are objections from others. Any discussion should be sent to the ITU-SG16(a)mailbag.cps.intel.com reflector. I am including the tsg16q3 and tsg16wp2 lists in this message so that all interested parties are aware of the process. If I do not see any objections by 17:00 UT a week from today, Dec 20, we will proceed with the additional review of the text as revised. For those with TIES logins, the Avaya comment document can be accessed at: http://www.itu.int/itudoc/itu-t/aap/sg16aap/recaap/h245v9/lcc/index.html For any that may not, I will summarize the changes below: 1. Annex A (page 47) Add the new data types RedundancyEncoding, MultiplePayloadStream, and FECdata to H235Media. This will permit the specification of encryption for these data types in the same way it is specified for other media types. As follows: H235Media ::=SEQUENCE { encryptionAuthenticationAndIntegrity EncryptionAuthenticationAndIntegrity, mediaType CHOICE { nonStandard NonStandardParameter, videoData VideoCapability, audioData AudioCapability, data DataApplicationCapability, ..., redundancyEncoding RedundancyEncoding, multiplePayloadStream MultiplePayloadStream, fec FECData }, ... } ---------------------------------------- 2. Annex B, Section B.3.1 (page 108) Add a description of the use of H235Media in DataType to indicate that the channel is to be encrypted. As follows: A dataType of h235Media is used to specify encryption of the logical channel; the actual data type is indicted within H235Media, along with the encryption specification. ----------------------------------------- 3. Annex B, Section B.3.1 (page 111) Add a description of the use of redundancyEncoding for media encryption when the dataType specifies multiple payload types within the channel. As follows: When encryption is specified for a channel carrying multiple payloads, redundancy encoding using RFC 2198 is used to preserve the actual payload types transmitted. The Encapsulating payload type is set to the value specified in the syncFlag field of the encryptionSync element. -- ------------------------------------------------------- Terry L Anderson tlatla(a)verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Rapporteur meeting in February 2003
by Even, Roni 08 Dec '02

08 Dec '02

Mr Okubo, Is the meeting Tuesday till Friday? Thanks Roni Even Polycom > -----Original Message----- > From: OKUBO Sakae [mailto:okubo@MXZ.MESH.NE.JP] > Sent: Saturday, December 07, 2002 9:23 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Rapporteur meeting in February 2003 > > > Dear Q.D,F,G,1-5/16 experts, > > At 01:18 +0900 02/10/26, OKUBO Sakae wrote just after the October > SG16 meeting ended: > >Please note that the next Rapporteur meeting is planned during 11-14 > >February 2003. Its details are yet to be fixed. > > Rapporteurs have been seeking the best place to hold this meeting. > This is to report the progress. > > 1/ As default, we will meet in Geneva to handle video related topics > with Q.6 experts who will meet there for WP3 consent of H.264. > > 2/ In case Q.6 and WP3 should not meet at that time depending on the > interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or > Raleigh, thanks to the offer of Cisco. > > 3/ Q.6 is now working in Japan and will have a definite answer next > Friday if they meet in Geneva during the mentioned week next > February. So our final decision will be made at that time. Please > stay tuned on this mailinglist. > > 4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, > and myself as document manager. > > -- > Best regards, > > OKUBO Sakae > e-mail: okubo(a)giti.waseda.ac.jp > ******************************************************************* > YRP Office > Global Information and Telecommunication Institute (GITI) > Waseda University > YRP Ichibankan 312 Tel: +81 468 47 5406 > 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 > 239-0847 Japan > > GITI Headquarter > 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 > ******************************************************************* > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Rapporteur meeting in February 2003
by OKUBO Sakae 07 Dec '02

07 Dec '02

Dear Q.D,F,G,1-5/16 experts, At 01:18 +0900 02/10/26, OKUBO Sakae wrote just after the October SG16 meeting ended: >Please note that the next Rapporteur meeting is planned during 11-14 >February 2003. Its details are yet to be fixed. Rapporteurs have been seeking the best place to hold this meeting. This is to report the progress. 1/ As default, we will meet in Geneva to handle video related topics with Q.6 experts who will meet there for WP3 consent of H.264. 2/ In case Q.6 and WP3 should not meet at that time depending on the interim achievements, Q.D,F,G,1-5/16 will meet in the US, San Jose or Raleigh, thanks to the offer of Cisco. 3/ Q.6 is now working in Japan and will have a definite answer next Friday if they meet in Geneva during the mentioned week next February. So our final decision will be made at that time. Please stay tuned on this mailinglist. 4/ For this Rapporteur meeting, Paul Jones acts as meeting organizer, and myself as document manager. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Thanks to Greg Meyer and Chris Hansen
by OKUBO Sakae 07 Dec '02

07 Dec '02

Dear all the subscribers of this mailinglist, This is to announce that the administrator of this mailinglist has changed from Mr. Greg Meyer to Mr. Chris Hansen due to the change of Mr. Meyer's job in Intel. Using this opportunity, I would like to thank Greg for all of his efforts to manage this indispensable tool for the activities of ITU-T SG16 WP2 Questions D,F,G,1-5. Thanks are also to Chris who has kindly undertaken to take care of the mailinglist. Appreciation is extended to Intel Corporation that has been providing the human and network resource to support the SG16 works. Originally KPN had operated this mailinglist service and Intel kindly succeeded it in 1997. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413 239-0847 Japan GITI Headquarter 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 ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

FW: [AVT] Resolution of G.726 payload format endian-issue
by Campos, Simao 15 Nov '02

15 Nov '02

Dear colleagues, for your information. Best regards, Simao -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: 15 November 2002 02:30 To: AVT WG Subject: [AVT] Resolution of G.726 payload format endian-issue This is a summary of the mailing list discussion regarding the packetization of G.726 audio in RTP. This topic is also on the agenda for the AVT meeting next week. Background Based on a request to align the sample packing order with that of ATM AAL2 transport, it was proposed that the draft RTP Profile packetization be changed to be consistent with ITU-T Recommendation I.366.2 Annex E before the draft is published as an RFC. The MIME subtype registrations for G726-16, G726-24, G726-32, and G726-40 in draft-ietf-avt-rtp-mime-06, which refer to the specification of the packetizations in draft-ietf-avt-profile-new-12, would therefore apply to the changed packetization. In addition, RTP static payload type 2, which is bound to the G726-32 encoding and packetization by draft-ietf-avt-profile-new-12, would also change its meaning. The request for input was distributed to the following mailing lists (and perhaps elsewhere): ietf(a)ietf.org avt(a)ietf.org mmusic(a)ietf.org sip(a)ietf.org vpim(a)lists.neystadt.org packetcable-test-codecs(a)cablelabs.com packetcable-codecs(a)cablelabs.com tsg11bicc(a)ties.itu.ch (Study Group 11 Q. 11 (BICC signaling)) tsg11q15(a)ties.itu.ch (Study Group 11 Q. 15 (AAL2 signaling)) ITU-SG16(a)echo.jf.INTEL.COM (Study Group 16) Nortel internal distribution list Summary of Comments All the comments received on the AVT mailing list both when the issue was first raised and in response to the request for input are included below, edited for brevity. The number of comments was surprisingly small, which indicates that there may not be many implementations of G.726 transport in RTP. Only one mentions an implementation of the G726 payload format as specified in draft-ietf-avt-profile-new-12.txt, although there are at least two other implementations: the publicly available RAT audio tool, and one by Magnus Westerlund which was interop tested with RAT. Two comments (from one company) suggest that the existing G726-* payload format specifications remain as is and that new MIME types be defined for the ITU I366.2 packetization. This possibility was discussed at the last IETF meeting in Yokohama. Another comment requested that the payload format remain as it is in the RTP Profile draft because the Voice Profile for Internet Mail (RFC 2421/2) uses the same sample packing. This is consistent with ITU-T Recommendation X.420 for X.400 mail, which means there is an existing inconsistency within ITU-T recommendations. One comment was neutral, but leaning toward preserving backward compatibility (i.e., not changing the payload format). There was one comment in favor of making the change, from the original requester. Conclusion The primary justification for changing the existing MIME types and the static payload type 2 for G726-32 to indicate the ITU I366.2 packetization would be existence of multiple implementations that had implemented the RTP payload format as if it were the same as ITU I366.2. No such implementations were mentioned, even though the original request did say that "many vendors had taken a cue from the AAL2 specifications (approved in 1999) and have designed DSPs that use the I.366.2 ADPCM code word packing rules for RTP". (The G726-32 mode has been in the draft RTP Profile since 1997, but the other rates were added more recently and the draft is not yet published as a standard.) Based on the feedback received, the working group chairs and Area Directors have agreed that the proposed change should NOT be accepted and that the G726-* payload formats specified in the RTP Profile draft should remain as they are. We will specify a new set of RTP payload formats designated by MIME subtypes AAL2-G726-16, -24, -32 and -48 which specify the sample packing in the order of I.366.2 Annex E. If the IESG is willing to have these new payload formats added to the draft RTP Profile in the form of an "RFC Editor note" when the IESG sends its approval of the draft RTP Profile to the RFC Editor, then we will do so. One problem would be that the RTP Profile is to be published as a Draft Standard, which means there should first be two interoperable implementations. Alternatively, a separate draft can be produced quickly to be published as a Draft Standard. At a minimum, we will request that the IESG add the following RFC Editor note in Section 4.5.4 which defines the G726-* formats: Note that the order in which samples are packed into octets in the G726-16, -24, -32 and -48 payload formats for RTP is consistent with ITU-T Recommendation X.420, but it is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -48 will be specified in a separate document. The description of the new AAL2-G726-* payload formats will include a similar but complementary note. Interoperability would have been optimized if there was a single packetization that all agreed to use, but that is not the case. If there are some systems already in the field that use static payload type 2 to indicate packetization according to the draft RTP Profile, and other systems in the field that use static payload type 2 with packetization according to I.366.2 Annex E, then we already have the situation that those systems will produce garbled audio when they interoperate, and the problem won't be detected when the session is established. We can't fix that problem without upgrading those systems. Therefore, we will also deprecate the use of static payload type 2, such that all systems should negotiate a dynamic payload type using the MIME subtypes G726-32 or AAL2-G726-32 depending upon which packetization they want to use. Vendors may be able to ease the transition within their own implementations by offering the dynamic payload type as the preferred value and the static payload type as the secondary value. An upgraded system that implements only G726-32 and receives an offer of a dynamic payload type bound to AAL2-G726-32 along with static payload type 2 but no dynamic payload type bound to G726-32 may want to assume that type 2 also indicates the AAL2 format and reject the call, and vice versa. To implement this deprecation, we will request another RFC Editor note changing the assignment of static payload type 2 in Table 4 of the RTP Profile to be "reserved" rather than "G726-32" and to add the following note in the first paragraph of Section 6: Payload type 2 was assigned to G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved. Similar instructions will go in the IANA Considerations section so that the assignment in IANA's registry is marked as deprecated. Steve Casner Colin Perkins AVT Co-Chairs -------------------------------------------------------------------- Comments received (edited): Date: Wed, 10 Jul 2002 13:58:27 +0200 From: Eli Shoval <elish(a)audiocodes.com> I am sending this as a response to the recent request to change the G.726 packetization in ietf avt profile. We at Audiocodes implemented the G.726 packetization according to ietf avt profile. We object to removing the original G.726 packetization from this standard because it will cause us to change our implementation. Why can't the ITU I366.2 packetization be added as additional vocoder to the ietf avt using dynamic payload type ? In this case if it will have MIME registration with a different name than the regular G726 and if both gateways support it they will be able to communicate. Date: Wed, 17 Jul 2002 22:20:39 -0400 From: Glenn Parsons <gparsons(a)nortelnetworks.com> In response to the G.726 agenda item, I just wanted to chime in VPIM (RFC2421/2) and the current AVT profile are aligned (with little endian). VPIM (and use of G.726) is widely deployed by voice mail vendors. Some of these systems support RTP as well. So I would suggest maintaining this alignment. Date: Tue, 15 Oct 2002 09:47:48 +0200 From: Oren Peleg <OrenP(a)audiocodes.com> Another Proposal could be: For the I.366.2 packetization, make a new MIME registration & Use a Dynamic Payload Type value. Date: Thu, 17 Oct 2002 14:47:59 -0400 From: Tom-PT Taylor <taylor(a)nortelnetworks.com> Consultations within my organization seem to tend toward the point of view that the discrepancy is not a big deal and it would be better to preserve backward compatibility. Date: Thu, 17 Oct 2002 11:34:39 -0700 From: Rajesh Kumar <rkumar(a)cisco.com> We would like to see the packetization of G.726 over RTP be made identical to what is defined for AAL2 in the ITU I.366.2 recommendation. In this regard, we strongly recommend that the audio MIME subtypes G726-16, G726-24, G726-32, and G726-40 be aligned to the ITU I.366.2 recommendation. This alignment would include the static payload type 2. If there is a need to interoperate with the "other," non-ITU packing scheme, we recommend that new MIME types be defined for those non-ITU schemes rather than for ITU-compatible schemes, which we think should be associated with the current MIME definitions. [end] _______________________________________________ Audio/Video Transport Working Group avt(a)ietf.org https://www1.ietf.org/mailman/listinfo/avt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0