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

Uploaded documents
by OKUBO Sakae 31 Oct '02

31 Oct '02

Dear SG16 experts, At 11:07 +0100 02/10/30, Euchner Martin ICN M SR 3 wrote: >The latest draft H.235V3 (as in TD-28r1 WP2/16)has been uploaded to the >Incoming directory. > >Any review, or even contributions against that documents are highly >appreciated... At 12:20 -0500 02/10/30, Paul E. Jones wrote: >I uploaded several draft documents to the Incoming directory on the >avc-site: > AnnexGv2.zip > DraftH460.3.zip > H323AnnexP.zip > H460-7-Digitmap.zip > H460-8-ReQuery.zip > h460-6plen.zip They have 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: Draft H.235v3 uploaded
by Euchner Martin ICN M SR 3 30 Oct '02

30 Oct '02

Olivier, thank you for the assistance. Please note, that H.235v3 is not yet approved and depending on further contributions, text and even ASN.1 may change. So it is perhaps a bit too early to make these parts public on the ITU-T webpage. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | 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: DUBUISSON Olivier [mailto:olivier.dubuisson@francetelecom.com] Sent: Wednesday, October 30, 2002 2:18 PM To: Euchner Martin ICN M SR 3 Cc: ITU-SG16(a)echo.jf.INTEL.COM; Julien BARBEAU Subject: Re: Draft H.235v3 uploaded Euchner Martin ICN M SR 3 wrote: > > The latest draft H.235V3 (as in TD-28r1 WP2/16) has been uploaded to the > Incoming directory. FYI the ASN.1 modules of the 2000 edition of H.235 are available in the module database of the ITU-T ASN.1 Project at: http://www.itu.int/ITU-T/asn1/database/itu-t/h/h235/2000/index.html We will check and compile H.235V3 and upload the modules to the ITU-T website ASAP. -- Olivier DUBUISSON (ITU-T ASN.1 Project leader) france telecom R&D DTL/TAL - 22307 Lannion Cedex - France t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Draft H.235v3 uploaded
by Euchner Martin ICN M SR 3 30 Oct '02

30 Oct '02

The latest draft H.235V3 (as in TD-28r1 WP2/16) has been uploaded to the Incoming directory. Any review, or even contributions against that documents are highly appreciated... With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | 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 ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: Outcome of the SG16 meeting just finished
by OKUBO Sakae 30 Oct '02

30 Oct '02

Dear Mike and all, At 15:55 +0000 02/10/29, mike.nilsson(a)bt.com wrote: >I have uploaded the file H245wcmr.zip to the incoming directory. > >This is the same as the file H245wcmr5.zip thatI sent on Thursday at >4:32PM (UK time). I am assuming this was accepted by the plenary without >any changes, and is technically the same as TD-92R1(PLEN). Yes, TD-92R1(PLEN) was accepted at the beginning of SG16 session last Friday. The file has been moved to /0210_Gen directory. 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 ******************************************************************* -- $BBg5WJ] (B $B\F (B e-mail: okubo(a)giti.waseda.ac.jp ************************************************************* $B") (B239-0847 $B2#?\2l;T8w$N5V (B3-4 YRP $B#1HV4[ (B312 Tel: 0468 47 5406 $BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (BYRP $BJ,<< (B Fax: 0468 47 5413 $B") (B169-0051 $B!!!!!!!!!!!!!!!!!!!! (B $BEl5~ET?7=I6h@>Aa0pED (B1-3-10 $B!!!! (BTel: 03 5286 3831 $BAa0pEDBg3X (B29-7 $B9f4[!!!!!!!!!!!! (B Fax: 03 5286 3832 $BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (B ************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Results of SG 16 posted on the web
by simao.campos＠itu.int 29 Oct '02

29 Oct '02

Dear colleagues, For your information, the results of SG 16 meetings are posted on the WEB at http://www.itu.int/ITU-T/studygroups/com16/results.html Thanks to the rapporteurs who put together the executive summaries! There you also find the list of (with links to) documents approved, etc. 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 ===================================================================== ***** Practice random kindness and senseless acts of beauty ***** =====================================================================

1 0

H.ldap - Directory Services Architecture
by OKUBO Sakae 29 Oct '02

29 Oct '02

Dear SG16 experts, This is a posting from Q.4 Rapporteur. We discussed the subject matter in Geneva and its outcome is contained in the WP2 meeting report: http://standard.pictel.com/ftp/avc-site/0210_Gen/ WP2_Report_TD65_revised.zip -- report of the discussions Q.4 report refers to the H.ladap workplan in TD-61 (WP2). This document is now available at the above place as: Directory_Services_Workplan.zip Your contributions are welcome toward the next Rapporteur meeting planned next February. 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 ******************************************************************* -- $BBg5WJ] (B $B\F (B e-mail: okubo(a)giti.waseda.ac.jp ************************************************************* $B") (B239-0847 $B2#?\2l;T8w$N5V (B3-4 YRP $B#1HV4[ (B312 Tel: 0468 47 5406 $BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (BYRP $BJ,<< (B Fax: 0468 47 5413 $B") (B169-0051 $B!!!!!!!!!!!!!!!!!!!! (B $BEl5~ET?7=I6h@>Aa0pED (B1-3-10 $B!!!! (BTel: 03 5286 3831 $BAa0pEDBg3X (B29-7 $B9f4[!!!!!!!!!!!! (B Fax: 03 5286 3832 $BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (B ************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Fwd: Re: Fw: SG16 meeting closure
by OKUBO Sakae 28 Oct '02

28 Oct '02

Dear Mr. Bhargava, At 14:49 -0500 02/10/28, Vivek Bhargava wrote: >I have uploaded the H.323 Implementers Guide as submitted for >approval to the incoming directory of the PictureTel site. Please >move it to the appropriate directory - Geneva_0210. It is now available at the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/IG_H323-October2002.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

Outcome of the SG16 meeting just finished
by OKUBO Sakae 25 Oct '02

25 Oct '02

Dear SG16 experts, I have placed the WP2 reports at the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/ WP2_Report_TD64_revised.zip -- list of consented and approved texts WP2_Report_TD65_revised.zip -- report of the discussions WP2_Report_TD66_plen.zip -- liaisons statements WP2_Report_TD67_plen.zip -- interim Rapporteur meeting Please note that the next Rapporteur meeting is planned during 11-14 February 2003. Its details are yet to be fixed. Using this opportunity, I would request Rapporteurs and Editors to upload the output documents at ftp://standard.pictel.com/avc-site/Incoming/ 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: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Tom-PT Taylor 17 Oct '02

17 Oct '02

Actually, all I meant to do was to provide a neutral summary. Consultations within my organization seem to tend toward the point of view that the discrepancy is not a big deal and it would be better to preserve backward compatibility. -----Original Message----- From: Rajesh Kumar [mailto:rkumar@cisco.com] Sent: Thursday, October 17, 2002 2:35 PM To: Taylor, Tom-PT [CAR:B602:EXCH] Cc: tsg11bicc(a)ties.itu.ch; tsg11q15(a)ties.itu.ch; ITU-SG16(a)echo.jf.INTEL.COM; avt(a)ietf.org; mmusic(a)ietf.org; hwildfeu(a)cisco.com; mgarakan(a)cisco.com; ddeliber(a)cisco.com; Michael Frendo; Cary FitzGerald; Richard Platt; oran(a)cisco.com; mmostafa(a)cisco.com Subject: Re: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers Steve and AVT/MMUSIC colleagues, Our position, which has not changed since we brought up this issue to the notice of the IETF, is similar to Tom's. We would like to see the packetization of G.726 over RTP be made identical to what is defined for AAL2 in the ITU I.366.2 recommendation. In this regard, we strongly recommend that the audio MIME subtypes G726-16, G726-24, G726-32, and G726-40 be aligned to the ITU I.366.2 recommendation. This alignment would include the static payload type 2. If there is a need to interoperate with the "other," non-ITU packing scheme, we recommend that new MIME types be defined for those non-ITU schemes rather than for ITU-compatible schemes, which we think should be associated with the current MIME definitions. Rajesh Kumar Cisco Systems At 08:33 AM 10/15/2002 -0400, Tom-PT Taylor wrote: For your action if it affects you. There is a clash between the packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2 packetization universally. Comments are requested. -----Original Message----- From: Stephen Casner [mailto:casner@packetdesign.com] Sent: Tuesday, October 15, 2002 1:31 AM To: mmusic(a)ietf.org Subject: [MMUSIC] 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. * ******************************************************************** _______________________________________________ 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

Re: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Rajesh Kumar 17 Oct '02

17 Oct '02

Steve and AVT/MMUSIC colleagues, Our position, which has not changed since we brought up this issue to the notice of the IETF, is similar to Tom's. We would like to see the packetization of G.726 over RTP be made identical to what is defined for AAL2 in the ITU I.366.2 recommendation. In this regard, we strongly recommend that the audio MIME subtypes G726-16, G726-24, G726-32, and G726-40 be aligned to the ITU I.366.2 recommendation. This alignment would include the static payload type 2. If there is a need to interoperate with the "other," non-ITU packing scheme, we recommend that new MIME types be defined for those non-ITU schemes rather than for ITU-compatible schemes, which we think should be associated with the current MIME definitions. Rajesh Kumar Cisco Systems At 08:33 AM 10/15/2002 -0400, Tom-PT Taylor wrote: >For your action if it affects you. There is a clash between the >packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2 >packetization universally. Comments are requested. > >-----Original Message----- >From: Stephen Casner >[<mailto:casner@packetdesign.com>mailto:casner@packetdesign.com] >Sent: Tuesday, October 15, 2002 1:31 AM >To: mmusic(a)ietf.org >Subject: [MMUSIC] 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. * >******************************************************************** > >_______________________________________________ >mmusic mailing list >mmusic(a)ietf.org ><https://www1.ietf.org/mailman/listinfo/mmusic>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

example commObject directory
by Tyler Johnson 17 Oct '02

17 Oct '02

There is a sample searchable directory that returns users and h323 dialing information at: https://videnet.unc.edu/vide-dod/ This is a web-based application that searches an underlying LDAP server that uses commObject. You can see how the commURI is used to link the user to an endpoint. You can also see how the label in commURI is used to allow users to create a friendly 'Endpoint Name' for their endpoint. This also demonstrates how endpoints can be associated with users (like 'John') or resources (like 'Conference Room 212'). Try searching for 'Jo' or all users in the United States (this second search will take a little while). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: [Fwd: Re: [Megaco] 105/102 Test calls..]
by OKUBO Sakae 17 Oct '02

17 Oct '02

Dear Christian and all, At 19:57 +1000 02/10/17, Christian Groves wrote: >I have uploaded a number of editor's drafts incoming to the SG16 meeting: >ftp://standard.pictel.com/avc-site/Incoming/ > > DC-xxx_semiperm_pkg.zip > TD-xx_ExtH324_Packages.zip > TD-xx_H223Multiplex.zip > TD-xx_LineTest_Packages.zip (H.248.17) > TD-xx_Packages_Supplement.zip > TD-xx_Profile_Packages.zip > >These will be moved to the directory: >ftp://standard.pictel.com/avc-site/0210_Gen/ >so if you can't find the files in Incoming theywill be the 0210_Gen directory. They are now in the ultimate home. 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: [Megaco] 105/102 Test calls..
by Christian Groves 17 Oct '02

17 Oct '02

G'Day, I have uploaded a number of editor's drafts incoming to the SG16 meeting: ftp://standard.pictel.com/avc-site/Incoming/ DC-xxx_semiperm_pkg.zip TD-xx_ExtH324_Packages.zip TD-xx_H223Multiplex.zip TD-xx_LineTest_Packages.zip (H.248.17) TD-xx_Packages_Supplement.zip TD-xx_Profile_Packages.zip These will be moved to the directory: ftp://standard.pictel.com/avc-site/0210_Gen/ so if you can't find the files in Incoming they will be the 0210_Gen directory. Regards, Christian Terry L Anderson wrote: > > Packages for these and other line tests are being developed and will be > published as H.248.17. Christian Groves is the editor and the lastest > draft will be presented to the ITU SG16 meeting next week. I don't > believe that Christian has uploaded a copy to the sg16 draft avc-site > but perhaps he will send you a copy or upload one to the avc-site. > > Srinivasan Krishnamoorthy wrote: > > >Hi, > > Need help with ISUP TEST calls.. > > > > Do we have ways to do the following in MEGACO .. are there > > any published extensions to tonegen.. > > > > testline (105) - automatic transmission measurement test (MGCP T/tl) > > milliwatt (102) > > > > and other testcall codes .. > > > >Thank you very much. > >-Srini > > > >_______________________________________________ > >Megaco mailing list > >Megaco(a)ietf.org > >https://www1.ietf.org/mailman/listinfo/megaco > > > > > > -- > > ------------------------------------------------------------ > 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 > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Tom-PT Taylor 15 Oct '02

15 Oct '02

For your action if it affects you. There is a clash between the packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2 packetization universally. Comments are requested. -----Original Message----- From: Stephen Casner [mailto:casner@packetdesign.com] Sent: Tuesday, October 15, 2002 1:31 AM To: mmusic(a)ietf.org Subject: [MMUSIC] 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. * ******************************************************************** _______________________________________________ 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

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