November 2000 - sg16-avd - lists.packetizer.com

Please fix this list server
by Chip Sharp 14 Nov '00

14 Nov '00

One way to avoid cascading auto-mail meltdowns is to change the list server so it does not replace the "Reply-To" address with the list name address. Thus, anyone that selects "reply" to an email will send the reply back to the original sender. "reply all" will send the reply to the original sender and the list. It seems that many companies have now instituted anti-virus filters that automatically generate a message back to the "Reply-To" address when they receive a virus. Can this list setup be changed to this mode? Thanks, Chip At 01:49 AM 11/15/00 +0000, you wrote: >****** Message from InterScan E-Mail VirusWall NT ****** > >Sent >>> RCPT TO:<Marek.Przybyszewski(a)DE.BOSCH.COM> >Received <<< 550 5.7.1 Unable to relay for Marek.Przybyszewski(a)de.bosch.com > >Could not deliver mail to this user. > >***************** End of message *************** >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA02481 > for <Marek.Przybyszewski(a)DE.BOSCH.COM>; Wed, 15 Nov 2000 02:48:37 > +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma002473; Wed, 15 Nov 00 02:47:33 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA28705; > Tue, 14 Nov 2000 17:41:22 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1468 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:41:21 -0800 >Received: from gwa2.fe.bosch.de (gwa2.fe.bosch.de [194.39.218.2]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27895 for > <ITU-SG16(a)mailbag.cps.intel.com>; Tue, 14 Nov 2000 17:31:19 -0800 > (PST) >Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.10.2/8.10.2) id > eAF1TCw09153 for <ITU-SG16(a)mailbag.cps.intel.com>; Wed, 15 Nov 2000 > 01:29:12 GMT >X-Authentication-Warning: gwa2.fe.bosch.de: uucp set sender to > <virus-protection(a)bosch.com> using -f >Received: from fez8017.fe.internet.bosch.com(virus-in.fe.internet.bosch.de > 10.4.4.17) by gwa2.fe.bosch.de via smap (V2.1) id xma008913; > Wed, 15 > Nov 00 01:29:05 GMT >InterScan-Notification: yes >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_974251217_B78506032.R82506026" >Message-ID: <200011150129.eAF1TCw09153(a)gwa2.fe.bosch.de> >Date: Wed, 15 Nov 2000 02:20:17 +0100 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: virus-protection(a)BOSCH.COM >Subject: InterScan eManager Content Management Notification! (Attachment > Removal) >Comments: To: ITU-SG16(a)mailbag.cps.intel.com >To: ITU-SG16(a)mailbag.cps.intel.com > >Content-Type: text/plain; > charset="iso-8859-1" >X-MIME-Autoconverted: from 8bit to quoted-printable by >mailbag.cps.intel.com id RAA28705 > >******Message from InterScan E-Mail VirusWall NT****** > >The following mail was blocked by InterScan eManager Content Management. > >Source mailbox: <ITU-SG16(a)mailbag.cps.intel.com> >Destination mailbox(es): ><Bjoern.Soelch(a)TENOVIS.COM>,<Axel.Niebuhr(a)TENOVIS.COM> >Policy: Attachment Removal >Attachment file name: Navidad.exe - application/x-msdownload >Action: Replaced with text > >Attached files with executable extension have been deleted, (i.e. *.exe). >Ausführbare Attachments wurden gelöscht (z.B. *.exe) > >******************* End of message ******************* >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA26146; > Wed, 15 Nov 2000 02:28:57 +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma026048; Wed, 15 Nov 00 02:28:53 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA27603; > Tue, 14 Nov 2000 17:20:47 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1414 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:20:43 -0800 >Received: from netsys.kaist.ac.kr (netsys.kaist.ac.kr [143.248.148.90]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27507; Tue, 14 Nov 2000 > 17:10:37 -0800 (PST) >Received: from nice.etri.re.kr (nice.etri.re.kr [129.254.17.14]) by > netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id JAA21427 for > <pv_99(a)netsys.kaist.ac.kr>; Wed, 15 Nov 2000 09:05:35 +0900 >Received: from ghlee (ghlee.etri.re.kr [129.254.72.107]) by nice.etri.re.kr > (8.9.3/8.9.3) with SMTP id JAA10399 for <pv_99(a)netsys.kaist.ac.kr>; > Wed, 15 Nov 2000 09:21:33 +0900 (KST) >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_002B_01C04EEB.2D813F20" >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 >Importance: Normal >Message-ID: <NEBBKFGEOLBEAFHGPDNAEEEBCAAA.ghlee(a)nice.etri.re.kr> >Date: Wed, 15 Nov 2000 10:02:35 +0900 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: ghlee <ghlee(a)NICE.ETRI.RE.KR> >Subject: Extension of paper submission deadline of PV2001 (Nov. 30, 2000) >Comments: To: "pv(a)netsys.kaist.ac.kr" <pv_99(a)netsys.kaist.ac.kr> >To: ITU-SG16(a)mailbag.cps.intel.com ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems "The best way to pick a lock is with a key." http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Extension of paper submission deadline of PV2001 (Nov. 30, 2000)
by ghlee 14 Nov '00

14 Nov '00

<<APOLOGIES TO THOSE WHO RECEIVE THIS EMAIL MORE THAN ONCE.>> Due to the large number of requests for extensions we have extended the deadline of paper submission to PV 2001 until November 30, 2000. Inviatation to PV(Packet Video Workshop) 2001 : 30 April - 1 May 2001, Kyongju, Korea The 11th International Packet Video Workshop (PV 2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea, which was the capital city of ancient Korea (A.D 676 - A.D 935), located in 350-kilometer southeast of Seoul. The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshop has been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. In 2001, the workshop is scheduled to take place in the week following Picture Coding Symposium (PCS 2001) which will be held in Seoul, Korea on 25-27 April 2001 (http://pcs.kaist.ac.kr) We cordially invite you take part in this workshop by submitting your work. Important due date: November 30, 2000: Paper submission (Extended) January 31, 2001: Notice of acceptance March 15, 2001: Final paper delivery For more information about PV 2001, paper submission guidline and the conference city, kyongju, please check the attached file as well as the web site of http://pv2001.kaist.ac.kr. Best regards, Jae-kyoon Kim, General Chair

1 0

PCS2001 Final Call for Papers
by ghlee 14 Nov '00

14 Nov '00

Please find attached Final Call for Papers of Picture Coding Symposium 2001 to be held in Seoul, Korea during 25 April - 27 April, 2001. The deadline for paper submission, 15 October 2000, is coming soon. Updated paper submissioin information is at http://pcs.kaist.ac.kr. For further information, please send an email to pcs(a)pcs.kaist.ac.kr. We look forward to seeing you at the exciting PCS2001. Best Regards, Yo-Sung Ho ********************************************************** Yo-Sung Ho, Associate Professor Department of Information and Communications Kwang-Ju Institute of Science and Technology (K-JIST) 1 Oryong-Dong Puk-Gu Kwangju, 500-712, Korea TEL: +82-62-970-2211 FAX: +82-62-970-2204 EMAIL: hoyo(a)kjist.ac.kr **********************************************************

1 0

FECC and remote device control
by Bian 14 Nov '00

14 Nov '00

Dear Paul, experts: Some H.323 Endpoints(Such as VCON) declear that they support FECC using H.281. How do we achieve interoperability with them ? Can we use H.281 in the context of H.323? Thanks Bian Xuegong ----- Original Message ----- From: Paul E. Jones To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: Sunday, November 12, 2000 3:04 AM Subject: Re: FECC and remote device control Roni, FECC in the context of an H.323 call is supposed to be done using H.282 and H.283 through H.245. Paul

2 1

FECC and remote device control
by Roni Even 14 Nov '00

14 Nov '00

Hi, I noticed in H.323 v4 and v3 the section about remote device control 6.2.7.2. In H.323 version 2 there was a sentence in H.323 6.2.7 "A terminal that provide far-end camera control using H.281 and H.224 ....". I think that there is a confusion now about how to do FECC in H.323. 1. Is it through H.281 over H.224 in an H.245 channel or is it by H.282 over H.283 or T.120. 2. How do we achieve interoperability between v3 and v2 terminals. Thank Roni Even

3 2

Extension of paper submission deadline of PV2001 (Nov. 30, 2000)
by PV2001 Secretariat 13 Nov '00

13 Nov '00

<<APOLOGIES TO THOSE WHO RECEIVE THIS EMAIL MORE THAN ONCE.>> Due to the large number of requests for extensions we have extended the deadline of paper submission to PV 2001 until November 30, 2000. Inviatation to PV(Packet Video Workshop) 2001 : 30 April - 1 May 2001, Kyongju, Korea The 11th International Packet Video Workshop (PV 2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea, which was the capital city of ancient Korea (A.D 676 - A.D 935), located in 350-kilometer southeast of Seoul. The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshop has been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. In 2001, the workshop is scheduled to take place in the week following Picture Coding Symposium (PCS 2001) which will be held in Seoul, Korea on 25-27 April 2001 (http://pcs.kaist.ac.kr) We cordially invite you take part in this workshop by submitting your work. Important due date: November 30, 2000: Paper submission (Extended) January 31, 2001: Notice of acceptance March 15, 2001: Final paper delivery For more information about PV 2001, paper submission guidline and the conference city, kyongju, please check the attached file as well as the web site of http://pv2001.kaist.ac.kr. Best regards, Jae-kyoon Kim, General Chair

1 0

Report of the 9-10 November meeting
by Sakae OKUBO 11 Nov '00

11 Nov '00

Dear Q12-14/16 experts, I have integrated the following reports of the Geneva Rapporteur meeting into APC-2031: - General: TD-25 - Q12: TD-26 - Q13: TD-27 - Q14: TD28 and placed it at http://standard.pictel.com/ftp/avc-site/0011_Gen/APC-2031.zip ftp://ties.itu.int/u/tsg16/sg16/q12-14/APC-2031.zip Please advise me if you have any findings to improve the text. Please also note that all the TDs have been moved to /0011_Gen directory. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

fyi - the response from the IETF Transport Area to MPEG
by Scott Bradner 10 Nov '00

10 Nov '00

For your information: This is the response from the IETF Transport Area Directors to the request from MPEG to delay consideration of the AVT working group draft draft-ietf-avt-rtp-mpeg4-es-05.txt. While the specific timing of the IESG consieration takes into account SG16's timetable you can see by the response that the work itself is consistent with other RTP payloads - it is a simple solution to a specific problem. Scott Bradner Allison Mankin IETF Transport Area Directors --------------- As the Transport Area Directors of the IETF Internet Engineering Steering Group, we have carefully reviewed the technology in draft-ietf-avt-rtp-mpeg4-es-05.txt, and the points in your liaison statement to us. We have decided to continue the process of advancing the draft on the standards track. Taking in turn each of the reasons you gave for IETF to suspend this process: > there is no > consensus yet on the payload formats for the carriage of various MPEG-4 > streams in WG11. For instance, there are still strong concerns that the > payload format for MPEG-4 audio specified in > <draft-ietf-avt-rtp-mpeg4-es-05.txt>, while adequate for a range of > applications, is not appropriate for general use. We first note that the MPEG-4 audio for the ES use in the draft is an approved standard of MPEG. The AVT Working Group reached what the chairs found to be an adequate rough consensus that the audio in the draft met the requirements of the intended applications of the draft. IETF-wide Last Call comments beside your liaison statement commented only on the question of generality, and did not question the validity of the audio for the intended applications using ES payload types. Candidates for Proposed Standard may be advanced even when they have a known technical omissions (in this case, omitting alternative audio specifications). According to RFC 2026: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. The Area Directors support the need for timeliness in the case of this specification. The request from ITU-T SG16 is to be able to reference RTP encapsulations of MPEG-4 audio and video that are adequately provided by the elementary streams payload types. Future development of additional audio payload format and/or improvements in the current Audio-LATM payload format are encouraged, and will in no way be contraindicated by the Proposed Standard status of the elementary streams draft. > <draft-ietf-avt-rtp-mpeg4-es-05.txt> may not be used in the context of > MPEG-4 over IP framework in the future. Indeed, additional development of MPEG-4 specifications is needed for some applications, but the elementary streams draft is expected to serve the purpose of others. We consider the situation to be analogous to the standards for MPEG-1 and -2 in RTP. For those payloads, when an application requires only Elementary Streams, it uses an ES-only payload type, and when it requires using all of the MPEG Systems Streams format, it uses an SL payload type. > WG11 would prefer to find a design > for a single RTP payload format that would suffice for the carriage of all > MPEG-4 content over IP networks. This is not consistent with the design of RTP, which encourages distinct payload encapsulation for distinct application purposes, and has mechanisms for supporting the application layer framing (ALF) approach. The format for both the ES and SL payload types for MPEG-2 happen to be contained in one RFC (2250), but the Transport Area generally prefers for working groups to publish the specifications meeting different applications requirements as separate RFCs, so that they can mature and be modified each on their own timescale. RTP provides ample mechanism for uniquely identifying distinct payload types and for applications to signal them. The MIME declarations and payload type considerations for IANA in draft-ietf-avt-rtp-mpeg4-es-05.txt are explicit in distinguishing that the draft pertains only to elementary stream video and elementary stream LATM audio. There would be no identification or signalling difficulty for future specification of other MPEG-4 related payloads. In summary, we welcome collaboration between the AVT Working Group and MPEG to develop the additional MPEG-4 payload types for RTP, but find that the technical development and IETF standards process are best served by submitting draft-ietf-avt-rtp-mpeg4-est-05.txt for IESG approval now and thereafter advancing it, with the best intention of meeting the ITU-T SG16 timeframe. Allison Mankin and Scott Bradner IESG Transport Area Directors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

About APC-2014 and APC-2015
by SG Kim 09 Nov '00

09 Nov '00

Dear Mr. Okubo and experts, I had a plan to attand the ITU-T SG16 Q.12-14 Rapporteur Meeting Geneva, 9-10 November 2000 and submitted the contributions, APC-2014(Title : Comments to H.323 Annex K) and APC2015(Title : A Procedure for Multimedia Mail Service). But I cannot attend the meeting because of in-house problem. I apologize for the abscence of the meeting. I wrote the contributions that included comment about example 3 of H.323 Annex K. Please arrange the contributions to be discussed by experts on H.323 Annex K. I can participate in the discussion by e-mail or any other way. Thank you. Best Regards, Sang-gil Kim KTR&DG Tel : +82-2-526-5124 FAX : +82-2-526-5909 E-mail : sgk(a)kt.co.kr

1 0

Re: fastStart element in all Q.931 messages up toandincludingConnect
by Paul Long 09 Nov '00

09 Nov '00

Pete, H.225.0 says that it is optional for an EP to receive and act on these messages. The message type is encoded in the _Q.931 header_ which has a corresponding CHOICE in the ASN.1 h323-message-body type. I think you are confusing the Q.931 message-type field with the ASN.1 CHOICE component. When an EP encounters an optional Q.931 message which it does not support, it will discard this message based on the Q.931 message type and not parse all of the subsequent IEs including the User-User IE, which contains all of the tunneling stuff we are talking about. IOW, the EP will not even see all of the supposedly common fields to which you are referring. Paul Long ipDialog ---------- Original Message ---------------------------------- From: Pete Cordell <pete(a)TECH-KNOW-WARE.COM> Reply-To: Mailing list for parties associated with ITU-T Study Group 16 Date: Tue, 7 Nov 2000 17:50:05 -0000 >I mentioned this on the other list, but this is a different thread. > >As it happens it is not necessary for an EP to understand all Q.931 messages >that might contain tunnelled H.245, early or otherwise. The tunnelled H.245 >is always in the same place for all messages. All you have to do is find >the UUIE, extract the ASN.1, and chuck it to the ASN.1 decoder. As the >H.245 (and H.450) are not in the message specific part of the ASN.1 >structure it will be interpretable (sp!) in all cases*, even if SETUP >ACKNOWLEDGE and NOTIFY are sent. > >Therefore there is no need to make interpretation of CALL PROCEEDING and >PROGRESS in there entirety mandatory. > >Earlier I suggested the following text (slightly revised) should be added to >the start of the tunnelling section to cover this: > >"If an entity implements H.245 tunnelling, then it shall extract and act on >H.245 information contained in all received Q.931 messages (including those >that it does not otherwise understand) irrespective of how it decides to >handle the other elements of the Q.931 message." > >Pete. > >* The ASN.1 does actually require to have knowledge of all messages types up >to the ellipsis in h323-message-body, and up to the corresponding ellipsis >in the sub-types. However, once decoded it doesn't actually have to do >anything with these parts, which is the true burden of making them >mandatory. > >============================================= >Pete Cordell >Tech-Know-Ware >pete(a)tech-know-ware.com >+44 1473 635863 >============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 3