September 2009 - sg16-avd - lists.packetizer.com

[itu-sg16] Contributions to the upcoming SG16 meeting
by OKUBO Sakae 09 Dec '09

09 Dec '09

Dear WP2/16 experts, At 12:36 -0400 08/04/10, Sasha Ruditsky wrote: >Attached is the SetSubmode document the SG16 meeting. >I submitted this document to the Israeli MOC in order to be >submitted to ITU-T. > >Can you, please, post it in the informal area as well? At 10:55 +0900 08/04/11, InCheol Jeong wrote: >I sent SG16 paper yesterday. Thank you for your advice. Your Contributions have been placed at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0804_Gen/0804_Gen.html -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

3 4

[itu-sg16] AVD-3813 Handling Of Error Conditions in H.323
by Sasha Ruditsky 14 Oct '09

14 Oct '09

Q2 Experts, The conclusion for the discussion of the AVD-3813 during the last SG16 meeting's was to ask the experts opinion through the mailing list. My apology for the short notice. I hope that we still have time before the next meeting for people to understand the problem and express their opinions. The problem discussed in AVD 3813 is more or less as follows: " H.225.0 gives very little attention to the specification of processing of the H.225.0 Call Signaling messages errors. The only place dedicated to this subject is Clause 7.1 of H.225.0. On the other hand, ITU-T Recommendation Q.931 on which H.225.0 messages are based provides quite detailed information on the same subject. While H.225.0 states that Implementations shall follow ITU-T Rec. Q.931 as specified in H.225.0, there is a lot of confusion surrounding the cases which H.225.0 does not cover and Q.931 does. In addition, ETSI TS 101 804 - 2 defines Conformance Test Specification for ITU-T H.225.0. This test specification apparently based on Q.931 procedures, not on the corresponding H.225.0 ones. More than this, in many cases ETSI TS 101 804 - 2 requests behavior which claims to be based on Q.931, however is not defined neither in Q.931, nor H.225.0. " Apparently "H.323 conformant" not always means "ETSI TS 101 804 - 2 conformant" and I believe we need to find some solution to at least make this particular point clear. I'm going to resubmit AVD-3813. It would be great to be able to get some ideas from the group into the resubmitted document. Thank you, Sasha

2 4

[itu-sg16] H.323 Annex I
by Paul E. Jones 07 Oct '09

07 Oct '09

Q2 Experts, Please review the text for H.323 Annex I: http://ftp3.itu.int/av-arch/avc-site/2009-2012/0906_Gen/AVD-3752.zip This document did not get sufficient review at the last Rapporteur meeting, but I would nonetheless like to consent this text at the upcoming meeting. Annex I was substantially re-written, but it is relatively short and the focus of the document is not changed: it defines the signaling procedures necessary to implement FEC as defined in IETF RFC 5103, which obsoletes the former FEC method detailed in RFC 2733. Going forward, the intent would be that if we want to document anywhere how H.323 devices ought to behave in order to overcome issues with error-prone channels, we might add additional material to this annex (perhaps even restructuring it if necessary). In any case, I would kindly like to request that you review this document. I will make an effort to re-submit it to this meeting unchanged as it appear here. However, if you have any comments on the text, let me know this week or early next week and I'll try to make revisions and share those with the Experts before I submit the text. Of course, you are definitely welcome to submit a contribution related to this text for review at the meeting. Paul

2 3

[itu-sg16] Meeting Notice of Q13/16 Seoul Meeting
by kawamori.masahito＠lab.ntt.co.jp 02 Oct '09

02 Oct '09

Experts of ITU-T SG16 Question 13/16 Multimedia application platforms and end systems for IPTV Cc Mr Y Naito, Chairman of SG16 <Naito.Yushi(a)dr.MitsubishiElectric.co.jp> Ms C Lamblin, Vice Chairman of SG16 <claude.lamblin(a)orange-ftgroup.com> Mr S-H Jeong, Vice Chairman of SG16 <shjeong(a)hufs.ac.kr> Mr N Luo, Vice Chairman of SG16 <noah(a)huawei.com> Mr M Neibert, Vice Chairman of SG16 <markneibert(a)mac.com> Mr I Oueichek, Vice Chairman of SG16 <oueichek(a)tarassul.sy> Mr F Soumah, Vice Chairman of SG16 <drfsuma(a)yahoo.fr> Mr Y Goto, Vice Chairman of WP2/16 <goto(a)ansl.ntt.co.jp> Mr S Campos-Neto, ITU TSB <simao.campos(a)itu.int> De M Kawamori, Rapporteur for Q13/16 <kawamori.masahito(a)lab.ntt.co.jp> --------------------------------------------------------------------- Subject: Notice of Rapporteur Meeting in Seoul, the Republic of Korea Date: 13-17 April 2009 --------------------------------------------------------------------- Dear Experts of Q13/16, The subject meeting of ITU-T SG16 experts will be held in Bundang, the Republic of Korea at the kind invitation of ETRI (Electronics and Telecommunications Research Institute) and TTA (Telecommunications Technology Association) of the Republic of Korea. Details of the meeting are contained herein. 1. Date ^^^^^^^ 13 (Monday) - 17 (Friday) April 2009 Meeting will start at 9:30 on the first day and close around 17:00 on the final day. 2. Venue ^^^^^^^^ TTA 267-2 Seohyeon-dong, Bundang-gu, Seongnam-city, Gyonggi-do, Republic of Korea Phone: +82 31 724 0085 E-mail: ssoh(a)tta.or.kr Home page: http://www.tta.or.kr/English/ 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ - Coordinate with other SDOs, Questions, and Study Groups - Progress work on the following: o H.IPTV-MAP o H.ProComp o H.IPTV-AEH o H.IPTV-AM o H.IPTV-DSMW o H.IPTV-WBTM o H.IPTV-MAFR.2 o H.IPTV-MAFR.4 o H.IPTV-MAFR.5 o H.IPTV-MAFR.6 o H.IPTV-MAFR.8 o H.IPTV-MAFR.13 o H.IPTV-MAFR.14 o H.IPTV-TDES.3 o H.IPTV-TDES.4 o TP.IPTV-CMA o TP.IPTV-CMA o TP.IPTV-SNV o TP.IPTV-WBSD o TP.IPTV-ISPF o TP.IMFR o TP.TDPower o H.IPTV-SDC - Progress work on Rigts Information Interoperability - Discussion of miscellaneous and new work items 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 6 April 2009 /// /// Distribution of the document: by 23:59 UTC, 8 April 2009 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify the document manager of this meeting, as soon as possible, by 23:59 UTC, Monday 6April 2009 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 use the document template available at the following place: <http://ftp3.itu.int/av-arch/avc-site/2009-2012/0904_Seo/> 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 5 calendar days in advance of the meeting (23:59 UTC, Wednesday 8 April 2009 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: <itu-sg16(a)lists.packetizer.com> To subscribe: please visit <http://lists.packetizer.com/mailman/listinfo/itu-sg16> Please avoid the use of reflector when your document is voluminous (i.e., more than 100 kbytes). 5) Input documents can be retrieved from 0904_Seo directory of the ftp site once Mr Jones has an opportunity to put them into place. The documents will be available through the following URLs: <http://ftp3.itu.int/av-arch/avc-site/2009-2012/0904_Seo> <ftp://ftp3.itu.int/avc-site/2009-2012/0904_Seo/> user: avguest, password: Avguest 6) The document distribution/presentation at the meeting will be all electronic. Participants must bring along a laptop, wireless LAN card and/or Ethernet card, in order to access the documents (Internet access will be available in the meeting rooms). Note: make sure you have the right power adapter for the Republic of Korea, see <http://wikipedia.org/wiki/Domestic_AC_power_plugs_and_sockets> type C (2-pin CEE 7/17, German/French unearthed). 5. Logistic Information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting logistic information can be found at: http://ftp3.itu.int/av-arch/avc-site/2009-2009/0904_Seo/Seoul_practical_inf… 6. VISA Information ^^^^^^^^^^^^^^^^^^^ Experts are advised to check about regulations regarding VISA. In case of doubt, the information can be obtained from the nearest Korean Embassy or Consulate as well as the following website: <http://www.mofat.go.kr/english/main/index.jsp?lang=eng> If needed, please return the form provided in the Annex B of the Practical Information to Ms. Oh, Sesoon, no later than 13 March 2009 for the processing of formal invitation letter. E-mail: ssoh(a)tta.or.kr Phone : +82-31-724- 0085 Fax: +82-31-724-0119 or +82-31-724-0109 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please check with the Annex A of the Practical Information. We are looking forward to meeting you in Seoul/Bundang. Sincerely yours, Masahito KAWAMORI (meeting organizer of this meeting) ----------

4 6

[itu-sg16] FW: [T16AVD] Request for input to the "Multiple video streams FECC AHG"
by Paul E. Jones 28 Sep '09

28 Sep '09

FYI From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, September 25, 2009 3:31 PM To: t09sg16avd(a)lists.itu.int Subject: [T16AVD] Request for input to the "Multiple video streams FECC AHG" I would remind you all of the following item in the Q1/16 Experts Meeting Report (24-25 June 2009): >>> 2.3 H.281 and changes for supporting multiple video streams Q1-I08 was presented and a short discussion followed. The group noted the limitations and considerations raised by the contribution. It was noted that, if the solution would involve enhancements to both H.281 and H.224, it would be desirable to consent those recommendations at the same time. Because of the absence of several experts, the proponent himself and not being able to fully discuss this topic, Q1 experts agreed to create an Ad-hoc group (chaired by S. Botzko) to progress this work through electronic correspondence in the interim period. The contributor was asked to submit a contribution to the next meeting of SG16 to allow a continuation of the discussion. Experts interested in participating in this work are encouraged to contact the Rapporteur and/or the AHG Chair. >>> Feedback on these approaches would be appreciated - please reply to this email. If desired, contact me directly and I will set up a meeting. Alternatively, interested parties can communicate through email. At this point I see three possible ways to progress the work: (1) Use the Q1-I08 contribution (June 2009 meeting) as the basis This contribution proposes "channeling" the existing H.281 messages, so that the video channel can be carried in the new messages. Backwards compatibility is provided since the existing messages are still used for the main video channel. Existing H.281 clients would not be able to control the second (or third) channels. (2) Use the C-0399 contribution (April 2008 meeting) as the basis This contribution proposes adding a second H.224 CME client id for the second video channel. Backwards compatibility is provided since the existing client ID is still used for the main video channel. Existing H.281 clients would not be able to control the second (or third) channels. (3) Revise H.281 Video Source Capability to include a channel number (Figure 10/H.281) There is no contribution (yet) for this approach. This idea proposes specifying the channel number within the existing H.281 Video Source Capability for sources 6-15. The channel is transmitted in ASCII in the existing camera name. Backwards compatibility is provided since existing clients can decode this message. This idea allows existing H.281 clients to control the cameras for both video channels - it is the only current proposal which does this. The syntax of only one message in H.281 is slightly adjusted. The existing video source capability for these sources looks like this: 8 7 6 5 4 3 2 1 4-bits encoded Video Source Reserved Motion video Normal resolution still image Double resolution still image Up to 16 ASCII encoded characters All zeros octet Pan Tilt Zoom Focus Reserved The revision is to set the Reserved Bit if the Video Source is sending on a secondary video channel. If the reserved bit is set, the first character of the source name is a channel number (in ASCII), the second character is a space. The remaining 14 characters have the existing meaning. This is backwards compatible, since if the reserved bit is ignored the message can be decoded properly by existing receivers. An alternative is to leave the reserved bit alone - since use of these extended sources is rare, this might be sufficient. All three approaches share a common issue. H.323 and H.320 video channel numbering is not preserved end-to-end. Therefore, sometimes the user may discover that they are moving the camera for the "wrong" video stream. One solution is bind the channels to H.239 role labels, which are preserved. For instance, use channel 0 for main, channel 1 for presentation, and channel 2 for live. Expanding beyond 2 channels could be done by adding new role labels to H.239. Stephen Botzko Chair - Multiple video streams FECC AHG Polycom +1 978 292 5395

1 0

[itu-sg16] unsubscribe
by Enrico Marocco 24 Sep '09

24 Sep '09

-- Ciao, Enrico

1 0