- sg16-avd - lists.packetizer.com

FW: [AVT] Seeking input from G.726 ADPCM implementers
by Campos, Simao 15 Oct '02

15 Oct '02

Dear colleagues, For your information and possible feedback to Steve Casner. Best regards, SImao -----Original Message----- From: Stephen Casner [mailto:casner@packetdesign.com] Sent: 15 October 2002 07:24 To: AVT WG Subject: [AVT] Seeking input from G.726 ADPCM implementers The IETF Audio/Video Transport working group is seeking input from any implementers of systems using the G.726 ADPCM audio encoding, in particular any that use the MIME audio subtypes G726-16, G726-24, G726-32, and G726-40 or the RTP static paylod type 2 for G726-32. This notice is being sent to multiple mailing lists to reach as many interested parties as possible; please reply only to avt(a)ietf.org. Background: The AVT working group is seeking to advance the Real-time Transport Protocol (RTP) and its associated Profile for A/V Conferences (RFCs 1889 and 1890, respectively) to Draft Standard status. Two drafts have been prepared to revise these RFCs for advancement: draft-ietf-avt-rtp-new-11.txt draft-ietf-avt-profile-new-12.txt These drafts have been "tentatively approved" for publication by the IESG. In addition, a new companion draft has been approved for publication as a Proposed Standard to specify MIME subtype registrations for all the encoding names defined in the RTP Profile: draft-ietf-avt-rtp-mime-06.txt Issue: The packetization of G.726 audio specified in the RTP Profile packs audio samples into octets beginning with the least-significant bit of the octet. This is at odds with the packetization of G.726 audio for ATM AAL2 transport specified in ITU-T Recommendation I.366.2 Annex E, which begins with the most-significant bit. Implementers of systems that operate with both transports or gateway between the two have requested that the RTP packetization be changed to match the I.366.2 packetization to avoid requiring two different DSP implementations and/or translation between packings. Both specifications have existed for some time: I.366.2 has been an approved standard since 1999, and the packing for the G726-32 rate has been part of the RTP Profile drafts since 1997. Therefore, implementations of both packings are likely to exist. Furthermore, since the RTP Profile did not include packetizations for rates other than 32K until 2001, some RTP implementations may have used the I.366.2 packings for those rates. As a consequence, there is no course of action that will make everyone happy. Proposal: After consultation with the IETF Transport Area Directors, it is proposed that the draft RTP Profile packetization be changed to be consistent with I.366.2 Annex E before it is published as an RFC. The MIME subtype registrations for G726-16, G726-24, G726-32, and G726-40 in draft-ietf-avt-rtp-mime-06, which refer to the specification of the packetizations in draft-ietf-avt-profile-new-12, would therefore apply to the changed packetization. In addition, RTP static payload type 2, which is bound to the G726-32 encoding and packetization by draft-ietf-avt-profile-new-12, would also change its meaning. Consequences: We have already heard from one vendor that has implemented the packetizations according to the current RTP Profile draft and therefore objects to the change. Any such systems already in the field would produce garbled audio when interoperated with RFC-compliant implementations, and not detect the error. This is a significant consideration, although draft specifications are not guaranteed to remain unchanged. We have also been informed that the format for G.726 audio in the Voice Profile for Internet Mail (RFC 2421/2) uses the same sample packing as currently specified in the RTP Profile draft. This is consistent with ITU-T Recommendation X.420 for X.400 mail. Since the VPIM systems use MIME type audio/32KADPCM rather than audio/G726-32, there would not be conflict in meaning if the latter were changed as proposed. However, voicemail systems that transmit messages over RTP would be forced to reformat the data. ******************************************************************** * We are seeking statements from interested parties both for and * * against this proposal, particularly with motivations. * ******************************************************************** _______________________________________________ Audio/Video Transport Working Group avt(a)ietf.org https://www1.ietf.org/mailman/listinfo/avt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

SPAM: unsubscribe request
by K. Hal Purdy 14 Oct '02

14 Oct '02

Sorry for spam, but I have tried unsuccessfully for two weeks to follow the directions at the bottom of every message in this mailing list: For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com I either get a response that says that I've illegally populated the Subject: field (when I haven't) or else I get no response at all. If someone could send me private email on how to *reliably* unsubscribe to this list, I promise never to fill your mailbox with unwanted bits again. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com Hal Purdy

1 0

Progress indicator forbidden in setup
by POSE Laurent FTRD/DAC/ISS 09 Oct '02

09 Oct '02

Hello, could anybody can explain me why the progress indicator has been set to "forbidden" in the setup message? (H.225v4 §7.3.10) when H.323 is used in VoIP trunking between 2 ISUP networks, the lack of this information has an impact on the selection of the called ISDN terminal (for exemple : if a fax and a telephone are behind a PABX and if BC=3.1kHz, without the progress indicator, fax terminal can pick up the call instead of the telephone) Thank you. Laurent Posé France Telecom. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Active work within IETF AVT related to QOSMON
by Alan Clark 08 Oct '02

08 Oct '02

The IETF AVT group is the responsible standards group for RTP/RTCP (RFC1889). RTCP already provides some end-to-end statistics on packet loss and jitter and is in use within the industry to support VoIP management. It was recognized within AVT that RTCP does not provide enough information to support monitoring of VoIP calls and diagnosis of typical problems. Several individual drafts related to the use of RTCP for extended metrics reporting were combined together at the last (Yokohama) meeting to form a working group draft. The RTCP Reporting Extensions provides a series of useful metrics to specifically support Voice over IP call management. These include:- - Packets lost (cumulative) - Packets discarded due to jitter (cumulative) - For loss and discard combined - mean burst length - mean burst density - mean gap length - mean gap density - Round trip delay (mS) to RTP terminating points - End system delay (mS) from RTP terminating point through to "analog" interface - Mean signal level during silence periods (dBo) - Mean signal level during talkspurts (dBo) - Doubletalk ratio - R factor - External network R factor (supports interconnection to other networks) - MOS-LQ (estimated listening quality MOS) - MOS-CQ (estimated conversational quality MOS) - Jitter buffer parameters (fixed/adaptive, size) - Packet loss concealment (silence insertion, simple extrapolation, robust) Attached is a recent working draft of this document, this will be updated and released in the very near future. Alan Clark Telchemy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

TD on Multiple Payload Streams
by Terry L Anderson 08 Oct '02

08 Oct '02

I have uploaded a document to the avc-site incoming directory, summarizing work from the Raleigh meeting on the definition of Multiple Payload Streams for inclusion in H.245. It has been submitted as a Rapporteur's TD to the Geneva meeting. td-xxx_MPS.doc Mr Okubo will you please move it to the 0210_Gen directory? -- ------------------------------------------------------------ Terry L Anderson, CMTS mailto:tla@lucent.com Tel:732.949.5628 Fax:732.949.7016 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

FW: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.tx t
by Tom-PT Taylor 07 Oct '02

07 Oct '02

In view of the use of SDP by H.248.1 and by parts of BICC, this discussion of the interpretation of the bandwidth line may be of interest. The question is what the bandwidth estimate is intended to include beyond the media SDUs themselves. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Monday, October 07, 2002 7:23 AM To: IETF MMUSIC WG Cc: IETF AVT WG; IETF SIPPING WG Subject: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt Hi all, I have submitted a draft that discuss and tries to address the problem with having IP and transport level as a part of the SDP bandwidth modifiers. Specifically it looks at the b=AS:<bw-value>. The problems is several, but one of the major is a result of having two IP versions deployed and having translation between the two. Also header compression and future transport protocols (DCCP) creates problems. So any person working with protocols using SDP (SIP, SAP, RTSP) or working with SDP and SDP-NG should look at this draft. Until it becomes available in the IETF directories it can be fetched from here: <http://standards.ericsson.net/westerlund/draft-westerlund-mmusic-sdp-bwpara m-00.txt > Discussion is encouraged and any comments should be directed to the MMUSIC mailing list. SO PLEASE remove the other lists when replying. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)era.ericsson.se _______________________________________________ mmusic mailing list mmusic(a)ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Uploaded contribution
by Even, Roni 06 Oct '02

06 Oct '02

Mr. Okubo, I uploaded a draft of H.323 V5 to the incoming directory Roni Even ********************************************** Roni Even VP Product Planning Polycom Network Systems Tel: +972-3-9251200 Mobile: +972-55-481099 Fax: +972-3-9211571 Email: roni.even(a)polycom.co.il ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: geneva contributions
by OKUBO Sakae 04 Oct '02

04 Oct '02

Dear Gary, Paul and all, At 13:02 -0400 02/10/04, Gary Thom wrote: >I have placed two contributions into the incomming directory: > >Draft H.460.4 >Draft Proposed Canges to H.246 Annex C At 17:28 -0400 02/10/04, Paul E. Jones wrote: >A document related to directory services was uploaded to the >Incoming directory of the AVC Site. That is a contribution >submitted on behalf of Cisco for Q4/16. These three documents have been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/h.460.4.zip http://standard.pictel.com/ftp/avc-site/0210_Gen/h246AnnexCchanges1.zip http://standard.pictel.com/ftp/avc-site/0210_Gen/DirectoryServices.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

1 0

Re: Document in /Incoming
by OKUBO Sakae 04 Oct '02

04 Oct '02

Dear Mr. Horvath, At 09:27 +0200 02/10/04, Horvath Ernst wrote: >I placed a contribution in /Incoming. > >Title: "H460-qosmon-2nd-draft" This has been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/ PS: Somehow the reflector is very prudent in distributing the posting at the moment. You may see this some hours later. -- 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: avc-site posting
by OKUBO Sakae 03 Oct '02

03 Oct '02

Dear Paul and all, At 12:01 -0400 02/10/03, Paul E. Jones wrote: >I just uploaded "H225AnnexG_V2_final_revision.zip". This contains >the H.225.0 Annex Gv2 draft we're considering for consent. This documents has been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/ -- 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: Q.G contributions
by OKUBO Sakae 03 Oct '02

03 Oct '02

Dear Mr. Euchner and all, Your contributions have been placed at: http://standard.pictel.com/ftp/avc-site/0210_Gen/ >Siemens AG Q.G, Q.2/16 >Changing the manner how media padding works for H.235. >Editor H.235 Q.G >Acknowledged key update in H.235V3. >Editor H.235 Q.G, Q.2, Q.3, $B!D (B/16 >H.235 Changes to the H.323 Implementors Guide. >Siemens AG Q.G >Authentication-only option in H.235V3 Annex D. >Siemens AG Q.G, Q.2, Q.3/16 >RTP Payload Type and Improved EncryptionSync in H.235V3 >Editor H.235 Q.G >Draft H.235 VERSION 3 - SECURITY AND ENCRYPTION FOR H-SERIES (H.323 >AND OTHER H.245-BASED) MULTIMEDIA TERMINALS >Editor H.235AnnexG Q.G, 2, 3/16 >Draft H.235 Annex G: Secure Real Time Transport Protocol (SRTP) >Usage within H.235 -- 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

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

H.460.QoSMon
by Tom-PT Taylor 19 Sep '02

19 Sep '02

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

Correction Of (was) H.248 Annex M.4: Packages for H.323/H.324 int erworking
by Tom-PT Taylor 19 Sep '02

19 Sep '02

H.248 Annex M.4 has an erroneous view of the role of the MUX descriptor, which I failed to catch before the document was approved. The question is: how far have people taken their implementations? Would it be possible to redo this part of the document correctly? 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 simao.campos＠itu.int 19 Sep '02

19 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

1 0

PictureTel Site Blocked
by Tom-PT Taylor 18 Sep '02

18 Sep '02

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

1 0