- sg16-avd - lists.packetizer.com

[itu-sg16] Q13 Meeting Documents Posted
by Paul E. Jones 06 Oct '08

06 Oct '08

Q13 Experts, All documents for the Q13 meeting have been receive and are posted here: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0810_Bus/ I will keep the 0810_Bus.html file updated as I receive document requests during the course of the meeting, all of which will be assigned a TD number. I will the revise TD-02 at the end of the meeting with the final document list. If you have any questions, please don't hesitate to ask. Kindest Regards, Paul

1 0

[itu-sg16] Q13 document deadline approaching
by Paul E. Jones 04 Oct '08

04 Oct '08

Q13 Experts, I have posted the list of documents for which numbers have been requested. There are two additional liaison statements to which I may assign numbers once I get clarification on their status. However, all person who requested a number should have received one. If you did not, please let me know. Also, I will expect all documents to be posted by 23:59 UTC, 5 October 2008 either to the /Incoming directory or sent to me by e-mail. I will then post the documents received within 24 hours. The current list of documents and links to available documents is here: http://wftp3.itu.int/av-arch/avc-site/2005-2008/0810_Bus/0810_Bus.html Thanks, Paul

1 0

[itu-sg16] Q13 Meeting Document Registration Deadline is October 13
by Paul E. Jones 01 Oct '08

01 Oct '08

Q13 Experts, I just want to send a gentle reminder that the deadline for registering documents for the upcoming Q13 meeting is 3 October 2008. If you plan to submit a document to this meeting, please let me know. I have allocated all document requests received thus far and the list of documents is here: http://wftp3.itu.int/av-arch/avc-site/2005-2008/0810_Bus/0810_Bus.html Kindest Regards, Paul E. Jones

1 0

回复:RE: RE: [itu-sg16] Q22 Question - SATC
by zourong 52447 27 Sep '08

27 Sep '08

Paul, you are a smart hacker, DPI can not stop you,:-). DPI hardly can tackle encrypted communication now, but this do not prevent DPI from getting more and more market deployment. Maybe someday,most internet communications will be encrypted to circumvent such kind of inspection, then I think new techonolgies will be devised to face these embarrassment. Anyway, I think content protection like copyright protection is a interesting area that worth doing something. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- 原邮件 ----- 发件人: "Paul E. Jones" <paulej(a)packetizer.com> 日期: 星期五, 九月 26日, 2008 下午2:06 主题: RE: RE: [itu-sg16] Q22 Question - SATC 收件人: 'zourong 52447' <zou.rong(a)huawei.com> 抄送: ''Noah Luo ' ("罗忠")' <noah(a)huawei.com> > Rong, > > You are right that current file sharing networks (mostly) do not use > encryption. But, they would if necessary. In fact, I have a file > sharingprogram on my machine that does offer encryption for file > transfers. If > such measures were employed to block traffic, I think all tools > would simply > encrypt contents by default. One could try to guess the contents > of the > encrypted file by looking at such things as the file length, etc., but > nothing is perfect. > > I can accept that no solution is perfect, but I honestly believe > that this > one just will not work in practice. I used to be one of the kids > in high > school that would remove copy protection from software products by > manuallyaltering machine code right on the disk. I even wrote my > own utilities to > allow me to modify code on disk -- and I wrote that in assembly > language. > Lawful intercept works for a few reasons: > 1) Most criminals are stupid and use public communication > 2) Almost everybody connects to a carrier network to carry voice -- > so > carriers become a natural intercept point > > Lawful intercept does not work for smart criminals. They use secure > communication channels. > > But, we can't really compare this to Lawful Intercept. Normal > users just > use the tools that are out on the Internet. If I were writing a file > sharing program and encountered packet filtering issues, I would > immediatelyemploy encryption. I could write the necessary code in > an afternoon and > effectively defeat systems employed to stop it. And, those systems > are all > very expensive hardware-based solutions that would be rendered > useless. > Honestly, I'm not trying to be an irritant :-) But, I'm quite > doubtful that > any DPI scheme can work to stop the proliferation of copyrighted > material.It's simply too easy to devise a work-around in software > and, while the DPI > logic can get more complicated, the algorithms in a PC-based > application can > be revised and updated far more rapidly. Heck, I would even have > the packet > encoding algorithms written in such a way as to be downloadable > when the > program starts. That way, the newest encoding algorithms are always > available every time the program starts. > > Paul > > > -----Original Message----- > > From: zourong 52447 [mailto:zou.rong@huawei.com] > > Sent: Thursday, September 25, 2008 11:48 PM > > To: Paul E. Jones > > Cc: 'Noah Luo ' ("罗忠") > > Subject: 回复:RE: [itu-sg16] Q22 Question - SATC > > > > Paul， > > > > Sorry for taking so long to respond to your mail because I have > taken a > > long vacation and then followed by a busy business trip. > > > > I agree with you that the method proposed in my contribution AVD > 3541> is not a perfect solution to the copy-right protection > issue. It could > > not handle the case that the communication is encrypted ?C as you > > mentioned. > > In fact, I think it is one of the limitations of DPI technology. The > > signature-based DPI technology could not inspect the encrypted data > > flow. But I still believe that it could work and do something > useful in > > a broad range of use cases, just like the lawful interception: it > > hardly could handle the encrypted communication but it still can > work> well. > > > > As to your suspicion whether it could work in a practical > situation.> I hope it could work in some public file sharing > scenarios especially > > the P2P file sharing. Why I put my effort in study the P2P file > sharing> scenario is that P2P file sharing is the most popular > file sharing > > tools nowadays and most of the files being shared are multimedia > files> and many of them are pirated. > > > > P2P file sharing has one important character that could be > exploited:> the file information is almost public. It should let > people know what > > the resource is, for example, the file name, file type, file > size, file > > hash value etc., these file describe information will be > transmitted in > > the file sharing control messages and could be intercepted by SATC. > > > > Another character of P2P file sharing is that it seldom uses > encrypted> communication because that will bring burden to its > efficiency and > > affect its popularity. > > > > Then to the question of “good database” and “suspicious database”. > What > > I want to do is a multi-level inspection and filter. It maybe > works as > > following: > > > > Extracting_file_information(); > > Searching_good_database(); > > If(got matched item) > > { > > Compare_signature(); > > If(match) > > { > > It is copy-righted file and transmitted; > > } > > Else > > { > > Searching_suspecious_database(); > > If(match) > > { > > It is a known pirated version, stop it; > > } > > Else > > { > > It maybe a new pirated version, record it temporality > > and notify the content provider to make sure and to update the > > suspicious database ; > > Transmit_flow(); > > } > > } > > } > > > > In this multi-level filtering, the first level ”good database” > > filtering can be performed with the help of a reasonably small- > sized> database and achieve rather fast processing speed, the > second level > > ”suspicious database” filtering may require a much bigger > database. But > > only searching only a part of them each time also could yield > > reasonable processing speed. > > > > So that is what I want to do, only those truly pirated file sharing > > will be stopped right now, other suspected file sharing will be > > recorded and let the technicians to do further judgment. > > > > > > > ***********************************************************************> ******************* > > This email and its attachments contain confidential information > from> HUAWEI, which is intended only for the person or entity > whose address > > is listed above. Any use of the information contained here in > any way > > (including, but not limited to, total or partial disclosure, > > reproduction, or dissemination) by persons other than the intended > > recipient(s) is prohibited. If you receive this email in error, > please> notify the sender by phone or email > > immediately and delete it! > > > > > ***********************************************************************> ****************** > > > > ----- 原邮件 ----- > > 发件人: "Paul E. Jones" <paulej(a)packetizer.com> > > 日期: 星期五, 九月 12日, 2008 上午11:50 > > 主题: RE: [itu-sg16] Q22 Question - SATC > > 收件人: 'Noah Luo(罗忠)' <noah(a)huawei.com> > > 抄送: zou.rong(a)huawei.com > > > > > Noah, > > > > > > I have no objection to exploring the idea. But, I'm 100% certain > > > it will > > > not work :-) I am various serious about that. When I was a > > > teenager, I > > > spent a lot of time removing copy protection from software > (actually> > modifying the machine code by hand), hacking computer > systems,> > etc. Even > > > when I was in college, I had a professor who called me an > > unscrupulous > > > hacker. He was only half joking. He had a real admiration > for my > > > technicalability, but wasn't very happy with some of the > hacking I > > > used to do. > > > Still, he recognized that I was a good kid who just wanting to > > > explore and > > > learn as much as possible. > > > > > > I used to play with viruses. I would even write some that would > > > not cause > > > harm -- they would never replicate. Rather, they would just run > > > in the > > > background of machines that I placed them on, loading into the > > > system at > > > boot time. I still have a collection of probably 1,000 virus > > > files, many > > > with the assembly code. > > > > > > The short of it is that I have a lot of experience at this > sort of > > > thing.While I don't do the hacking I did when I was a kid, I can > > > guarantee you > > > that there will be some just ready to tackle the challenge of > > > breaking any > > > kind of defense like what this standard intends to provide. And, > > > as I said, > > > the simplest thing to do is simply use TLS. In fact, I could > > exchange > > > pirated music or video via e-mail between my server at home and > > > anybody else > > > who uses TLS -- my servers all use encryption. But, we can > > > certainly employ > > > simpler techniques. For example, I could do this: > > > > > > K = 256_bit_random_key; > > > while(not_end_of_file) > > > { > > > M = read_file(16 octets of the file); > > > Y = M XOR K; > > > transmit_message(Y); > > > K = rotate_right(K); > > > } > > > transmit_message(K); > > > > > > This is a very simple and extremely fast encryption algorithm that > > > willactually transmit the session key at the end. So, there > is no > > > secrethidden, but it avoids the need of exchanging encryption keys > > > some other way. > > > This is not a flawless procedure, though. In fact, this is very > > > easy to > > > "crack", since we're just XORing the bits of the input stream with > > > the key > > > and then rotating the key 1 bit after each message. If an input > > > stream had > > > a number of 0s, then the key would appear as repeated data blocks > > > that can > > > be easily identified by a cryptography person. Heck, even I would > > > recognizethe pattern. But, this might still be complex enough to > > > avoid real-time > > > detection of pirated content. But, I could just as easily use AES > > and > > > *really* encrypt the media and place the 256-bit initialization > > > vector and > > > key at the end of the transmitted media stream :-) > > > > > > Anyway, like I said-- I have no objections to studying this. I > > > just am just > > > a firm believer that it will only stop the casual pirates: those > > > who want to > > > use gmail.com or something to send an e-mail containing music. > It > > > would not > > > stop software designed for secure file exchange, either person- > to- > > > person or > > > across file sharing networks. > > > > > > My primary concern now is with the wording in the report. Rong > > > felt it was > > > OK, but I still think it's wrong. It says: > > > "... if SATC finds a data stream carrying content failing to match > > > a known > > > signature, it will block the stream or mark it as being > suspicious.”> > > > > Worded another way, this sentence says: "if the data stream > > > contains an > > > unknown data stream, block the data stream." > > > > > > Now that would actually work to block pirated content, because you > > > essentially only let known data through the network. But, I don't > > > thinkthat is the intent, and it's definite not what the AVD > > > document said. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Noah Luo(罗忠) [mailto:noah@huawei.com] > > > > Sent: Thursday, September 11, 2008 5:46 AM > > > > To: 'Paul E. Jones' > > > > Cc: zou.rong(a)huawei.com > > > > Subject: 答复: [itu-sg16] Q22 Question - SATC > > > > > > > > Dear Paul > > > > Thank u very much for your good analysis and insightful > comments on > > > > this > > > > specific aspect SATC.I will work together with Rong and come up > > > with a > > > > solution as to how the Q22 meeting report will be appropriatedly > > > > reworded.Based on C3541 itself,actually, Q22 meeting report just > > > > faithfully > > > > reflects the basic idea of the scheme described.But if we > also take > > > > into > > > > account the supplementary information Rong provided in his mail > > > to you, > > > > then > > > > Q22 report may need incorporate some more information. > > > > > > > > As for your questions regarding the feasibility of using > signature> > > matching > > > > to block pirated contents transmission.I agree that we need more > > > > careful > > > > consideration.I think it will be ideal if more contributions > > > will be > > > > submitted by Rong to the next SG16 meeting so that we can > have more > > > > extensive discussion.My personal feeling is that it is a rather > > > > innovative > > > > idea to use this kind of techniques to block illegally > distributed> > > contents, > > > > but there may still lack some feasible technical points to > > > enable this > > > > idea > > > > to be transformed into a practical solution. > > > > > > > > Paul, do you think this arrangement will be okay? > > > > > > > > Best Regards > > > > > > > > Noah > > > > > > > > > > > > 华为技术有限公司 huawei_logo > > > > > > > > > > > > 地址：深圳市龙岗区坂田华为基地邮编：518129 > > > > http://www.huawei.com > > > > ------------------------------------------------------------- > ---- > > > ------ > > > > ----- > > > > --------------------------------------------------------- > > > > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人 > 或群 > > > > 组。禁 > > > > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散 > 发）本 > > > 邮 > > > > 件中 > > > > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > This e-mail and its attachments contain confidential information > > > from> HUAWEI, which > > > > is intended only for the person or entity whose address is > listed> > > above. Any > > > > use of the > > > > information contained herein in any way (including, but not > > > limited to, > > > > total or partial > > > > disclosure, reproduction, or dissemination) by persons other > > > than the > > > > intended > > > > recipient(s) is prohibited. If you receive this e-mail in error, > > > please> notify the sender by > > > > phone or email immediately and delete it! > > > > > > > > -----邮件原件----- > > > > 发件人: itu-sg16-bounces(a)lists.packetizer.com > > > > [mailto:itu-sg16-bounces@lists.packetizer.com] 代表 Paul E. Jones > > > > 发送时间: 2008年9月11日 10:48 > > > > 收件人: 'zourong 52447' > > > > 抄送: itu-sg16(a)lists.packetizer.com > > > > 主题: Re: [itu-sg16] Q22 Question - SATC > > > > > > > > Rong, > > > > > > > > I think the meeting report is not exactly correct. The Q22 > meeting> > > report > > > > said that SATC would block content that that failed to match a > > > > signature. > > > > What you said is that SATC would block media content that > > > matches a > > > > "good" > > > > signature, but is apparently altered in some way. That is, it > > would > > > > block > > > > media that it can clearly identify as pirated content. > > > > > > > > So, perhaps we should revise the wording that is presently in > > > the Q22 > > > > meeting report related to AVD-3541. Can you consult Noah on > > > what the > > > > correct statement should be? > > > > > > > > As for whether this will work, I still have doubts. Even > storing> > > signatures > > > > of all current media could be a massive database and, quite > > > likely, one > > > > that > > > > would need to be in memory, as you need real-time (and likely > > > wire- > > > > speed) > > > > access to the signatures. > > > > > > > > I have no objection to doing work on this: if you can meet a > > > particular> business requirement, great. But, I personally think > > > that trying to > > > > match > > > > against signatures will not stop any serious pirate. It might > > > stop the > > > > casual pirate, though. > > > > > > > > A data stream of pirated content can be altered in so many ways > > > that it > > > > would be easy for somebody to create a program to stream pirated > > > > content > > > > that does not match a signature in the database. I could run > > > the media > > > > stream through a cipher algorithm, for example. And, I > could even > > > > transmit > > > > the cipher key as the last payload of the message: after > all, the > > > > entire > > > > file has been delivered! Secrecy wasn't the purpose of the > > > encryption,> but > > > > merely to disguise what is being transmitted until we've > > > successfully> bypassed the SATC "detectors". > > > > > > > > Perhaps the simplest thing to do, actually, given the wide > > > > proliferation of > > > > tools like OpenSSL, is to just use TLS between nodes that > want to > > > > transmit > > > > pirated content. That provide more-than-acceptable level of > > > > encryption. > > > > > > > > In any case, I did not intend to bring the work to a halt, > by any > > > > means. > > > > But, be cognizant of the fact that this is a very complex > > > problem and I > > > > seriously doubt you can devise a method that would prevent a > good> > > hacker > > > > from getting around the system. At best, you will only stop the > > > casual> "pirates". You would not stop serious pirates or popular > > > "file> sharing" > > > > software. Such software would definitely employ techniques > to get > > > > around > > > > any detection/blocking logic in the router/switch. > > > > > > > > What's more important right now is understanding what should > > > have been > > > > stated in the meeting report. I do not think this sentence is > > > > accurate: > > > > > > > > “... if SATC finds a data stream carrying content failing to > > > match a > > > > known > > > > signature, it will block the stream or mark it as being > > suspicious.” > > > > > > > > Paul > > > > > > > > > -----Original Message----- > > > > > From: zourong 52447 [mailto:zou.rong@huawei.com] > > > > > Sent: Wednesday, September 10, 2008 4:05 AM > > > > > To: paulej(a)packetizer.com > > > > > Cc: itu-sg16(a)lists.packetizer.com > > > > > Subject: [itu-sg16] Q22 Question - SATC > > > > > > > > > > Paul, > > > > > really thanks your's comments, here is the clarification. > > > > > 1) As to the circumventing problem, I really could not say > > > their is > > > > > a perfect way that could not be circumvented. But I don’t > > > think it is > > > > > easy to do so. This scenario is attempted to provide a > tool for > > > > content > > > > > provider to prevent their “specially processed” content, i.e. > > > copy- > > > > > righted content from being pirated. It is assumed the > “specially> > > > processed” content have some characteristic > information that > > > would be > > > > > destroyed by any piratical actio > > > > > n such as using a different decoding method, and these > > > characteristic> > information or “signature” would be provided to > > > SATC system by > > > > content > > > > > provider. As to the compress scheme to circumvent, I think the > > > SATC> > could handle most of the common compress schemes such as > > > winzar,> > winzip, tar etc., but I also think it is impossible the > > > SATC could > > > > > handle all compress schemes. > > > > > 2) The method mentioned in AVD-3541 is not attempted to create > > a > > > > > database of all pirated media, it’s a database that store the > > > > > signature of good media especially those most popular > video or > > > audio> > recently, so the database will keep in a state of > > > acceptable size. > > > > The > > > > > periodical updating of the database is necessary just like the > > > IDS do > > > > > to update the anti-virus database. > > > > > 3) The pirated media database could exist as an subsidiary > > > database.> > This was not mentioned in the AVD-3541 because I > > > think it maybe too > > > > > detail to describe it in a scenario. The file transmitted > will be > > > > > suspected as pirated file when satisfied following two points: > > (1) > > > > > There is a item in the “good media database” that means the > > > file is a > > > > > target of protecting. (2)the signature of the file transmitted > > > do not > > > > > match with that stored in the data > > > > > base. Then the suspected file could be blocked directly, > or in > > > a more > > > > > prudent way, it could be just marked as suspicious and search > > > in a > > > > > subsidiary “pirated media database” to make sure it is a > existing> > > > pirated version or it maybe a new pirated version > and need more > > > > manual > > > > > analytical works of content provider. > > > > > 4) As to the performance problem, I think this kind of > > inspection > > > > > may have some negative impact on the packet transmission but > > > may not > > > > as > > > > > terrible as thought, in fact, many DPI product in market can > > > achieve> > 10G to 40G, even 80G throughput, their process > > > capability is > > > > > remarkable. > > > > > > > > > > > > 发件人： Paul E. Jones > > > > > > 发送时间： 2008-09-05 10:59:38 > > > > > > 收件人： itu-sg16(a)lists.packetizer.com > > > > > > 抄送： > > > > > > 主题： [itu-sg16] Q22 Question - SATC > > > > > > > > > > > > Q22 Experts, > > > > > > > > > > > > While reviewing the Q22 meeting report, I was intrigued > by a > > > > > > comment related to AVD-3541. This contribution proposes > > > that SATC > > > > > > can be used to block illegal content from being transmitted > > over > > > > > > the Internet by examining the media flow and comparing that > > > media> > > flow (or some signature thereof) against a database. > > > SATC would > > > > > > then block content as appropriate. > > > > > > > > > > > > I would like to comment: > > > > > > 1) I could easily circumvent any such measure, so > any such > > > > > > system would prove to work only temporarily; and > > > > > > 2) While a given copy of a digital copy of some > > > content, such > > > > > > as music or a movie, will have a clearly recognizable > > signature, > > > > > > the same media can be “substantially” altered by merely > > > using a > > > > > > different encoding method (e.g., a different video codec or > > > > > > compression scheme); and > > > > > > 3) Actually attempting to create a database of all > known> > > > > pirated media, including all variations, would > result in the > > > > > > creation of a massively huge database; and > > > > > > 4) Maintenance of such a database would be a never- > ending> > > > > chore; and > > > > > > 5) Notwithstanding the foregoing, while such a database > > > could> > > be constructed and flows could be examined, inspecting > > > flows in > > > > > > real-time and trying to positively identify a given flow > is a > > > > > > monumental task that will result in significantly negative > > > impact> > > on packet transmission performance, even if a bank of > > > specialized> > > network processors were employed per router or > > switch > > > > > > > > > > > > In short: do we really want to attempt this? While it’s all > > > > > > technically possible (at the risk of turning a 1Gbps pipe > > > into a > > > > > > 1Kbps pipe), I would argue that it’s not going to work. I > > would > > > > > > be happy to be first in line to write the software > necessary to > > > > > > circumvent such a system. And I would do it just > because I > > > can ;-) > > > > > > > > > > > > Having said that, the meeting report said that, the meeting > > > report> > > said that “if SATC finds a data stream carrying > > > content failing to > > > > > > match a known signature, it will block the stream or > mark it as > > > > > > being suspicious.” > > > > > > > > > > > > I underlined the text of significance. This suggests > that the > > > > > > database would only be populated with signatures of > known good > > > > > > media flows and would only block unrecognized flows. This > > seems > > > > > > different than what I read and understood from AVD-3541. > > > What the > > > > > > meeting report suggests would be a simpler problem with a > > > > > > substantially smaller database. So, what was actually > > discussed > > > > > > and decided for SATC? A system that blocks unrecognized > > > flows or > > > > > > a system that blocks recognized flows? > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

[itu-sg16] Fwd:Notice of Rapporteur Meeting in Busan, the Republic of Korea
by OKUBO Sakae 21 Sep '08

21 Sep '08

*** posted on behalf of Mr Kawamori *** Experts of ITU-T SG16 Question 13/16 Multimedia application platforms and end systems for IPTV Cc Mr P-A Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr P Barrett, Vice Chairman of SG16 <paul.barrett(a)psytechnics.com> Mr Y Naito, Vice 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 Okubo, Chairman of WP2/16 <okubo(a)aoni.waseda.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 Busan, the Republic of Korea Date: 10-12 October 2008 ------------------------------------------------------------------- Dear Experts of Q13/16, The subject meeting of ITU-T SG16 experts will be held at the Busan Lotte Hotel in Busan, the Republic of Korea. Details of the meeting are contained herein. Please note that this meeting precedes the 86th MPEG Meeting and Q13/16 will have a joint meeting with MPEG on the 11th and possibly on 12th. 1. Date ^^^^^^^ 10 (Friday) - 12 (Sunday) October 2008 Meeting will start at 10:00 on the first day and close around 18:00 on the final day. The joint meeting with MPEG will be 10:00-13:00 and 14:00-17:00 on 11th, and 10:00-13:00 on 12th. 2. Venue ^^^^^^^^ Busan Lotte Hotel 503-15 Bujeon-dong, Busanjin-gu, Busan, 614-030, Republic of Korea Tel: +82 2 759 7060, Fax: +82 2 319 8709, E-mail: jaeyu(a)lotte.net For further information on the meeting venue, please visit the website at <http://www.busanlottehotel.co.kr>. 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ - Coordinate with other SDOs, Questions, and Study Groups - Progress work on H.IPTV-AEH, H.IPTV-MAP, H.IPTV-MAFR series - Host a joint meeting with MPEG - Progress work on 'BIFS for IPTV', 'LASeR for IPTV', and 'M3W for IPTV', jointly with MPEG - Progress work on MXM jointly with MPEG - Discussion of miscellaneous and new work items 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 3 October 2008 /// /// Distribution of the document: by 23:59 UTC, 5 October 2008 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Mr Paul Jones <paulej(a)packetizer.com>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 3 October 2008 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/2005-2008/0810_Bus/AVD-template_0810_B…> 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, Sunday 5 October 2008 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 0810_Bus 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/2005-2008/0810_Bus/> <ftp://ftp3.itu.int/avc-site/2005-2008/0808_Gen/> 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 will be held at Busan Lotte Hotel, Busan, the Republic of Korea, collocated with MPEG meeting. Busan, also known as Pusan, is the second largest city in Korea. Busan is situated on the southeastern tip of the Korean peninsula, and is about an hour's flight from Seoul. For the information on the collocated MPEG meeting and logistics, please visit: <http://www.chiariglione.org/mpeg/meetings/busan08/kragenda.htm#Logistic_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 you need an invitation letter for visa, please send the following information to KATS, Ms. Eunsook Kim <jungbo(a)kats.go.kr> by e-mail: 1. Name 2. Sex: Male or Female 3. Date of birth (dd-mm-yyyy) 4. Passport No. & Date of Expiry (dd-mm-yyyy) 5. Company / Organization 6. Your Designation / Title 7. Post Address 8. Tel/Fax 9. E-mail address 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Participants should contact the hotels directly regarding room availability and for making room bookings. For reservation information at Busan Lotte Hotel, please contact: Mr. Yu, Jae (jaeyu(a)lotte.net) TEL: 82-2-759-7060 FAX: 82-2-319-8709 CELL: 82-10-2508-7390 Email: jaeyu(a)lotte.net. Free shuttle bus services run approximately every one and half hours from Busan international airport to the hotel. The journey will take approximately 30 minutes. We are looking forward to meeting with you in Busan. Sincerely yours, Masahito KAWAMORI (meeting organizer of this meeting) Paul JONES (document manager of this meeting) ----------

1 0

Notice of Rapporteur Meeting in Busan, the Republic of Korea
by Masahito Kawamori 21 Sep '08

21 Sep '08

Experts of ITU-T SG16 Question 13/16 Multimedia application platforms and end systems for IPTV Cc Mr P-A Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr P Barrett, Vice Chairman of SG16 <paul.barrett(a)psytechnics.com> Mr Y Naito, Vice 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 Okubo, Chairman of WP2/16 <okubo(a)aoni.waseda.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 Busan, the Republic of Korea Date: 10-12 October 2008 ------------------------------------------------------------------- Dear Experts of Q13/16, The subject meeting of ITU-T SG16 experts will be held at the Busan Lotte Hotel in Busan, the Republic of Korea. Details of the meeting are contained herein. Please note that this meeting precedes the 86th MPEG Meeting and Q13/16 will have a joint meeting with MPEG on the 11th and possibly on 12th. 1. Date ^^^^^^^ 10 (Friday) - 12 (Sunday) October 2008 Meeting will start at 10:00 on the first day and close around 18:00 on the final day. The joint meeting with MPEG will be 10:00-13:00 and 14:00-17:00 on 11th, and 10:00-13:00 on 12th. 2. Venue ^^^^^^^^ Busan Lotte Hotel 503-15 Bujeon-dong, Busanjin-gu, Busan, 614-030, Republic of Korea Tel: +82 2 759 7060, Fax: +82 2 319 8709, E-mail: jaeyu(a)lotte.net For further information on the meeting venue, please visit the website at <http://www.busanlottehotel.co.kr>. 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ - Coordinate with other SDOs, Questions, and Study Groups - Progress work on H.IPTV-AEH, H.IPTV-MAP, H.IPTV-MAFR series - Host a joint meeting with MPEG - Progress work on 'BIFS for IPTV', 'LASeR for IPTV', and 'M3W for IPTV', jointly with MPEG - Progress work on MXM jointly with MPEG - Discussion of miscellaneous and new work items 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 3 October 2008 /// /// Distribution of the document: by 23:59 UTC, 5 October 2008 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Mr Paul Jones <paulej(a)packetizer.com>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 3 October 2008 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/2005-2008/0810_Bus/AVD-template_0810_B…> 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, Sunday 5 October 2008 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 0810_Bus 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/2005-2008/0810_Bus/> <ftp://ftp3.itu.int/avc-site/2005-2008/0808_Gen/> 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 will be held at Busan Lotte Hotel, Busan, the Republic of Korea, collocated with MPEG meeting. Busan, also known as Pusan, is the second largest city in Korea. Busan is situated on the southeastern tip of the Korean peninsula, and is about an hour's flight from Seoul. For the information on the collocated MPEG meeting and logistics, please visit: <http://www.chiariglione.org/mpeg/meetings/busan08/kragenda.htm#Logistic_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 you need an invitation letter for visa, please send the following information to KATS, Ms. Eunsook Kim <jungbo(a)kats.go.kr> by e-mail: 1. Name 2. Sex: Male or Female 3. Date of birth (dd-mm-yyyy) 4. Passport No. & Date of Expiry (dd-mm-yyyy) 5. Company / Organization 6. Your Designation / Title 7. Post Address 8. Tel/Fax 9. E-mail address 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Participants should contact the hotels directly regarding room availability and for making room bookings. For reservation information at Busan Lotte Hotel, please contact: Mr. Yu, Jae (jaeyu(a)lotte.net) TEL: 82-2-759-7060 FAX: 82-2-319-8709 CELL: 82-10-2508-7390 Email: jaeyu(a)lotte.net. Free shuttle bus services run approximately every one and half hours from Busan international airport to the hotel. The journey will take approximately 30 minutes. We are looking forward to meeting with you in Busan. Sincerely yours, Masahito KAWAMORI (meeting organizer of this meeting) Paul JONES (document manager of this meeting) ----------

1 0

Re: Final meeting report
by OKUBO Sakae 15 Sep '08

15 Sep '08

Dear Paul and all, At 12:40 -0400 08/09/15, Paul E. Jones wrote: >I have integrated the changes into the report from those who >provided comments. The final report is attached. Thank you for your editing. This report AVD-3632 has been placed at the meeting directory: http://wftp3.itu.int/av-arch/avc-site/2005-2008/0808_Gen/AVD-3632.zip The index page has been updated accordingly: http://wftp3.itu.int/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

1 0

[itu-sg16] Q22 Question - SATC
by zourong 52447 11 Sep '08

11 Sep '08

Paul, really thanks your's comments, here is the clarification. 1) As to the circumventing problem, I really could not say their is a perfect way that could not be circumvented. But I don’t think it is easy to do so. This scenario is attempted to provide a tool for content provider to prevent their “specially processed” content, i.e. copy-righted content from being pirated. It is assumed the “specially processed” content have some characteristic information that would be destroyed by any piratical actio n such as using a different decoding method, and these characteristic information or “signature” would be provided to SATC system by content provider. As to the compress scheme to circumvent, I think the SATC could handle most of the common compress schemes such as winzar, winzip, tar etc., but I also think it is impossible the SATC could handle all compress schemes. 2) The method mentioned in AVD-3541 is not attempted to create a database of all pirated media, it’s a database that store the signature of good media especially those most popular video or audio recently, so the database will keep in a state of acceptable size. The periodical updating of the database is necessary just like the IDS do to update the anti-virus database. 3) The pirated media database could exist as an subsidiary database. This was not mentioned in the AVD-3541 because I think it maybe too detail to describe it in a scenario. The file transmitted will be suspected as pirated file when satisfied following two points: (1) There is a item in the “good media database” that means the file is a target of protecting. (2)the signature of the file transmitted do not match with that stored in the data base. Then the suspected file could be blocked directly, or in a more prudent way, it could be just marked as suspicious and search in a subsidiary “pirated media database” to make sure it is a existing pirated version or it maybe a new pirated version and need more manual analytical works of content provider. 4) As to the performance problem, I think this kind of inspection may have some negative impact on the packet transmission but may not as terrible as thought, in fact, many DPI product in market can achieve 10G to 40G, even 80G throughput, their process capability is remarkable. > > 发件人： Paul E. Jones > 发送时间： 2008-09-05 10:59:38 > 收件人： itu-sg16(a)lists.packetizer.com > 抄送： > 主题： [itu-sg16] Q22 Question - SATC > > Q22 Experts, > > While reviewing the Q22 meeting report, I was intrigued by a > comment related to AVD-3541. This contribution proposes that SATC > can be used to block illegal content from being transmitted over > the Internet by examining the media flow and comparing that media > flow (or some signature thereof) against a database. SATC would > then block content as appropriate. > > I would like to comment: > 1) I could easily circumvent any such measure, so any such > system would prove to work only temporarily; and > 2) While a given copy of a digital copy of some content, such > as music or a movie, will have a clearly recognizable signature, > the same media can be “substantially” altered by merely using a > different encoding method (e.g., a different video codec or > compression scheme); and > 3) Actually attempting to create a database of all known > pirated media, including all variations, would result in the > creation of a massively huge database; and > 4) Maintenance of such a database would be a never-ending > chore; and > 5) Notwithstanding the foregoing, while such a database could > be constructed and flows could be examined, inspecting flows in > real-time and trying to positively identify a given flow is a > monumental task that will result in significantly negative impact > on packet transmission performance, even if a bank of specialized > network processors were employed per router or switch > > In short: do we really want to attempt this? While it’s all > technically possible (at the risk of turning a 1Gbps pipe into a > 1Kbps pipe), I would argue that it’s not going to work. I would > be happy to be first in line to write the software necessary to > circumvent such a system. And I would do it just because I can ;-) > > Having said that, the meeting report said that, the meeting report > said that “if SATC finds a data stream carrying content failing to > match a known signature, it will block the stream or mark it as > being suspicious.” > > I underlined the text of significance. This suggests that the > database would only be populated with signatures of known good > media flows and would only block unrecognized flows. This seems > different than what I read and understood from AVD-3541. What the > meeting report suggests would be a simpler problem with a > substantially smaller database. So, what was actually discussed > and decided for SATC? A system that blocks unrecognized flows or > a system that blocks recognized flows? > > Thanks, > Paul > >

2 2

[itu-sg16] Q22 Question - SATC
by Paul E. Jones 04 Sep '08

04 Sep '08

Q22 Experts, While reviewing the Q22 meeting report, I was intrigued by a comment related to AVD-3541. This contribution proposes that SATC can be used to block illegal content from being transmitted over the Internet by examining the media flow and comparing that media flow (or some signature thereof) against a database. SATC would then block content as appropriate. I would like to comment: 1) I could easily circumvent any such measure, so any such system would prove to work only temporarily; and 2) While a given copy of a digital copy of some content, such as music or a movie, will have a clearly recognizable signature, the same media can be "substantially" altered by merely using a different encoding method (e.g., a different video codec or compression scheme); and 3) Actually attempting to create a database of all known pirated media, including all variations, would result in the creation of a massively huge database; and 4) Maintenance of such a database would be a never-ending chore; and 5) Notwithstanding the foregoing, while such a database could be constructed and flows could be examined, inspecting flows in real-time and trying to positively identify a given flow is a monumental task that will result in significantly negative impact on packet transmission performance, even if a bank of specialized network processors were employed per router or switch In short: do we really want to attempt this? While it's all technically possible (at the risk of turning a 1Gbps pipe into a 1Kbps pipe), I would argue that it's not going to work. I would be happy to be first in line to write the software necessary to circumvent such a system. And I would do it just because I can ;-) Having said that, the meeting report said that, the meeting report said that "if SATC finds a data stream carrying content failing to match a known signature, it will block the stream or mark it as being suspicious." I underlined the text of significance. This suggests that the database would only be populated with signatures of known good media flows and would only block unrecognized flows. This seems different than what I read and understood from AVD-3541. What the meeting report suggests would be a simpler problem with a substantially smaller database. So, what was actually discussed and decided for SATC? A system that blocks unrecognized flows or a system that blocks recognized flows? Thanks, Paul

1 0

Q1/16 meeting has concluded: report and documents
by Patrick Luthi 04 Sep '08

04 Sep '08

Dear experts, The Rapporteur meeting of Q1/16 has just concluded. The meeting report can be found here: http://ftp3.itu.int/av-arch/lbc-site/0808_Geneva/q1h13.doc The final list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0808_Geneva/q1h00r2.doc Best regards, Patrick Luthi Rapporteur for Q1/16

1 0

Re: [itu-sg16] Incoming LSs (TDs 741, 742 & 743-WP2/16)
by OKUBO Sakae 27 Aug '08

27 Aug '08

Dear Christian and Q3 experts, At 12:25 +0200 08/08/27, <Isabelle.Frost(a)itu.int> wrote: >Please be informed that the following incoming LSs, addressed to >Q3/16 from Chairman ITU-T SG 16 (on behalf of 3GPP TSG CT WG4), are >now available as: > >TD 741 WP 2/16 at: ><http://itu.int/md/T05-SG16-080905-TD-WP2-0741/en>http://itu.int/md/T05-SG16-080905-TD-WP2-0741/en >TD 742 WP 2/16 at: ><http://itu.int/md/T05-SG16-080905-TD-WP2-0742/en>http://itu.int/md/T05-SG16-080905-TD-WP2-0742/en >TD 743 WP 2/16 at: ><http://itu.int/md/T05-SG16-080905-TD-WP2-0743/en>http://itu.int/md/T05-SG16-080905-TD-WP2-0743/en > >The draft table is also updated at: ><http://ties.itu.int/u/tsg16/sg16/documents/irls>http://ties.itu.int/u/tsg16/sg16/documents/irls They have been posted as AVD-3629, 3630 and 3631 to the meeting directory. -- 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 ******************************************************************

1 0

[itu-sg16] ITU Workshop on IPv6 - Geneva, 4-5 September 2008
by simao.campos＠itu.int 25 Aug '08

25 Aug '08

Dear colleagues, ITU is organizing a Workshop on IPv6, which will be held at ITU headquarters, Geneva, Switzerland, from 4 to 5 September 2008. The main purpose of this event is to raise awareness on the importance and opportunities that IPv6 deployment will generate, and to answer key questions related to international public policy issues on the migration from IPv4 to Ipv6. The emphasis of this workshop is on economic aspects of IP address allocation as well as on identifying future directions for ITU's related work, including technical standardization and capacity building assistance to developing countries. In particular, in line with the activities undertaken by ITU-T Study Group 2 and Study Group 3, the workshop will address the questions raised in Study Group 3 - Contribution 30 and its addendum. To participate to the workshop please register at: http://www.itu.int/cgi-bin/htsh/edrs/ITU-T/workshop/edrs.registration.form?… The the ITU website at http://itu.int/ITU-T/worksem/ipv6/200809 for more detailed information on the workshop. Best regards, Simao ===================================================================== Simão Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Tel: +41-22-730-6805 Place des Nations Fax: +41-22-730-5853 Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int On the web: www.itu.int/ITU-T/studygroups/com16 ===================================================================== ***** Practice random kindness and senseless acts of beauty ***** =====================================================================

1 0

FW: IPTV-GSI event, Geneva, 1-5 September 2008 -- Reminder --
by simao.campos＠itu.int 21 Aug '08

21 Aug '08

> Dear all, > > As announced in TSB Circular 224, > http://www.itu.int/md/T05-TSB-CIR-0224/en, the fourth IPTV-GSI event > is to take place in Geneva, from 1 to 5 September 2008. > > > If you wish to participate in the event and have not registered, > kindly fill in the online registration form at: > http://www.itu.int/cgi-bin/htsh/edrs/ITU-T/studygroup/edrs.registratio > n.form?_eventid=3000027 > > > An updated IPTV-GSI work plan for the event is posted at > http://www.itu.int/oth/T2C02000001/ > > > Contributions are to be submitted by electronic mail to > tsbiptv(a)itu.int. The deadline for contributions is 24 August 2008, > midnight, Geneva time. > > Contributions will be posted on the IPTV-GSI web page > http://www.itu.int/ITU-T/gsi/iptv/. > > > Your attention is drawn to the table developed at the last IPTV-GSI > TSR providing the status of the IPTV work. This is in Doc 7 at > http://www.itu.int/ITU-T/studygroups/com13/iptv-jca/iptv-gsi-tsr/index > .html. See also below. > > Note that the approval of Recommendation ITU-T Y.1910, IPTV > architecture is to be considered at the 12 September 2008 meeting of > Study Group 13. > > > Best regards, > on behalf of Mr Georges Sebek > Document # > (IPTV-GSI) Title Prime > Q/SG Target Completion > TD101 Q.iptvsa: Signalling and control plane architecture for IPTV > 1/11 Not known > TD 73 > G.IPTV-PMPD: IPTV performance monitoring - Parameter definitions > 13/12 November 2009 > TD 74 > G.IPTV-PMMM: IPTV Performance monitoring - Measurement methods > 13/12 2010 > TD 112 Y.iptv-netcontrol-fw: IPTV network control framework > 2/13 Q3 2009 > TD 118 Y.iptv-req: IPTV services requirements 2/13 > September 2008 > TD 510* Functional architecture aspects of IPTV network control > 3/13 Not known > TD 72 > Y.IPTV-TM: Traffic management mechanisms for the support of IPTV > services 4/13 Q2 2009 > TD 20 IPTV vocabulary of terms 11/13 Not known > TD 103 H.IPTV-CDER: Content delivery error recovery for IPTV > services 13/16 Not known > TD 113 > H.IPTV-TDES.1: IPTV terminal devices and end-system > September 2008 > TD 114 H.IPTV-MAFR: Overview of Multimedia Application > Frameworks for IPTV 13/16 Not known > TD 115 H.IPTV-SDC: Mechanisms for service discovery up to > consumption for IPTV 13/16 Not known > TD116 J/H.IPTV-BCTM: Broadcast-centric IPTV Terminal middleware > September 2008 > TD 117 H.IPTV-MD: Metadata for IPTV 13/16 September 2008 > TD 107 > H.iptv-hn: Architecture and functional requirements for Home > Network supporting IPTV services 21/16 September 2008 > TD 108 > H.iptv-rm: Architecture and functional requirements for remote > management of home networks supporting IPTV services 21/16 Not > known > TD 105 > X.iptvsec-1: Functional requirements and architecture for IPTV > security aspects 9/17 September 2008 > *: TD 510 (WP2/13) >

1 0

Re: [itu-sg16] Q.3 Agenda
by OKUBO Sakae 21 Aug '08

21 Aug '08

Dear Christian and Q3 experts, At 16:49 +1000 08/08/21, Christian Groves wrote: >Please find attached the Q.3 Agenda. If its OK with you, could you >please upload it to the meeting directory? Done as requested. The document list has been updated accordingly: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

1 0

Documents for the next week meeting of Q1
by Patrick Luthi 21 Aug '08

21 Aug '08

Dear experts, All meeting documents have been posted: http://ftp3.itu.int/av-arch/lbc-site/0808_Geneva ftp://ftp3.itu.int/lbc-site/0808_Geneva user: avguest, password: Avguest The list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0808_Geneva/q1h00.doc Best regards, Patrick Luthi Rapporteur for Q1/16

1 0

[itu-sg16] Additional documents have been posted
by OKUBO Sakae 20 Aug '08

20 Aug '08

Dear WP2/16 experts, Please note the following new and revised documents: 1/ An initial meeting room allocation is now available as TD-25. 2/ Three liaison statements from TSAG have been posted: AVD-3623 -- LS regarding handling of patent declarations AVD-3624 -- LS on quality of ITU-T Recommendations AVD-3625 -- LS on improved Geographic Distribution and Coordination of ITU-T Seminars and Workshops 3/ Mr Probst's report of the TSAG meeting has been updated with this information and posted as AVD-3527a. 4/ AVD-3548 has been withdrawn. 5/ Some documents have been revised. They have AVD-XXXXXa document numbers. All of those documents can be downloaded from the index page: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

1 0

[itu-sg16] Withdraw AVD-3548
by Yoshiki NISHIKAWA 19 Aug '08

19 Aug '08

Dear Mr Okubo and all, Due to the considerations inside NTT, we have to withdraw AVD-3548. The information inside there will be presented as part of AVD-3549 during the meeting. Best regards -- NISHIKAWA Yoshiki NTT Cyber Solutions Laboratories, NTT Corporation E-mail:nishikawa.yoshiki@lab.ntt.co.jp Tel :+81 46 859 3632 FAX :+81 46 859 5505

1 0

[itu-sg16] Submitted contributions for the next week Rapporteur group meeting
by OKUBO Sakae 18 Aug '08

18 Aug '08

Dear contributors, Thank you for your cooperation for the on-time submission. I have uploaded all the contributions received via ftp or e-mail to the meeting directory except for the following: AVD-3494 Q13/16 Rapporteur (M Kawamori) AVD-3495 Q13/16 Rapporteur (M Kawamori) AVD-3544 NTT AVD-3545 NTT AVD-3546 NTT AVD-3547 NTT, KDDI, SOFTBANK BB AVD-3607 Editor (B Kenrick) -- advised to be late Please advise me if I am wrong. Please check if your contributions are correctly placed at: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/> and properly listed at: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

1 0

[itu-sg16] ALU docs; RE: Reminder -- document uploading and participation registration for the next week meeting
by Schwarz Albrecht 18 Aug '08

18 Aug '08

All ALU docs should be now available on the server. The remaining ones were uploaded today: Index of /av-arch/avc-site/Incoming Name Last modified Size [DIR] Parent Directory 14-Dec-2006 00:53 - [ ] AVD-3507_H.248.14_Default_mit_Ed01.doc 18-Aug-2008 10:21 50k [ ] AVD-3508_H.248.1_StreamID_Ed01.doc 18-Aug-2008 10:22 57k [ ] AVD-3509_H.248.67_ScopeApplicability_Ed02.doc 18-Aug-2008 15:43 87k [ ] AVD-3510_H.248.67_DefTransportMode_Ed02.doc 18-Aug-2008 15:43 51k [ ] AVD-3511_H.248.67_DataType_for_Properties_Ed02.doc 18-Aug-2008 15:43 108k [ ] AVD-3512_H.248.67_Procedures_Ed02.doc 18-Aug-2008 15:43 80k [ ] AVD-3513 H.248.64_Update_clauses_1to5.doc 18-Aug-2008 10:22 88k [ ] AVD-3517_H.248.52_CopyOptions_Ed02.doc 18-Aug-2008 10:22 252k [ ] AVD-3518_H.248.56_DefaultValue_Ed02.doc 18-Aug-2008 10:22 66k [ ] AVD-3522_H.248.1_Version4_AggregateTermination_Ed02.doc 18-Aug-2008 10:22 99k [ ] AVD-3618_H.248.25_Corrections_Ed01.doc 18-Aug-2008 10:22 47k > -----Original Message----- > From: itu-sg16-bounces(a)lists.packetizer.com > [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of > OKUBO Sakae > Sent: Montag, 18. August 2008 07:49 > To: itu-sg16(a)lists.packetizer.com > Subject: [itu-sg16] Reminder -- document uploading and > participation registration for the next week meeting > > Dear WP2/16 experts, > > Please be reminded that the document submission deadline is: > > /// Distribution of the document: by 23:59 UTC, 18 August 2008 /// > > Please use ftp for uploading as indicated in the meeting > notice > <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/Notice > _0808_Gen.txt>. > > Site: ftp3.itu.int/ > User ID: avguest > Password: Avguest (Note the uppercase 'A') > Directory: avc-site/Incoming > > In case you have difficulty with ftp, please e-mail your > document to me <okubo(a)aoni.waseda.jp>. > > Once a document is uploaded to the /avc-site/Incoming, > currently you can view this directory and download documents > there at <http://ftp3.itu.ch/av-arch/avc-site/Incoming/>. > > As I have to process 73 documents yet to be uploaded (and > Olympic games are ongoing ...), there may be some lag before > all the documents will be placed at the meeting directory > <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/>. If > you need urgent review of some contributions, please think > about downloading them from /Incoming as raw materials. > > The current list of documents is available at: > > <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/0808_Gen.html> > > Please find after my signature the current list of > participants I have been advised of. If you are attending the > next week meeting but your name is missing there, please send > a note to me. > > -- > 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 > ****************************************************************** > > Stephen Botzko -- Polycom > Tommy Young -- Huawei > Yangobo Lin -- Huawei > Arturo Martin De Nicolas -- Ericsson > Patrick Luthi -- Tandberg > Sakae Okubo -- Waseda University > Albrecht Schwarz -- Alcatel-Lucent > Paul E Jones -- Cisco > Yoshinori Goto -- NTT > Christian Groves -- NTEC > Leo Lehmann -- OFCOM > Hiroshi Ohta -- NTT > Aki Fukuoka -- NTT > Brody Kenrick -- Dilithium > Wataru Kameyama -- Waseda University > Yoshiki Nishikawa -- NTT > Masahito Kawamori -- NTT > Seong-Ho Jeong -- HUFS > Noah Luo -- Huawei > Baohong He -- CATR > Xiaolin Jiang -- CATR > Dong Wang -- ZTE > Zou ZiXuan -- Huawei > Jun Seob Lee -- ETRI > Masami Ueda -- Sumitomo Electric > Marie Kim -- ETRI > Youichi Takashima -- YRP UNL > Tetsuo Kamina -- YRP UNL > Ki-Jong Koo -- ETRI > Mijeom Kim -- ETRI > Shuichi Nishio -- ATR > > ========== >

1 0

List of contributions for the Geneva meeting of Q1/16
by Patrick Luthi 18 Aug '08

18 Aug '08

Dear Q1/16 experts, The deadline to register contributions was last Sunday at 23.59 and this is the current list of registered contributions for the Geneva meeting (27-28 August 2008). The deadline for submitting your contributions is 23:59 UTC on Wednesday 20 August 2008. The documents will be available through this URL: http://ftp3.itu.int/av-arch/lbc-site/0808_Geneva/ Please advise me if your contribution is not listed here: Q1-H00 Rapporteur List of Documents for Meeting H of the ITU-T SG16 Q1 Experts Group Q1-H01 Invitation for Questions 1,2,3,4,5,12,21,22,24,25,29 Experts Group 25-29 August 2008 in Geneva --> see Q1-H02 Q1-H02 Rapporteur Meeting announcement for Meeting H of Q1/16 Experts, Geneva, 27-28 August 2008 Q1-H03 Rapporteur Meeting report of Working Party 2 of ITU-T Study Group 16, Geneva, 22 April-2 May 2008 Q1-H04 Polycom Proposed H.320 BAS codes for support of G.719 Q1-H05 Polycom Proposed H.281 changes for supporting multiple video streams Q1-H06 Dilithium IMS interworking with H.324 Annex K Q1-H07 Dilithium Proposed Clarification on SPC Transmission Timing in H.324 Annex K Q1-H08 Dilithium Proposed New H.324 Annex Clarifying Mandatory Signalling Entities Q1-H09 Editor Proposed draft revised H.230 Q1-H10 Ericsson H.324 Annex K, MONA SPC update to improved CS-IMS interworking I am looking forward meeting with you in Geneva next week. Best regards, Patrick Luthi Rapporteur for Q1/16

1 0

Re: [itu-sg16] Brazilian contribution to ITU-T SG16 -- AVD-3555
by OKUBO Sakae 15 Aug '08

15 Aug '08

Dear Mr Antonio Celso Guimaraes Teixeira and all, At 9:40 -0300 08/08/15, Antonio Celso Guimaraes Teixeira wrote: >Effectivelly, document AVD-3555 is a new proposal. There is a >mistake in the indication of source. > >Could you, please, change the source from "Editors" to "Brazil", >inside our document ? Done as requested both in the document itself and the list. http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/AVD-3555.zip http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

1 0

Re: [itu-sg16] Contribution to Q.21 and Q.22/16
by OKUBO Sakae 15 Aug '08

15 Aug '08

Dear Mr Jun Seob Lee, Thank you for your input contributions. At 15:06 +0900 08/08/01, タフチリシキ wrote: >I will submit 2 contribution to coming WP2/SG16 meeting. Please >assign AVD number for followings The following numbers have been allocated to them: AVD-3520 Proposed changes to draft new H.IRP AVD-3521 Proposed changes to draft new H.IDscheme The index page has been updated accordingly. <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0808_Gen/0808_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 ******************************************************************

2 1

Re: [itu-sg16] Registration of documents for the upcomping WP2/16 Rapp. meeting
by OKUBO Sakae 15 Aug '08

15 Aug '08

Dear Elad Chomsky, Albrecht Schwarz and Shuichi Nishio, Thank you for your input contributions, to which the following AVD-numbers have been allocated and the document list <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0808_Gen/0808_Gen.html> has been updated: AVD-3612 3 Updated draft for new H.248.1v3 Appendix IV (ex. H.248.STATISTICS) Editor (E Chomsky) AVD-3613 3 Draft H.248.1v3 Appendix IV - Reincorporate example for read and reset statistics Juniper Networks AVD-3614 3 H.248.53 - Remove the General IP Header QoS properties from the Local descriptor Juniper Networks AVD-3615 3 H.248.52 - Proposed initial draft for Traffic Policing Statistics package version 2 Juniper Networks AVD-3616 3 H.248.PIC - Proposed initial draft for a new H.248 Package: Packages Information and Control package Juniper Networks AVD-3617 3 H.248.RECRTCP - Proposed initial draft for a new H.248 Package: Received RTCP Juniper Networks AVD-3618 3 H.248.25 - Editorial corrections Alcatel-Lucent AVD-3619 12 Requirements for Network Robots as AMS terminal ATR, NTT -- 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 ******************************************************************

1 0

Re: [itu-sg16] Request for AVD numbers
by OKUBO Sakae 15 Aug '08

15 Aug '08

Dear Mr Kawamori, At 16:28 +0900 08/08/11, kawamori.masahito(a)lab.ntt.co.jp wrote: >Could you please assinge the AVD numbers to the following contributions >to the upcoming Rapporteurs meeting? The following AVD-numbers have been allocated to your six contributions: AVD-3542 1. Title: Proposed modification for H.IPTV-MAFR.0 Question: Q13/16 Source: NTT AVD-3543 2. Title: Proposed modification for H.IPTV-MAFR.10 Question: Q13/16 Source: NTT AVD-3544 Title: Proposed editorial modifications for H.iptv-md Question: Q13/16 Source: NTT AVD-3545 Title: Proposed modifications for H.IPTV-SDC Question: Q13/16 Source: NTT AVD-3546 Title: Proposed modifications for H.IPTV-TDES.0 Question: Q13/16 Source: NTT AVD-3547 Title: Proposal for the Basic Model of IPTV Terminal Device Question: Q13/16 Source: NTT, KDDI, SoftbankBB I will indicate "for IPTV-GSI" to AVD-3544 through 3547 in the docuent list. -- 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 2

[itu-sg16] Documents for Rapporteur group meeting (25-29 August)
by OKUBO Sakae 14 Aug '08

14 Aug '08

Dear WP2/16 experts, The document registration deadline will come in 24 hours (23:59 UTC, 15 August 2008). The current list of documents is available at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0808_Gen/0808_Gen.html I believe I have incorporated all the requests, but please advise me if your document is missing in the list. Those documents with hyper linked numbers have been posted. Please also advise me if your document is not there. -- 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 ******************************************************************

1 0