- sg16-avd - lists.packetizer.com

Re: APC allocation for H.323 Annex P
by Sakae OKUBO 30 Oct '00

30 Oct '00

Dear Mr. Wolfstein, >I have been appointed by Mr. Skran (rapportuer for Q13/16) as editor of >H.323 Annex P (modem relay over IP). I will send the initial draft for >this annex after receiving the APC number. Following some talks with Mr. >Skran, it was decided that it would be best if the draft was presented in >a joint meeting with the modem experts group, which is scheduled to take >place during the SG meeting, on Thursday, November 16th. I would like you >to allocate an APC number to the document, defined as "H.323 Annex P Draft >(modem relay over H.323)". APC-2022 has been allocated to your contribution. 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

AW: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)
by Euchner Martin 30 Oct '00

30 Oct '00

Hi Jaakko, I'm not certain, whether I really understand the purpose of the EncryptionToken. If I look at Annex G v1, H.235 Clear and CryptoTokens are always present in each Annex G message; they are conveyed within AnnexGCommonInfo and thus are already part of each annex G message. Thus, I would say, that EncryptionToken is somewhat redundant and we do not need that this way. The other question I have concerns AuthenticationRejection: Why do you reverse tunnel - that is, feed back - the tunneled message in the reject? Finally a general question: Once there was a discussion that Annex G not only be used among Border elements as currently defined in the H.225 Annex Gv1 scope, but to extend its usage for mobility purposes. If this were true, then Annex G could be applied also between the GK-VLF/BE and between HLF/BE-AuF. What is the current status of that discussion? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] Gesendet am: Montag, 30. Oktober 2000 11:11 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: [H.323 Mobility:] MD-110 uploaded (new messages to H.225 Annex G) Mr. Fortinsky et al, I have uploaded MD-110 containing a contribution on adding new, authentication related messages to the H.225 Annex G protocol, to the URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-110_AdditionOfMe ssagesToH225AnnexG.zip . I will send the contribution also to the two meetings in Geneva, but if you send comments really quickly (tomorrow) to me, I may be able to make some changes to the contribution, before distributing it. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] A revised MD-110 uploaded
by Jaakko Sundquist 30 Oct '00

30 Oct '00

Hi all again, It didn't take long to realize one more addition that I think is needed to the H.225 Annex G. There is a need to convey the User Profile from the HLF to the VLF/GK serving the User. At least the knowledge of a possible Home GK & whether or not it is mandatory for this User to use the Home GK (Service Execution in Home Administrative Domain) should be conveyed. So I'm proposing an addition of a User Profile field to the DescriptorUpdateAck message for conveying this information. The contribution can be found in: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-110b_AdditionOfM essagesToH225AnnexG.zip . If no comments arrive before an unspecified time tomorrow, this will also be the contribution for the Geneva meetings. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Uploaded Contributions
by CHATRAS Bruno FTRD/DAC/ISS 30 Oct '00

30 Oct '00

The following contributions: APC-2020 France Telecom Support of a direction indication in the generic announcement package APC-2021 France Telecom Proposed package for data transmission over analog lines have been uploaded to: ftp://standard.pictel.com/avc-site/Incoming/ Mr Okubo could you please move them to the 0011_Gen directory. Best Regards. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC-number request
by Sakae OKUBO 30 Oct '00

30 Oct '00

Dear Mr. Suzuki, Mr. Sundquist, Mr. Li, Mr. Chatras, The following APC numbers have been allocated to your contributions: APC-2016 NTT DoCoMo Support of HTTP in H.324 APC-2017 Nokia Comparison of 3GPP All IP and H.323 Annex H architectures APC-2018 UCLA, Samsung Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-2019 UCLA, Samsung Proposals for H.323 Annex I APC-2020 France Telecom Support of a direction indication in the generic announcement package APC-2021 France Telecom Proposed package for data transmission over analog lines 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

Re: APC Number Request
by Sakae OKUBO 30 Oct '00

30 Oct '00

Dear Mr. Sang-gil Kim, The following APC numbers have been allocated to your contributions: APC-2014 >Source: Korea Telecom >Title: Comment to H.323 Annex K APC-2015 >Source: Korea Telecom >Title: A Procedure for Multimedia Mail Service 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

[H.323 Mobility:] MD-110 uploaded (new messages to H.225 Annex G)
by Jaakko Sundquist 30 Oct '00

30 Oct '00

Mr. Fortinsky et al, I have uploaded MD-110 containing a contribution on adding new, authentication related messages to the H.225 Annex G protocol, to the URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-110_AdditionOfMe ssagesToH225AnnexG.zip . I will send the contribution also to the two meetings in Geneva, but if you send comments really quickly (tomorrow) to me, I may be able to make some changes to the contribution, before distributing it. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC-number request
by Jaakko Sundquist 30 Oct '00

30 Oct '00

Hi again, I forgot one APC-number: "Comparison of 3GPP All IP and H.323 Annex H architectures" - as a Nokia contribution. I hope, I'm still on time... thanks in advance anyway. -Jaakko Sundquist > -----Original Message----- > From: EXT Sakae OKUBO [mailto:okubo@giti.waseda.ac.jp] > Sent: 29. October 2000 18:21 > To: jaakko.sundquist(a)nokia.com > Cc: Q.12-14/16 Reflector; wg5-3 TTC > Subject: Re: APC-number request > > > Dear Mr. Sundquist > > APC numbers have been allocated as follows: > > >Could you allocate APC-numbers for me for the following > contributions: > > APC-2011 > >"H.323 Annex H Draft" - as the editor contribution > > APC-2012 > >"New messages to the H.225 Annex G protocol" - as a Nokia > contribution > > APC-2013 > >"Changes to the H.323 Annex H" - as a Nokia contribution. > > 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

Questions on SDL keys used in H.245
by Lin Liu 29 Oct '00

29 Oct '00

Dear experts, I am a PhD student working in the area of modelling and analysis of communication protocols with formal methods. Currently I am looking at the H.245 recommendation. I have got a trivial question about the SDL keys used in H.245 (published in 05/99). In Figure C.1/H.245 -SDL key, "signal from protocol user" (the one with double vertical lines at the right side) and "local signal received" (the one with single vertical line) are defined as different SDL keys. But in the SDL specifications of some H.245 procedures, it seems that these two keys (as well as "signal to protocol user" and "local signal sent") are used undistinguishably. For example, in Figure C.9/H245 - Incoming CESE SDL, "local signal received" key is used for primitive "TRANSFER.response", which expected by me to be reprensentated as key "signal from protocol user" because it IS the primitive issued by the CESE user. There are some other simliar situations in this and other figures as well. I feel confused with these, is there anything inside the protocol which I have not got yet or is it the problem with misusing the SDL keys ? Could anybody interested in this can give me some hints ? Looking forward to your reply. Thanks a lot. Lin Liu ================ PhD student School of Electrical and Information Engineering University of South Australia The Mawson Lakes Campus, SA 5095, Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contributions Uploaded
by Christian Groves 29 Oct '00

29 Oct '00

Hello, Contributions: APC-1997 Editor (C Groves) Draft H.248 Implementors' Guide APC-1998 Editor (C Groves) Draft H.248 Annex K - Generic Announcement Package APC-1999 Editor (A Heidermark) Draft H.248 Annex L - Error Code and Service Change Reason Description APC-2000 Ericsson H.248 Annex x - Load Control Package APC-2001 Ericsson Direction in H.248 annex K APC-2002 Ericsson Signal on Root for H248v2 Have been uploaded to : ftp://standard.pictel.com/avc-site/Incoming/ Mr. Okubo could you please move these to the //standard.pictel.com/avc-site/0011_Gen directory? Regards, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-number request
by Jaakko Sundquist 29 Oct '00

29 Oct '00

Mr. Okubo, Could you allocate APC-numbers for me for the following contributions: "H.323 Annex H Draft" - as the editor contribution "New messages to the H.225 Annex G protocol" - as a Nokia contribution "Changes to the H.323 Annex H" - as a Nokia contribution. Thanks in advance. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

List of APC documents
by Sakae OKUBO 29 Oct '00

29 Oct '00

Dear Q12-14/16 experts, Thsi is to remind you of the following deadlines for the input contributions to the Q12-14/16 Rapporteur meeting on 9-10 November: /// Registration of the document: by 23:59 UTC, 30 October /// /// Distribution of the document: by 23:59 UTC, 2 November /// /// Use the ftp site (or e-mail reflector) for distribution /// Please find attached a current list of registered documents. Its Word file is available as: http://standard.pictel.com/ftp/avc-site/0011_Gen/0011_Gen.doc 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 *********************************************************** Documents of the Q.12-14/16 Geneva meeting (9-10 November 2000) APC-1950 SG11 (Q.BIC/11) Liaison To SG 12, SG 13 And SG 16 Asking For Guidance On Quality Of Services to be Supported with the BICC Protocol APC-1951 Study Group 11 BICC Special Rapporteurs Liaison to SG 16 proposing some additional clarifications in the H.323 Implementers Guide for H.246 Annex C. APC-1952 SG 11 Joint Special Rapporteurs for BICC Support of directionality in "H.248 Annex K - Announcement Package" APC-1953 Accord Networks Support bi directional channels in annex C fast start APC-1954 Lucent Technologies, NTT DoCoMo H.324 Annex C multimedia call package for H.248 APC-1955 NTT DoCoMo, NEC Identification of references to IETF Documents in H.225.0 version 4 (per Recommendation A.5) APC-1956 Oki Electric Adding ServiceControl fields to LCF/LRJ APC-1957 Editor (P Jones) H.323 Implementor's Guide APC-1958 Editor (P Jones) H.323 v4 APC-1959 Editor (O Levin) H.323 Annex O Draft APC-1960 Lucent Technologies Proposal to create an SDL representation of H.248 APC-1961 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding Section B.4.3 APC-1962 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the password and shared secret APC-1963 Editor (M Euchner) Clarification on the use of sendersID and generalID in white Draft H.235 Version 2 APC-1964 Editor (M Euchner) REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS - CORRECTED VERSION FOR DECISION APC-1965 Editor (M Euchner) Draft H.235 Version 3 - Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 Editor (M Euchner) Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 Editor (M Euchner) Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 Mobile Environments" APC-1968 Editor (T Anderson) Draft H323 Annex R APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 APC-1978 AT&T Mobility Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1979 AT&T Application Layer QOS Signalling Architecture and Protocol: H.323 Application Specific and Generic Value Added Services APC-1980 AT&T Common Value Added Intelligent Backend Services (BES) Protocols for all Applications APC-1981 Editor (K Klaghofer) Editorial comments to H.450.9 White document (COM16-117E) APC-1982 Editor (K Klaghofer) H.450.10 Call Offer Supplementary Service for H.323 APC-1983 Editor (K Klaghofer) H.450.11 Call Intrusion Supplementary Service for H.323 APC-1984 Editor (M Fortinsky) H.225.0 Annex G version 2 APC-1985 VocalTec Communications H.225.0 Annex G Profile Negotiation APC-1986 VocalTec Communications Clarifications Related to H.225.0 Annex G Service ID's APC-1987 Editor (F Audet) H.323 Annex M.1 - QSIG tunnelling APC-1988 PictureTel RTP Payload Types in H.245 APC-1989 PictureTel Proposed New H.245 messages for H.263++ Annex U and Annex W.6.3.12 APC-1990 Comverse Network Systems H.225.0 Annex G v2: support for Service Zone APC-1991 Comverse Network Systems H.225.0 v4: Enhancing SupportedProtocols to indicate video APC-1992 Siemens {to be advised} APC-1993 Siemens {to be advised} APC-1994 Siemens {to be advised} APC-1995 Lucent Technologies Issues for H.248 implementors' guide APC-1996 Nortel Networks Proposed corrections to H.323v4 Annex D on T.38 fax switchover APC-1997 Editor (C Groves) Draft H.248 Implementors' Guide APC-1998 Editor (C Groves) Draft H.248 Annex K - Generic Announcement Package APC-1999 Editor (C Groves) Draft H.248 Annex L - Error Code and Service Change Reason Description APC-2000 Ericsson H.248 Annex x - Load Control Package APC-2001 Ericsson Direction in H.248 annex K APC-2002 Ericsson Signal on Root for H248v2 APC-2003 France Telecom Mobility management protocol in H.323 Annex H APC-2004 Editor (M Buckley) Latest Draft of Annex N of H.323 APC-2005 Lucent Technologies Transport QoS Parameters and Traffic Descriptor for QoS Characterisation in H.323 systems APC-2006 Editor (M Buckley) Latest draft of TIPHON DTS05003 "End to End Quality of Service Control and Signalling in TIPHON Systems" APC-2007 Editor (A Heidermark) Editorial changes to Annex H to H.248 APC-2008 Editor (A Heidermark) Editorial changes to Annex I to H.248 APC-2009 LM Ericsson Use of Call Independent Signalling for Service Control APC-2010 Nortel Networks Use of inband tones in H.323 using special RTP payload types ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: MPEG-4 elementary streams in H.323
by Scott Bradner 28 Oct '00

28 Oct '00

As has been mentioned before in this thread the AVT working group is currently evaluating draft-ietf-avt-rtp-mpeg4-es-05.txt. The IESG received the following liaison statement from ISO/IEC JTC1/SC29/WG11 (MPEG). We (the Transport Area Directors) would like to hear from SG16 (or at least the people on this list and anyone else who cares to comment) if they have any comments on this liaison statement or advice to us about what we should do at this time. Allison Mankin & Scott Bradner ---------- INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO ISO/IEC JTC 1/SC 29/ WG 11 N3694 October 2000, La Baule Title: Liaison Statement to IETF on MPEG-4 on IP Source: WG11 Status: Approved WG11 has progressed in the development of a framework for the carriage of MPEG-4 content over IP networks, and we have included the recent version, N3718, for your information. WG11 understands that for the carriage of MPEG-4 elementary streams over IP networks, there is an Internet-Draft <draft-ietf-avt-rtp-mpeg4-es-05.txt> eligible for promotion to a standards track RFC. However, 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. That is, <draft-ietf-avt-rtp-mpeg4-es-05.txt> may not be used in the context of MPEG-4 over IP framework in the future. 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. Therefore, WG11 is concerned about promotion of <draft-ietf-avt-rtp-mpeg4-es-05.txt> to standards track RFC because of possible interoperability problems between different types of terminals using MPEG-4 content. WG11 recommends that IETF suspend promotion to standards track RFC of all IETF drafts related to the carriage of MPEG-4 content over IP networks and wait for WG11 to finalize its current work on a generic solution that includes framework and payload formats for the carriage of MPEG-4 content over IP networks. WG11 commits to the following schedule: Draft of framework at La Baule meeting Finalization of framework by December 1st, 2000 Finalization of generic payload format by December 1st, 2000 Finalization of video payload format by December 1st, 2000 Finalization of audio payload format by January 2001 Finalization of FlexMux payload format by January 2001 WG11 is aware that the ITU-T wishes to move forward with the adoption of an RTP payload specification for MPEG-4 Elementary Streams into the H.323 suite Recommendations. Therefore, in a companion liaison statement to ITU-T SG 16, WG11 has requested that ITU-T either delay the decision for the affected H.323 suite Recommendations or allow an interim revision without incurring a long delay such as two years. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC number request for November Rapporteur meeting
by Sakae OKUBO 28 Oct '00

28 Oct '00

Dear Mr. Bougant, Mr. Buckley, Mr. Freundlich, Mr. Skjaeran, Mr. Audet, The following APC numbers have been allocated to your contributions. APC-2003 France Telecom Mobility management protocol in H.323 Annex H APC-2004 Editor (M Buckley) Latest Draft of Annex N of H.323 APC-2005 Lucent Technologies Transport QoS Parameters and Traffic Descriptor for QoS Characterisation in H.323 systems APC-2006 Editor (M Buckley) Latest draft of TIPHON DTS05003 "End to End Quality of Service Control and Signalling in TIPHON Systems" APC-2007 Editor (A Heidermark) Editorial changes to Annex H to H.248 APC-2008 Editor (A Heidermark) Editorial changes to Annex I to H.248 APC-2009 LM Ericsson Use of Call Independent Signalling for Service Control APC-2010 Nortel Networks Use of inband tones in H.323 using special RTP payload types 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

[H.323 Mobility:] MDs uploaded
by Jaakko Sundquist 27 Oct '00

27 Oct '00

Hi all, I have uploaded two MDs to the URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/ . MD-107 includes refinements to the H.323 Annex H abbreviations and definitions. The original idea was to make the definitions more 3G-like, but as I went through them, I did not find too much that could be made more 3G-like, so the contribution became rather just a general refinement of the terms. Contributions for the 3Gfication are VERY welcome. MD-108 includes a comparison and mapping between the 3GPP all IP netwrok architecture and the H.323 Annex H architecture. Have a nice weekend, everyone. - Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution number
by Sakae OKUBO 27 Oct '00

27 Oct '00

Dear Mr. Audet, Dear Mr. Groves, The following APC numbers have been allocated to your contributions: APC-1996 Nortel Networks Proposed corrections to H.323v4 Annex D on T.38 fax switchover APC-1997 Editor (C Groves) Draft H.248 Implementors' Guide APC-1998 Editor (C Groves) Draft H.248 Annex K - Generic Announcement Package APC-1999 Editor (C Groves) Draft H.248 Annex L - Error Code and Service Change Reason Description APC-2000 Ericsson H.248 Annex x - Load Control Package APC-2001 Ericsson Direction in H.248 annex K APC-2002 Ericsson Signal on Root for H248v2 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

Annex I
by Baese Gero 27 Oct '00

27 Oct '00

Dear Mr. Aronson, since the last meeting in Portland there is a discussion concerning Annex I, unfortunately we haven't heard your opinion as an expert on this area. What do you think about the discussed technical topics as well as the provided test conditions ? Can you please comment on that ? Thank you very much. Best wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: MPEG-4 elementary streams in H.323
by Stephan Wenger 26 Oct '00

26 Oct '00

Gary, Experts, The MPEG-ES I-D is in IESG last call since 10/17. I believe that it is neither to SG16 and certainly not to MPEG to decide of its movement forward. For SG16 it is, however, relevant, that the assignment of an RFC number follows the IESG approval at considerable delay, typically several weeks. Unless someone is pushing the RFC editor really hard, the ES-I-D will not have a RFC number assigned in time for the SG meeting. I don't know what the SG should do regarding the determined code points referencing the draft. If someone wants to stop the progress of the I-D now, the right action would be to announce so, including technical reasons, on the rem-conf reflector. Before doing so I would like you to consider the following: MPEG systems wants, for their own reasons, to promote MPEG systems, not only the media coding schemes. Many (including me) believe that the current system specification cannot be delivered over lossy networks. For that reason, the I-D focusing on the transmission of MPEG systems (SL-draft by Civanlar et. al) will likely move forward as "experimental" only, and not as standards track. I'm not sure that MPEG knows the difference, and I'm also not sure whether we in the ITU allow to normatively reference an experimental RFC. Would be nice to see this clarified. Stephan At 01:50 PM 10/26/2000 -0700, Gary Sullivan wrote: >ITU-T Systems and Video Experts, > >I am at an MPEG meeting in France. There has been a lot of recent >discussion here and in the IETF on how to carry MPEG-4 data on IP >networks. I was asked by some MPEG participants to help explain >and understand the impact of this work on ITU-T SG16. > >My understanding is that the H.323 community has been expecting >an IETF RFC with Proposed Standard status to be approved prior >to the November SG16 meeting sufficient to specify an RTP >packetization format for use in H.323 systems to carry MPEG-4 >video (and perhaps audio) elementary streams. > >However, there are some discussions here at MPEG about how to ensure >that any such specification is adequate not only for the needs of H.323 >but also for MPEG-4 systems as well. > >As a result, it appears that MPEG is poised to recommend tomorrow >that the current Kikuchi-san Internet Draft not be promoted to >Proposed Standard RFC status in the IETF. This seems to mean >that we are unlikely to be able to reach Decision status for this >feature in H.323 in November in SG16. > >The SG16 community needs to understand this unfortunate situation >and its impact on the progress of work for the SG 16 meeting in November. > >Best Wishes, > >Gary Sullivan > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

MPEG-4 elementary streams in H.323
by Gary Sullivan 26 Oct '00

26 Oct '00

ITU-T Systems and Video Experts, I am at an MPEG meeting in France. There has been a lot of recent discussion here and in the IETF on how to carry MPEG-4 data on IP networks. I was asked by some MPEG participants to help explain and understand the impact of this work on ITU-T SG16. My understanding is that the H.323 community has been expecting an IETF RFC with Proposed Standard status to be approved prior to the November SG16 meeting sufficient to specify an RTP packetization format for use in H.323 systems to carry MPEG-4 video (and perhaps audio) elementary streams. However, there are some discussions here at MPEG about how to ensure that any such specification is adequate not only for the needs of H.323 but also for MPEG-4 systems as well. As a result, it appears that MPEG is poised to recommend tomorrow that the current Kikuchi-san Internet Draft not be promoted to Proposed Standard RFC status in the IETF. This seems to mean that we are unlikely to be able to reach Decision status for this feature in H.323 in November in SG16. The SG16 community needs to understand this unfortunate situation and its impact on the progress of work for the SG 16 meeting in November. Best Wishes, Gary Sullivan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Documents uploaded
by Francois Audet 26 Oct '00

26 Oct '00

Bob, I believe in your Annex M.3 draft, it should say H.245 v7 instead of v6 in the ASN.1 in the Summary section since we mandated v7 for H.323v4 at the last meeting. > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, October 26, 2000 11:14 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Documents uploaded > > > The following documents for the November 9-10, 2000 Raporteur > meeting in > Geneva have been uploaded to the PictureTel site: > > APC-1974 Editor (R Callaghan) > H.450.12 - Common Information Additional Network Feature for H.323 > > APC-1975 Editor (R Callaghan) > H.323 Annex M.3 - Tunneling DSS1 in H.323 > > APC-1976 Siemens > H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture > > APC-1977 Siemens > Deficiencies of H.225.0 for a native transport of DSS1 > > Bob > > -------------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > 5500 Broken Sound Blvd, Boca Raton, Fl 33487 > Tel: +1 561 923-1756 Fax: +1 561 923-1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ----------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Documents uploaded
by Callaghan, Robert 26 Oct '00

26 Oct '00

The following documents for the November 9-10, 2000 Raporteur meeting in Geneva have been uploaded to the PictureTel site: APC-1974 Editor (R Callaghan) H.450.12 - Common Information Additional Network Feature for H.323 APC-1975 Editor (R Callaghan) H.323 Annex M.3 - Tunneling DSS1 in H.323 APC-1976 Siemens H.323 Annex M.3 - Tunneling DSS1 in H.323 - Architecture APC-1977 Siemens Deficiencies of H.225.0 for a native transport of DSS1 Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Sanity check on Packet Sizes....
by Chip Sharp 26 Oct '00

26 Oct '00

As Brian says, there are several different answers. In reality, the max length IP packet supported is constrained by the MTU (max transmission unit) supported by the host at each end (usually a function of receive buffers) and of the subnets in the path. Since IP is an internetworking protocol, it runs over a number of networking technologies and protocols, each with its own frame or packet size limitation. For example, running IP over an X.25 network (e.g., ISDN D-channel X.25) might limit the MTU size to 128 octets. Ethernet allows 1500 bytes. RFC1191 contains a table of MTU sizes for various subnet technologies and the RFC numbers in which they are defined. I copy the table below (one advantage of having ASCII specs :-). Plateau MTU Comments Reference ------ --- -------- --------- 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring ref. [6] 17914 8166 IEEE 802.4 RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised) RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet Nets RFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3 RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576 X.25 Networks RFC 877 544 DEC IP Portal ref. [10] 512 NETBIOS RFC 1088 508 IEEE 802/Source-Rt Bridge RFC 1042 508 ARCNET RFC 1051 508 (13%) 296 Point-to-Point (low delay) RFC 1144 296 68 Official minimum MTU RFC 791 Table 7-1: Common MTUs in the Internet In a general case implementation, I would support at least 1500 bytes MTU sizes. As for your specific application (video), it might not require 1500 byte packets. Supporting some type of Path MTU Discovery (RFC1191 or RFC1981) might be useful to avoid fragmentation since some paths don't support 1500 byte MTUs. For example, many tunneling technologies (GRE, L2TP, IPSEC) reduce the effective packet size. Chip At 10:09 PM 10/25/00 -0400, Rosen, Brian wrote: >There is the "real" answer, and the practical answer. > >The real answer is that depending on what kind of network you are on, >you could see, in theory, packets of up to 64K bytes. 4K bytes can actually >be >seen in some Gig-E systems. Whether you will find a video codec using such >large packets sizes or not is uncertain; I've never seen one. > >It used to be that we thought 1510-odd bytes was the biggest practical >packet you >see on a LAN, but that's no longer the case. There is a lot of code around >that >fails above that 1500 ish number. > >Brian > > > -----Original Message----- > > From: Chris Farmer [mailto:cfarmer@smithmicro.com] > > Sent: Wednesday, October 25, 2000 9:05 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Sanity check on Packet Sizes.... > > > > > > Okay, > > > > I was researching an arcane fact on the theoretical and > > practical sizes for > > RTP packet sizes for > > video conferencing. > > > > What I have come up with is: > > There is specific RFC's about implimenting H.263, H.261, > > G.723, but I'm > > looking for just an overall > > practical size to check input buffer sizes. > > > > RFC 1889 RTP packet structure referes to 768, RFC 791 > > RFC 768 UDP refers to obsolete RFC 760. > > RFC 791 states in the Glossory, > > ARPANET messages max size is about 1012 octets (8096)bits. > > ARPANET packet max size is about 126 octets (1008) bits. > > > > As a client side EP, should I be concerned about the ARPANET > > message size or > > the ARPANET packet size? > > > > RFC 760 states: > > 65,536 octets theoretically, put not practical > > Page 22, every destination should be able to > > receive a datagram > > of 576 octets in one piece or as fragments to be reassembled > > > > so my guess here is 4608 bits max? Or is this too low level > > and there is > > another RFC that I should reference? > > > > Any help in this direction? > > > > Thanks, > > > > > > Christopher B. Farmer > > Software Engineer > > Smith Micro Software, Inc. > > (503) 641-1221 ext 28 > > ====================================================================== > > Daily C\C++ Tidbits at www.EngageUs.com\c > > "Challenges in life are inevitable. Failure is optional" - > > Roger Crawford > > ====================================================================== > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.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

Re: Sanity check on Packet Sizes....
by Roni Even 26 Oct '00

26 Oct '00

Hi, H.225.0 section 6.2.2 mandate the size of video packet not to exceed the MTU size unless the macro block is larger then the MTU. It also say that the frame have to be broken on a GOB or macroblock boundary. The reason is for robustness of information. If a packet is lost then you are losing part of the frame and can still synchronize on the rest of information or replace the missing part. Roni Even -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Thursday, October 26, 2000 4:09 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Sanity check on Packet Sizes.... There is the "real" answer, and the practical answer. The real answer is that depending on what kind of network you are on, you could see, in theory, packets of up to 64K bytes. 4K bytes can actually be seen in some Gig-E systems. Whether you will find a video codec using such large packets sizes or not is uncertain; I've never seen one. It used to be that we thought 1510-odd bytes was the biggest practical packet you see on a LAN, but that's no longer the case. There is a lot of code around that fails above that 1500 ish number. Brian > -----Original Message----- > From: Chris Farmer [mailto:cfarmer@smithmicro.com] > Sent: Wednesday, October 25, 2000 9:05 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Sanity check on Packet Sizes.... > > > Okay, > > I was researching an arcane fact on the theoretical and > practical sizes for > RTP packet sizes for > video conferencing. > > What I have come up with is: > There is specific RFC's about implimenting H.263, H.261, > G.723, but I'm > looking for just an overall > practical size to check input buffer sizes. > > RFC 1889 RTP packet structure referes to 768, RFC 791 > RFC 768 UDP refers to obsolete RFC 760. > RFC 791 states in the Glossory, > ARPANET messages max size is about 1012 octets (8096)bits. > ARPANET packet max size is about 126 octets (1008) bits. > > As a client side EP, should I be concerned about the ARPANET > message size or > the ARPANET packet size? > > RFC 760 states: > 65,536 octets theoretically, put not practical > Page 22, every destination should be able to > receive a datagram > of 576 octets in one piece or as fragments to be reassembled > > so my guess here is 4608 bits max? Or is this too low level > and there is > another RFC that I should reference? > > Any help in this direction? > > Thanks, > > > Christopher B. Farmer > Software Engineer > Smith Micro Software, Inc. > (503) 641-1221 ext 28 > ====================================================================== > Daily C\C++ Tidbits at www.EngageUs.com\c > "Challenges in life are inevitable. Failure is optional" - > Roger Crawford > ====================================================================== > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

List of participants, Rapporteur meeting on 9-10 November
by Sakae OKUBO 26 Oct '00

26 Oct '00

Dear Q12-14/16 experts, Please review the attached list of registered participants for the 9-10 November Rapporteur meeting. If you are missing or you are not correctly represented, please immediately advise me. I will send the full list to Mr. Bigi, ITU-TSB, and then he will prepare badges for your participation in the meeting held at the ITU premises. I need your cooperation to avoid any confusion/trouble at the ITU building. The meeting notice <http://standard.pictel.com/ftp/avc-site/0011_Gen/Notice_0011_Geneva.zip> says that today is the deadline for your registration. 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 *********************************************************** ----------------------------------------------------------- Family First name name Country Organization ----------------------------------------------------------- Anderson Terry USA Lucent Technologies Audet Francois USA Nortel Networks Baese Gero Germany Siemens AG / ZT IK 2 Bougan Francois FRANCE France Telecom Callaghan Robert Germany Siemens AG Coldren Rex U.S.A. Lucent Technologies Delmond Frederic FRANCE France Telecom Euchner Martin Siemens Germany Even Roni Israel Accord Networks Fortinsky Michael Israel VocalTec Communications Ltd. Freundlich Glen USA Avaya, Inc. Gilman Robert USA Avaya, Inc. Groves Christian Sweden LM Ericsson Gu Qunshan USA PictureTel Corp. Harasaki Hidenobu Japan NEC Corporation Jones Paul USA Cisco Systems, Inc. Kawahara Toshiro Japan NTT DoCoMo, Inc. Klaghofer Karl Germany Siemens AG Korpi Juha Germany Siemens AG Leibovitch Ilana Israel MOC (ECI Telecom) Levin Orit Israel RADVision Li Adam Hengkong Korea Samsung Electronics Lindbergh Dave USA PICTURETEL CORP. Maeng Joon USA VTEL Corp. Michaely Boaz Israel Comverse Network Systems (for SG meeting: Israel Ministry of Communication) Minono Satoshi Japan Oki Electric Industry Co.,Ltd Modahala Loganathan USA Cisco Systems, Inc. Okubo Sakae Japan TAO Waseda Research Center Park Jeong-Hoon Korea Samsung Electronics Potter Morgan UK BT Roelands Marc Belgium Siemens Roy Radhika R. USA AT&T Sayre Clifford USA Lucent Technologies Segers John The Netherlands Lucent Technologies Skran Dale USA Sonus Netwoks Sundquist Jaakko Finland Nokia Suzuki Takashi Japan NTT DoCoMo, Inc. ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1956(Adding ServiceControl fields to LRJ/LCF) uploaded
by Satoshi Minono 26 Oct '00

26 Oct '00

Dear Mr.Skjaeran, Please excuse my delay in answering your e-mail (Annex K over multiple domains). We have read your comments carefully and agree to them. I have posted APC-1956 (Adding ServiceControl fields to LRJ/LCF) to the Incoming directory of PictureTel ftp site. Thank you. Best regards, Satoshi Minono ---------------------------------------------------------------------------- -- Oki Electric Industry Co.,Ltd. Tel:+81-3-3454-2111 Fax:+81-3-3798-7684 e-mail:minono888@oki.co.jp

1 0