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

Delayed Contribution from Waseda University
by OKUBO Sakae 29 Sep '02

29 Sep '02

Dear SG16 experts, I have submitted the following delayed contribution to ITU-TSB: Source: Waseda University Title: Study item for displaying remote PC presentations in H.300-series systems Outline: This submission is stimulated by the indication of Q.1/16 future work "H.320 Annex Multiple Streams" in the WP2/16 report of the February 2002 meeting (Section 3.5.13 of COM 16-R19). A current daily practice of face-to-face meetings, lectures, demonstrations, etc is to present PC files with an LCD projector. The interface between PC and projector is well established and stable these days. It will enhance the H.300-series videoconferencing systems if they incorporate the feature of remotely presenting the PC display image. It is available for your review at the avc-site: http://standard.pictel.com/ftp/avc-site/0210_Gen/Waseda_delayed_020928.zip -- 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

2 2

ITU-T SG16 mailinglists
by OKUBO Sakae 29 Sep '02

29 Sep '02

Dear all, Recently the following ITU-T SG16 mailinglists subscribed to the Intel's itu-sg16(a)lists.intel.com mailinglist: > tsg16qd(a)itu.int > tsg16qf(a)itu.int > tsg16qg(a)itu.int > tsg16q2(a)itu.int > tsg16q3(a)itu.int > tsg16q4(a)itu.int > tsg16q5(a)itu.int A consequence is that if you post your message at itu-sg16(a)lists.intel.com and if you have not subscribed to those ITU-T mailinglists, you will receive a "non-member submission" warning. If you have a TIES account, then you can make subscriptions to those ITU-T mailinglists through the following page: http://www.itu.int/ITU-T/studygroups/com16/edh/subscribe.html Otherwise, you can ignore the warning. Your posting is still distributed by the Intel's itu-sg16(a)lists.intel.com to those who subscribed to it. -- 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

Decoding H.245 Messages
by Tom-PT Taylor 27 Sep '02

27 Sep '02

Naive question from someone who has never implemented ASN.1 PER: could I use the latest H.245 ASN.1 to decode H.245v5 and H.245v6 messages? 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

2 1

Meeting documents
by OKUBO Sakae 27 Sep '02

27 Sep '02

Dear SG16 experts, Somewhat belatedly, AVD-2252, integrated report of the Bruges meeting, is now available at the following place: http://standard.pictel.com/ftp/avc-site/0206_Bru/AVD-2252.zip Using this opportunity, let me remind you that you are requested to voluntarily post input documents (Delayed Contribution or Temporary Document) for the coming SG16 meeting at http://standard.pictel.com/ftp/avc-site/Incoming so that experts can review them in advance of the meeting. Please note, however, since the October meeting is an official ITU-T meeting, all the documents are managed by ITU-TSB. 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

RE: comments on AVD 2253 from Raleigh
by Even, Roni 26 Sep '02

26 Sep '02

Paul, Single source is not a good definition, is it an a same IP address or is it the same encoder Roni > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, September 26, 2002 6:56 AM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Martin Euchner > Subject: Re: comments on AVD 2253 from Raleigh > > > Roni, > > The current definition, which was drafted by Terry Anderson, > is pretty clear > that multiple payload streams must carry data from a single > "source", I > believe. Have a look at AVD 2257. > > Paul > > ----- Original Message ----- > From: "Even, Roni" <roni.even(a)polycom.co.il> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "Even, Roni" > <roni.even(a)polycom.co.il>; <ITU-SG16(a)echo.jf.INTEL.COM> > Cc: "Martin Euchner" <Martin.Euchner(a)icn.siemens.de> > Sent: Wednesday, September 18, 2002 4:06 AM > Subject: RE: comments on AVD 2253 from Raleigh > > > > Paul, > > > > I think that the requirement were to prevent audio and > video in the same > > stream on one side and to allow for multiple video or audio > in the same > > stream to be compatible with SIP capabilities and not only > for MOIP. So I > > think that there should be a text saying that in multiple > streams we do > not > > recommend audio and video in the same stream and to be able > to specify the > > packetization scheme for the multiple streams. > > Roni > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Tuesday, September 17, 2002 7:52 PM > > > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > > > Cc: Martin Euchner > > > Subject: Re: comments on AVD 2253 from Raleigh > > > > > > > > > Roni, > > > > > > , > > > > I have some concerns about the changes proposed in this AVD. > > > > > > > > 1. The AVD adds a new data type called > multiplepayloadstream that is > > > > intended to allow more then one payload in a stream. > > > According to the > > > ASN.1 > > > > you can have different media types in the same logical > > > channel which is > > > not > > > > a good practice and would break a lot of implementations. > > > > > > We already have precedence for this, such as RFC 2833. In > > > addition, this > > > feature would only be used if both sides advertise the > > > capabilities, so I do > > > not expect to see anything break. > > > > > > > 2. The data type in H.245 open logical channel describe the > > > media type but > > > > do not specify the RTP payload format used. There are cases > > > were there is > > > > more then one way to build the RTP stream for example in > > > H.263. In the OLC > > > > in H2250LogicalChannelParameters there is a RTPPayloadType > > > parameter that > > > > describe the RTP payload. If the AVD is used to describe > > > multiple streams > > > > there is no way to specify the packetization scheme used. > > > > > > This might be true. Would it be possible to add those > parameters as > > > necessary in the future? At the moment, the only use for > > > this capability at > > > the moment is for modem over IP, wherein every payload that > > > will be used is > > > understood based solely on the capability, I believe-- > > > perhaps I'm wrong. > > > In any case, the important thing is to know whether the > > > syntax precludes the > > > specification of additional parameters. > > > > > > > 3. I think that the editor of H.235 will look to see if the > > > proposed AVD > > > > allows to specify and change a key for each payload that > > > can be used in > > > the > > > > logical channel. I am not an expert on H.235 > > > > > > Most definitely.. I would certainly welcome comments and > > > input in the area > > > of security. > > > > > > Paul > > > > > > > > >

2 1

Re: comments on AVD 2253 from Raleigh
by Even, Roni 25 Sep '02

25 Sep '02

Paul, I think that the requirement were to prevent audio and video in the same stream on one side and to allow for multiple video or audio in the same stream to be compatible with SIP capabilities and not only for MOIP. So I think that there should be a text saying that in multiple streams we do not recommend audio and video in the same stream and to be able to specify the packetization scheme for the multiple streams. Roni > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, September 17, 2002 7:52 PM > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Martin Euchner > Subject: Re: comments on AVD 2253 from Raleigh > > > Roni, > > , > > I have some concerns about the changes proposed in this AVD. > > > > 1. The AVD adds a new data type called multiplepayloadstream that is > > intended to allow more then one payload in a stream. > According to the > ASN.1 > > you can have different media types in the same logical > channel which is > not > > a good practice and would break a lot of implementations. > > We already have precedence for this, such as RFC 2833. In > addition, this > feature would only be used if both sides advertise the > capabilities, so I do > not expect to see anything break. > > > 2. The data type in H.245 open logical channel describe the > media type but > > do not specify the RTP payload format used. There are cases > were there is > > more then one way to build the RTP stream for example in > H.263. In the OLC > > in H2250LogicalChannelParameters there is a RTPPayloadType > parameter that > > describe the RTP payload. If the AVD is used to describe > multiple streams > > there is no way to specify the packetization scheme used. > > This might be true. Would it be possible to add those parameters as > necessary in the future? At the moment, the only use for > this capability at > the moment is for modem over IP, wherein every payload that > will be used is > understood based solely on the capability, I believe-- > perhaps I'm wrong. > In any case, the important thing is to know whether the > syntax precludes the > specification of additional parameters. > > > 3. I think that the editor of H.235 will look to see if the > proposed AVD > > allows to specify and change a key for each payload that > can be used in > the > > logical channel. I am not an expert on H.235 > > Most definitely.. I would certainly welcome comments and > input in the area > of security. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Meeting documents
by OKUBO Sakae 25 Sep '02

25 Sep '02

Dear SG16 experts, Somewhat belatedly, AVD-2252, integrated report of the Bruges meeting, is now available at the following place: http://standard.pictel.com/ftp/avc-site/0206_Bru/AVD-2252.zip Using this opportunity, let me remind you that you are requested to voluntarily post input documents (Delayed Contribution or Temporary Document) for the coming SG16 meeting at http://standard.pictel.com/ftp/avc-site/Incoming so that experts can review them in advance of the meeting. Please note, however, since the October meeting is an official ITU-T meeting, all the documents are managed by ITU-TSB. -- 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

Re: [Security] Enhancements to H.233 and H.234
by Euchner Martin ICN M SR 3 20 Sep '02

20 Sep '02

Ok; sounds fine with me. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il] Sent: Wednesday, September 18, 2002 9:59 AM To: Euchner Martin ICN M SR 3; Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM Subject: RE: [Security] Enhancements to H.233 and H.234 Martin, I think that H.234 did not give values was because when written it only defined 512bit DH since it was for DES. Patrick suggests adding AES and after discussing with him we will add the reference to RFC 1412 as in H.235 Roni > -----Original Message----- > From: Euchner Martin ICN M SR 3 [mailto:Martin.Euchner@icn.siemens.de] > Sent: Tuesday, September 17, 2002 1:49 PM > To: 'Even, Roni'; ITU-SG16(a)echo.jf.INTEL.COM; Euchner Martin > ICN M SR 3 > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > Roni, > > regarding recommended DH parameters, H.234 apparently follows > a different > philosophy than H.235: > > H.234 does not recommend any particular DH set. Any DH-set > should work as > long as the parameters are chosen with care. > On the other hand, H.235 recommends certain sets of DH > parameters (taken > from RFC2412). H.235 also allows to use arbitrary (i.e. non > standardized) > DH-parameters if there is a need for. > > Now I do not know why H.234 did not recommend any particular > set. I can only > speculate: perhaps it was decided to leave that issue to the > implementation. > Or such agreed parameters were simply not available in those > former days. > Anyway, this makes the ITU recommendation pretty vague and introduces > potential interoperability problems. > > H.235 defines the recommended DH-values in order to yield a consistent > security level among key management and media security taking > into account > the media encryption algorithms and also exportability issues. It was > further recognized that using the well-defined DH parameter aids in > interoperability and simplifies implementations. > > One good question that we are touching is: > Should we leave H.234 in the same spirit as the document is/was? > Or should we improve and add more recommendations such as suggested > DH-parameters and some more text? > > I can see arguments for either way... > > > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 47713 > | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://intranet.icn.siemens.de/marketing/cs27/topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > > -----Original Message----- > From: Even, Roni [mailto:roni.even@POLYCOM.CO.IL] > Sent: Tuesday, September 17, 2002 8:11 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: [Security] Enhancements to H.233 and H.234 > > Patrick, > I still do not understand number 1 since this tag is in the > context of h.233 > and should be specified like that. > As for the prime number look at the RFC 2412. H.235 refer to > it since it > includes verified prime numbers for 1024 and 1536 and I > suggest we have the > same recommendation as H.235. Maybe you should consult with > Martin Euchner > Regards > Roni > > > -----Original Message----- > > From: Patrick Luthi [mailto:patrick.luthi@tandberg.no] > > Sent: Tuesday, September 17, 2002 12:59 AM > > To: Even, Roni; ITU-SG16(a)echo.jf.INTEL.COM > > Subject: RE: [Security] Enhancements to H.233 and H.234 > > > > > > Roni, > > > > See my answers in-line! > > > > Regards, > > > > Patrick > > > > At 16:03 9/12/2002 +0300, Even, Roni wrote: > > >Patrick, > > >I looked at the contributions and have some comments. > > > > > >1. In H.233 why the new tag class, why don't you use 11 as > > the rest of H.233 > > >messages. > > > > We used 00 because it defines the universal tag class (11 > > being context > > specific), and we thought that SE_NULL, as data type null > > message, would > > best belong to that class. This makes it consistent with ASN.1. > > > > >2. By adding the new encryption algorithm you need a longer > > DH prime. In > > >H.235 they have a table in annex D which is based on > > RFC2412. Do you think > > >we should have the option to recommend the same numbers as > > H.235 does. > > > > H.233 nor H.234 are specifying any Diffie Hellman prime > values and my > > understanding is that it is left to the implementor to choose > > the best > > value. I see your point, and in the interest of interoperability, a > > specified value would help. > > I will think about how to best integrate some text specifying > > prime values > > in H.234. One idea was to add a note in the section about > > Diffie Hellman > > (clause 4/H.234) saying something (inspired by D.7.1/H.235) > like this: > > It is recommended to use a prime value of 512 bits for the > > DES algorithm > > (when exportable security is of concern), 1024 bits for > > Triple DES and AES > > algorithms (when high security is of concern), and 1536 bits > > for Triple DES > > and AES algorithms (when very high security is of concern). > > Would that address your concerns? Any feedback or comments > > are welcomed! > > > > > > >Regards > > >Roni Even > > > > > > > -----Original Message----- > > > > From: Patrick Luthi [mailto:patrick.luthi@TANDBERG.NO] > > > > Sent: Friday, August 30, 2002 1:54 AM > > > > To: ITU-SG16(a)echo.jf.INTEL.COM > > > > Subject: [Security] Enhancements to H.233 and H.234 > > > > > > > > > > > > Dear experts, > > > > > > > > We would like to share with you 2 proposals for enhancements > > > > to H.233 and > > > > H.234 that we are planning to submit to the October > > meeting of SG16. > > > > > > > > Enhancements to H.233: this contribution proposes to add the > > > > Triple Data > > > > Encryption Algorithm (TDEA or triple DES) and the > > Advanced Encryption > > > > Standard (AES) to the list of algorithms in H.233 along with > > > > corrections of > > > > some inconsistencies. > > > > > > > > Enhancements to H.234: this contribution proposes changes to > > > > H.234 to allow > > > > the exchange of asymmetric length of encryption keys. > > > > > > > > Please let me know if you have any suggestions or comments! > > > > The plan would > > > > be to ask for Consent for both recommendations at the > > closing of the > > > > upcoming SG16. > > > > > > > > Best regards, > > > > > > > > Patrick > > > > > > > > _____________________________ > > > > Patrick Luthi > > > > Manager - Technical Standards > > > > Rapporteur (chairman) for the ITU-T multimedia systems, > > terminals and > > > > data-conferencing Experts group (Question 1/16) > > > > TANDBERG > > > > N-1366 Lysaker, Norway > > > > Phone: + 47 67 125 125 > > > > e-mail: patrick.luthi(a)tandberg.no > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: H.460.QoSMon
by Horvath Ernst 20 Sep '02

20 Sep '02

Tom, you can find the (first and only) draft in D211 of the February 2002 (Geneva) SG16 meeting . There will be an updated draft available for the forthcoming meeting. Regards, Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Gesendet am: Donnerstag, 19. September 2002 22:57 An: ITU-SG16(a)echo.jf.INTEL.COM Cc: 'Horvath Ernst' Betreff: H.460.QoSMon Where is the last (first?) available draft of this document? I haven't been able to track it down. 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

RE: PictureTel Site Blocked
by Campos, Simao 20 Sep '02

20 Sep '02

Dear colleagues, it seems that these problems with the PictureTel site keep recurring. I would like to suggest an alternative, that could be discussed in Geneva in October. TSAG has created a mechanism for creating "semi"-open FTP areas under TIES (for the purp[ose of communicating with organizations outside the ITU), outside of the traditional informal FTP area of the SGs. This area has a username/password, but these can be communicated to the interested parties. In this sense, I would like to investigate with you what would be your feeling about migrating all the material that is now available in the PicTel FTP site into such an area hosted by the ITU, created for SG 16. If your response is positive, I would start checking internally how can we most expeditely move into that direction. Best regards, Simao -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: 18 September 2002 22:08 To: ITU-SG16(a)echo.jf.INTEL.COM Subject: PictureTel Site Blocked The PictureTel site is giving me an error message: maximum number of anonymous users exceeded. I expect this is the FTP problem they had before. The administrator address provided in the error message (Patrick Luthi's old address) bounces, so I don't know who to contact to reset the server. 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

3 2