communications standards reviewitu-t sg15 wp1 network access sg15 wp2 network signal processing sg16...

December 2000 Vol. 11.11 Copyright © CSR 2000 1

COMMUNICATIONS STANDARDSREVIEW

Volume 11, Number 11 December, 2000

In This Issue

The following reports of recent standards meetings represent the view of the reporterand are not official, authorized minutes of the meetings.

ITU-T Study Group 16, MultiMedia Services, Systems and Terminals, November 13 – 17, 2000, Geneva..............3Documents Approved by Resolution No. 1....................................................................................3Future Structure of Study Group 16...............................................................................................6WP1/16, Low Rate Systems.......................................................................................................8WP2/16, Services and High Rate Systems.....................................................................................8WP3/16, Signal Processing.......................................................................................................8Q1/16 WP2, Audiovisual/multimedia Services................................................................................8Q2/16 WP2, Interactive Multimedia Information Retrieval Services (MIRS)...........................................10Q3/16 WP2, Data Protocols for Multimedia Conferencing.................................................................10Q4/16 WP1, High Speed Modems................................................................................................10Q5/16 WP1, ISDN Terminal Adapters, and Interworking of DTEs on ISDNs with DTEs on Other Networks......12Q6/16 WP1, DTE-DCE Interchange Circuits...................................................................................12Q7/16 WP1, DTE-DCE Interface Protocols.....................................................................................12Q8/16 WP1, DCE-DCE Protocols................................................................................................14Q9/16 WP1, Accessibility to Multimedia for People with Disabilities..................................................16Q10/16 WP1, Modem Testing....................................................................................................17Q11/16 WP2, Circuit Switched Network (CSN) Multimedia Systems and Terminals...................................17Q12/16 WP2, B-ISDN Multimedia Systems and Terminals.................................................................19Q13/16 WP2, Packet Switched Multimedia Systems and Terminals.......................................................20Q14/16 WP2, Common Protocols, MCUs and Protocols for Interworking with H.300-series Terminals.........30Q15/16 WP3, Advanced Video Coding..........................................................................................38Q16/16 and Q17/16, Multimedia Harmonization and Coordination......................................................40Q19/16 WP3, Extension to existing ITU-T Speech Coding Standards at Bit Rates Below 16 kbit/s...............42Q20/16 WP3, Audio and Wideband Coding in Public Telecommunication Networks..................................43Q21/16 WP3, Encoding of Speech Signals at Bit Rates Around 4-kbit/s................................................45Q22/16 WP3, Software and Hardware Tools for Standardization of Speech and Audio Coding Algorithms........48Q23/16 WP1, PCM Modems......................................................................................................50QFax1/16 WP1 (Former Questions 1/8, 4/8, and 5/8).......................................................................51QFax2/16 WP1 (Former Question 6/8)..........................................................................................57SG16 Meeting Roster, November 13-17, 2000, GenevA, Switzerland...................................................59

Partial Report of TR-41, Telecommunications Equipment Requirements, November 13 – 17, 2000, Savannah, GA.63TR-41.1, Multi-Line Telecommunication Systems...........................................................................63TR-41.1.2, Voice Quality over IP................................................................................................64TR-41.2, Conformity Assessment...............................................................................................65TR-41.3, Analog and Digital Wireline Terminals............................................................................68TR-41.3.5, Revision of TIA-470-B.............................................................................................69TR-41.4, VoIP Gateways and Infrastructures...................................................................................70TR-41.5, Multimedia-Building Distribution Systems.......................................................................70TR-41.7, Environmental and Safety Considerations.........................................................................70TR-41.9, FCC Technical Regulatory Considerations........................................................................70TR-41.10, Private ISDN Issues...................................................................................................75TR-41.11, FCC Regulatory Administrative Considerations................................................................75TR-41 Partial Meeting Roster, November 13 – 17, 2000, Savannah, GA...............................................75

Table of Contents Continued on Next Page

COMMUNICATIONS STANDARDS REVIEW

2 Vol. 11.11 Copyright © CSR 2000 December 2000

ETSI TM6 #20, Access Transmission Systems on Metallic Cables, Nov.r 27 – Dec. 1, 2000, Monterey, CA.........76ANAI.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78SDSL.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Voice Over DSL......................................................................................................................82RFI... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83VDSL.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84ADSL.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87DSL Testing and Interoperability Issues........................................................................................88Spectral Management....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88Roster of TM6 Meeting #20, Nov. 27 – Dec.1, 2000, Monterey, California...........................................90

TR-30, Data Transmission Systems and Equipment, December 4 – 8, 2000, Scottsdale, AZ...............................92TR-30.1, Modems...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92TR-30.2, Data Transmission......................................................................................................93TR-30.3, Data Communications Equipment Evaluation and Network Interfaces........................................93TR-30.1 and TR-30.2 Meeting Roster, December 4 – 8, 2000, Scottsdale, AZ.........................................94

Acronym Definitions.....................................................................................................................95Year 2001 Standards Committee Meeting Schedules as of December 20, 2000...............................................100CSR Terms of Distribution for Electronic Copies..................................................................................101

Communications Standards Reviewregularly covers the following committee meetings:

TIA TR-30 Data Transmission Systems & EquipmentTR-41 User Premises Telephone Equipment

Requirements

ITU-T SG15 WP1 Network AccessSG15 WP2 Network Signal ProcessingSG16 Multimedia

ETSI AT Access and TerminalsTIPHON Voice over InternetTM6 Transmission & Multiplexing

DSL Forum xDSL, Access Technologies

COMMUNICATIONS STANDARDS REVIEW ALSO PUBLISHES:

Communications Standards Summary (ISSN 1075-5721), a quarterly publication reporting on all activeprojects and recently completed standards of the TIA’s (Telecommunications Industry Association’s) TR-committees. Authorized by TIA.

For more details visit http://www.csrstds.com. To receive a complimentary issue of either of CSR’s technicaljournals, please contact Elaine Baskin, tel +1 650 856-9018, fax +1 650 856-6591, e-mail:[email protected]

11911



REPORT OF ITU-T STUDY GROUP 16, MULTIMEDIA SERVICES, SYSTEMSAND TERMINALS, NOVEMBER 13 – 17, 2000, GENEVA, SWITZERLAND

Study Group 16’s eighth meeting was chaired by P-A. Probst (Swisscom). As the meeting was held only fiveweeks after the WTSA-2000, the meeting was held under the structure and management in place prior to the WTSA.However, as agreed by the WTSA-2000, the meeting also incorporated the work of former ITU-T Study Group 8.For this meeting, all the ex-Study Group 8 work was considered under Working Party 1/16.

The new Alternative Approval Process (AAP) for Recommendations (Recommendation A.8) is now in place. SeeCSR Vol. 11.10 or <http://www.itu.int/itudoc/itu-t/approved/a/index.html>. Using this new process,Recommendations can be approved, without dissent, in as short as two months. It is expected that the AAP will beused for approval of all future SG16 Recommendations.

This meeting of SG16 used the structure which has been in place since 1997, i.e., with three Working Parties(WPs):

WP, Title ChairmanWP1/16, Low Rate Systems J. Magill, Lucent Technologies (UK)WP2/16, Services & High Rate Systems F. Tosco, CSELT (Italy)WP3/16, Signal Processing S. Campos Neto, Comsat (US)

For future meetings, a revised SG16 structure has been agreed, see below.

TD-15(Plen) (TSB) is the list and attribution of delayed contributions.

TD-03(Gen) (ITU) is a liaison presenting a new Patent Declaration Form for use with ITU | ISO/IEC common textRecommendations. ITU and ISO/IEC have agreed to the ITU’s proposal for a common Patent Statement andLicensing Declaration form to be used in the case where a patent exists related to material in a common textRecommendation. The concerned organizations may use this form to facilitate reporting of such patents to both ITUand ISO/IEC.

DOCUMENTS APPROVED BYRESOLUTION NO. 1

TD-16(Plen) shows the documents for Recommendations according to Resolution 1, from the Coordination meeting,Geneva, November 10, 2000. In response to TSB Circular 282 of 11 August 2000 and its addendum of 6 October2000, 15 Administrations of Member States assigned the authority to Study Group 16 to approve two corrigenda,four amendments to existing Recommendations, nine draft revised and 27 draft new ITU-T Recommendations, inaccordance with the provisions of Resolution 1. Table 1, below, shows the documents approved by Resolution 1.

Three documents were not approved, and are not included in Table 1:

• H.323 Annex L, Stimulus control protocol, was not approved due to substantial changes.

The following Recommendations, which were Determined at the previous meeting of Study Group 8, were notapproved:

• T.800 | ISO/IEC 15444-1, JPEG 2000 image coding systems, was not approved as one company indicated thatit held relevant patent(s) and was not willing to grant a license under the terms required by the ITU-T.

• T.870 | ISO/IEC 14495-2, Information Technology – Lossless and near lossless compression of continuous-tone still images: Extensions, was not approved as the text was not submitted before the required deadline.



Qx/16 RECOMMENDATION Documents*

Q1 F.700 Annex A Revised - Framework Recommendation ForAudiovisual/Multimedia Services

COM 16-R67 + TD-15 (WP2)

Q1 F.700 Annex C.2 - Middleware service elements descriptions COM 16-R67, TD-15 (WP2)Q1 F.701 - Guideline Recommendation for identifying multimedia service

requirementsCOM 16-R67

Q1 F.703 - Multimedia Conversational Services COM 16-R67Q22 G.191 Annex A – Floating point version of G.772.1 COM 16-139Q20 G.722.1 Annex B – Floating point version of G.722.1 TD-43(Plen)Q20 G.722.1 Corrigendum COM 16-133Q13 **H.225.0 (Version 4) - Call Signalling Protocols And Media Stream

Packetization For Packet-Based Multimedia Communication SystemsCOM 16-134 + TD-91(Plen)+ (TDs 2, 5, 6, 7, & 10(Plen))

Q14 H.235 Revised - Security and encryption for H-series (H.323 and otherH.245-based) multimedia terminals

COM 16-122 + TD-23(Plen)+ (TD-52(Plen))

Q14 H.245 (Version 7) - Control Protocol For Multimedia Communication COM 16-120 + TD-55(Plen)+ (TD-29(Plen))

Q13 H.246 Annex E.1 - General Inter-Working Function (IWF) BetweenMobile Application Part and H.225.0

COM 16-137 + (TD-21(Plen))

Q13 H.246 Annex E.2 – Inter-Working Function (IWF) Between ANSI-41(Americas) Mobile Application Part And H.225.0

COM 16-138 + (TD-21(Plen))

Q14 H.248 Annex F - Facsimile, text conversation and call discriminationpackages

COM 16-126 + (TD-28(Plen))

Q14 H.248 Annex G - User Interface Elements and Actions Packages COM 16-130 + TD-25(Plen)Q14 H.248 Annex H - Transport over SCTP COM 16-131 + TD-36(Plen)

+ (TD-14(Plen))Q14 H.248 Annex I - Transport over ATM COM 16-132 + TD-18(Plen)Q14 H.248 Annex J - Dynamic Tone Definition package COM 16-123Q14 H.248 Annex K - Generic Announcement package COM 16-124 + TD-38(Plen)Q15 H.262 | ISO/IEC 13818-2 Amendment 7 for video elementary stream

content description dataTD-71(Plen)

Q15 H.262 | ISO/IEC 13818-2 Corrigendum 3 for correction of reservedextension data handling

COM 16-135

Q15 H.263 Annex U – Enhanced reference picture selection COM 16-140 + TD-51(Plen)Q15 H.263 Annex V – Data partitioned slice (DPS) COM 16-140 + TD-51(Plen)Q15 H.263 Annex W – Additional Supplemental Enhancement Information COM 16-140 + TD-51(Plen)

+ (TD-19(Plen))Q13 H.323 (V.4) - Packet-Based Multimedia Communications Systems COM 16-128 + TD-59(Plen)Q13 H.323 Annex J - Security for H.323 Annex F COM 16-116Q13 H.323 Annex K - HTTP based service control transport channel in H.323 COM 16-127 + TD-68(Plen)

(+ TDs 2, 5, 6, 7, &10(Plen))

Q13 H.323 Annex M.1 - Tunnelling of Signalling Protocol (QSIG) in H.323 COM 16-118 + TD-24(Plen)Q13 H.323 Annex M.2 - Tunnelling of Signalling Protocol (ISUP) in H.323 COM 16-129 + TD-66(Plen)Q11 H.324 Annex H - Mobile Multilink Operation COM 16-119 +D.52Q13 H.450.9 - Call Completion Supplementary Services for H.323 COM 16-117 + TD-22(Plen)QFax1 T.4 Amendment 2 – Standardization of Group 3 facsimile terminals for

document transmissionCOM 8-R.15

QFax1 T.30 Amendment 2 - Procedures for document facsimile transmission inthe General Switched Telephone Network

TD-94(Plen)



QFax1 T.38 Amendment 3 - Procedures for real-time Group 3 facsimilecommunication over IP Networks

COM 8-R.15 + COM 8-114 +TD-99(Plen)

QFax1 T.89 – Application profiles for Recommendation T.88 – lossy/losslesscoding of bi-level images (JBIG) for facsimile

COM 8-115 + TD-50(Plen)

Q4 V.8 Revised - Procedures for starting sessions of data transmission overthe public switched telephone network

COM 16-R76 + TD-35(Plen)

Q4 V.8bis Revised - Procedures for the identification and selection ofcommon modes of operation between data circuit-terminating equipments(DCEs) and between data terminal equipments (DTEs) over the publicswitched telephone network and on leased point-to-point telephone-typecircuits

COM 16-R76 + TD-35(Plen)

Q9 V.18 Revised - Operating and interworking requirements for DCEsoperating in text telephone mode

COM 16-125

Q8 V.44 - Data Compression Procedures TD-30(Plen)Q8 V.59 - Managed Objects for Diagnostic Information of Public Switched

Telephone Network Connected V-Series Modem DCEsCOM 16-R77 + TD-31(Plen)

Q23 V.92 - Enhancements to Recommendation V.90 COM 16-R77 + TD-44(Plen)

* Document references in parenthesis contain Recommendation A.5 reference material.** The USA Administration invoked the 4-week rule (i.e., requested a further 4 weeks for consideration) on Annexes

E & F to Recommendation H.225.0 pending the approval of ISO documents incorporated by reference. These ISOdocuments have now been approved and so approval of the Recommendation is now complete.

Note: Some other changes were made to references in the above Recommendations to either delete them or makethem informative, to comply with Recommendation A.5.

Table 1. Documents Approved by Resolution 1 in SG16.

OTHER DOCUMENTS APPROVED BY STUDY GROUP 16

Implementers Guides and Appendices approved by SG16 are shown in Table 2.

Qx/16 Title DocumentsQ14 H.248 Implementers Guide TD-39(Plen)Q11 H.320 Implementers Guide TD-56(Plen) + TD-26(Plen)Q13 H.323 Series Implementers Guide TD-58(Plen) + TD-64(Plen)Q11 H.324 Implementers Guide TD-45(Plen)QFax1 T.38 Appendix I TD-92(Plen)QFax1 T.38 Appendix II TD-93(Plen)Q8 V.42 Appendix VI TD-48(Plen)Q7 V.250 Implementers Guide TD-63(Plen)

Table 2. Implementers Guides and Appendices approved by SG16.

DOCUMENTS STARTING THE APPROVAL PROCESS IN SG16

The documents listed in Table 3 received “consent” for approval under the AAP.



Qx/16 Title DocumentsQ19 G.729 Corrigendum to Annexes TD-42(Plen)Q12 H.222.0 Corrigendum TD-27(Plen)Q15 H.263 Annex X, H.263++ TD-53(Plen)Q13 H.323 Annex L, Stimulus control protocol TD-60(Plen)Q13 H.450.10, Call Offer Supplementary Services TD-61(Plen)Q13 H.450.11, Call Intrusion Supplementary Services TD-62(Plen)QFax1 T.30 Amendment 3 TD-95(Plen)QFax1 T.37 Amendment 2 TD-96(Plen)QFax2 T.82 Corrigendum TD-72(Plen)QFax2 *T.800, JPEG 2000 image coding systems TD-31(Gen)QFax2 *T.870, Information Technology – Lossless and near lossless

compression of continuous-tone still images: ExtensionsTD-77(Plen)

* Recommendations T.800 and T.870 were submitted for AAP approval on the basis that all IPR issues would beresolved before the last call process and that all relevant IPR statement had been received by the TSB at that time.These issues will be addressed by a meeting of the ISO JPEG committee in December 2000.

Table 3. Documents receiving “Consent” by SG16 under AAP.

FUTURE STRUCTURE OF STUDY GROUP 16

The following is the future Working Party structure of SG16 including the names of Rapporteurs where known:

WP1/16: Modems and facsimile terminals (Q.H/16, 11, 12, 13, 14/16); Chair: M. Matsumoto (Japan)WP2/16: Multimedia platform and interworking (Q.D, F, G, 1, 2, 3, 4, 5/16); Chair: F. Tosco (CSELT, Italy)WP3/16: Media coding (Q.E/16, 6, 7, 8, 9, 10/16); Chair: S. F. Campos Neto (LMGT, USA)WP4/16: Multimedia framework (Q.A, B, C/16); Chair: J. Magill (Lucent Technologies, UK)

QUESTIONS ASSIGNED TO SG16 BY WTSA-2000

The questions for SG 16 have been organized in “vertical” and “horizontal” questions. As in any matrix structure,the topics of the horizontal and vertical questions do significantly overlap. However, there is a fundamentaldifference between the “deliverables” (products) of the horizontal and vertical questions.

The horizontal questions have double purpose. The horizontal questions B-H correspond to and incorporate theFramework Study Areas (FSA), while Question A represents an “umbrella” over all horizontal questions B-H.Horizontal questions also unite “common components” to be applicable to several vertical questions (e.g.,“Accessibility,” “Security”).

A horizontal question is broader in scope than a vertical question, crosscutting in nature; it covers the area of anentire FSA or more than one FSA. A horizontal question is also the “incubator” for new study ideas and it shallmaintain a “Roadmap of Standards” relevant to the FSA. This Roadmap will include the standards and drafts withinSG16, ITU and also in relevant external bodies. It should reflect the standards already completed by relevantStandards Bodies and Forums, and those planned for the future. It should identify new standardization work to bedone, and assist in the formulation of new study questions leading to a new Standard/Recommendation done at anappropriate place (e.g., by a vertical question). It should also harmonize work with other relevant standard bodies.Nevertheless, horizontal questions may also have recommendations as “deliverables” if they are “common” for thevertical questions (e.g., security-related recommendations are applicable for several vertical questions). A verticalquestion, however, is strictly project-oriented with the task to deliver concrete Recommendations.

The future progression of work following this meeting will be under new Questions approved by the WTSA, ascontained in TD-13(Plen), and shown in Table 4.



New Q Old Q(s) Title RapporteurA/16 16, 17 MediaCom 2004 J. Magill (Lucent Technologies, UK)B/16 new Multimedia Architecture J. Vandenameele (Alcatel, Belgium)C/16 1,2 Multimedia applications and services F. Lucas (3Com, USA),

Associated Rapporteur: A. Blausten(USA) (to be confirmed)

D/16 new Interoperability of Multimedia Systems andServices

F. Tosco will act as contact pointuntil appointment of the Rapporteurby SG16.

E/16 new Media coding Simão F. Campos Neto (LMGT,USA)

F/16 new Quality of Service and End-to-end Performance inMultimedia Systems

M. Buckley (Lucent Technologies,UK)

G/16 new Security of Multimedia Systems and Services M. Euchner (Siemens, Germany)H/16 9 Accessibility to Multimedia Systems and Services G. Hellström (Ericsson, Sweden)1/16 3,11,12 Multimedia systems, terminals and data

conferencingP. Luthi (PictureTel, USA)

2/16 13 Multimedia over packet networks using H.323systems

P. Jones (Cisco, USA)

3/16 14 Infrastructure and interoperability for Multimediaover packet networks

G. Freundlich (AvayaCommunication, USA)

4/16 new Video and data conferencing using Internet-supportedservices

S. Okubo (TAO, Japan)

5/16 new Mobility for Multimedia Systems and Services F. Tosco will act as contact pointuntil appointment of the Rapporteurby SG16.

6/16 15 Advanced video coding G. Sullivan (Microsoft, USA),Associated Rapporteur: T. Wiegand(Heinrich Hertz-Institute, Germany)

7/16 20 Wideband coding of speech at around 16 kbit/s R. Drogo de Iacovo (CSELT, Italy)8/16 21 Encoding of speech signals at bit rates around 4

kbit/sP. Barrett (BT, UK)

9/16 24 Variable bit rate coding of speech signals Y. Naito (Mitsubishi, Japan)10/16 19, 22 Software tools for signal processing standardization

activities and maintenance of existing voice codingstandards

R. Salami (Canada) (to be confirmed)

11/16 4, 10, 23 Voiceband Modems: Specification and PerformanceEvaluation

L. Brown (Conexant, USA)

12/16 5, 8 DCE-DCE Protocols for the PSTN and ISDN W. Pechey (UK)13/16 6, 7 DTE-DCE Interfaces and Protocols R. Rainer Damm (Deutsche

Telekom, Germany) (to be confirmed)14/16 1-6/8 Facsimile terminals (Group 3 and Group 4) T. Geary (Conexant, USA)

Table 4. New Questions for Study Group 16

FUTURE MEETINGS

The next full meeting of SG16 is scheduled for May 28 - June 8, 2001 in Brazil, or June 4-15, 2001 in Geneva.

RELATIONS WITH OTHER ITU-T A CTIVITIES

TD-01(Gen) (K. Park, TSAG Vice-Chair, WP3/TSAG Chair) is a liaison from WP3/TSAG (EDH) to inform allSGs of further information and developments regarding electronic document handling (EDH). Recommendation A.3is proposed for deletion at the WTSA; following the WTSA, the information contained in A.3 will be madeavailable as a “Guide for the elaboration and presentation of texts for Recommendations of the ITU-T” on the ITUweb site. The TSB will archive documents from the 1997-2000 study period for TSAG and for all the SGs; the



TSB will provide information on how to access these documents. This contribution also includes a summary of themajor activities carried out by the TSB EDH, information on new facilities, a summary of the latest informationavailable on the ITU-T website, and information on EDH support facilities at SG meetings held in Geneva.

WP1/16, LOW RATE SYSTEMS

J. Magill (Lucent Technologies, UK) is the chair of Working Party 1/16. TD-21(1/16) is the agenda. TD-73(Plen)is the meeting report. Changes to the meeting schedule and some additions to the document allocation table weremade as shown in TD-40(1/16). TD-074(Plen) provides a list of interim meetings. TD-075(Plen) provides theliaison statements outbound from WP1. TD-076(Plen) is the updated WP1 work plan.

Questions 4/16 and 23/16 met November 8-10 2000 just prior to the SG16 meeting. TD-31(1/16) contains thereport of these meetings. The main purpose was to complete the draft of V.92 in preparation for final Approval atthis November SG16 meeting, and to consider proposed V.250 commands to support V.59, Modem managedobjects.

All of the work on facsimile matters, which was transferred from SG8 to SG16 by the WTSA, was handled for thismeeting by WP1/16. Work on former Questions 1/8, 4/8, and 5/8, referred to below as QFax1, was handled by theprevious Q5/8 Rapporteur, L. McIntyre (Xerox). Work on former Question 6/8, referred to below as QFax.2, washandled by the previous Q6/8 Rapporteur, I. Sebestyen (Siemens).

The Chair informed the meeting that as there was no Rapporteur for Q5/16, and Q6/16 had only received onecontribution, matters relating to these Questions would be considered during the WP1 plenary. The Q4/16Rapporteur, B. Adams (Motorola), was unable to attend the meeting. At the time of this meeting there was noRapporteur for Q10/16. As the work under Questions 4/16, 10/16, and 23/16 will be combined into new Question11/16, it was agreed that for this meeting the work on these three Questions would be handled by L. Brown, currentQ23/16 Rapporteur.

WP2/16, SERVICES AND HIGH RATE SYSTEMS

The Working Party 2/16 Chair is F. Tosco (CSELT, Italy). The WP2/16 report is TD-78(Plen). TD-19(2/16) isthe draft agenda and workplan. TD-29(2/16) lists the documentation for the meeting. TD-078(Plen)a1 provides a listof liaison statements both to and from WP2. TD-79(Plen) lists the Recommendations for consent and texts forapproval from this meeting. TD-40(2/16) is the report of the interim meetings of Qs12-14/16, November 8-10,2000, Geneva.

WP3/16, SIGNAL PROCESSING

S.F. Campos Neto (Comsat) is the chair of Working Party 3/16. TD-11(3/16) is the agenda and work schedule.The discussion of Q15/16 was held in parallel with the speech coding-related questions (Q19-22/16 and Q24/16).TD-28(3/16) is the WP3/16 meeting plenary report. TD-12r21(2/16) is the WP2 document list. The liaisonsproduced by WP3 are included in TD-29(3/16).

QUESTION 1/16 WP2, AUDIOVISUAL/MULTIMEDIA SERVICES

The Rapporteur for Q1/16 is Y. Robin-Champigneul (FT/CNET, France). TD-44(2/16) is the agenda. TD-45(2/16)(Y. Robin-Champigneul, Rapporteur) is the Q1/16 progress report. Since the February SG16 meeting, Q1/16 workcontinued via correspondence on the ITU-T Q1/16 reflector, mainly on F.IEMS, International emergency multimediaservices. Four documents were Determined at the last meeting, and were Decided at this meeting:

• F.700 Annex A.3, Media component text• F.700 Annex C.2, Middleware service element conversation control• F.701 (F.USER), Guideline Recommendation for identifying multimedia service requirements• F.703 (F.MCVS), Multimedia conversational services

These documents were published in COM16-R67, Part II.A.I (Determined Recommendations of the F-Series). Afirst version of the draft new Recommendation F.IEMS was drafted and distributed via email. Draft RecommendationF.USER (F.701) was distributed to ITU’s partners in the MoU (see below) to help them in providing scripts for e-business applications.

A liaison statement was issued at the February plenary meeting with information to other SGs concerned withProject M.3 and on the MoU, and with a request for participation in the project and for information on their relatedwork. Answers were received from SG7 (TD-4(Gen)) and SG13 (TD-5(Gen)), stating their interest in the project and,in the case of SG7, with information on some on-going activities.



TD-04(Gen) is the liaison from SG7 Question 20, Security Services Mechanisms and Protocols, which thanksQ1/16 for the opportunity to review the draft description of Project M.3 (GII Project: Technical Framework forElectronic Commerce). The proposed draft new in Q20/7 was modified to reflect support for electronic business.

TD-05(Gen) is the liaison from SG13 WP1. They consider E-business to be an important focus for their futurearchitectural work and wish to cooperate with Q1/16. The only relevant recommendations from SG13 on E-Businesscurrently is Y.130, Information Communication Architecture, Decided Feb. 28, 2000.

TD-09(Gen) reports that project M.3 is in charge of coordinating ITU-T’s activities in the framework of the MoU onelectronic business signed with ISO, IEC and UN/ECE. Its main tasks are therefore to seek cooperation from otherStudy Groups and to participate in the management of the MoU.

The fifth meeting of the MoU MG was held in Geneva on May 17-18. It was the first meeting since the ITU-T hadofficially joined the MoU and the second meeting where ITU-T was represented. Y. Robin-Champigneul(FT/CNET, France) participated in this meeting on behalf of ITU-T. One of the main points on the agenda was theBusiness Object Summit (BOS), November 27-28, 2000 in Geneva, hosted by the United Nations ECE (see<http://www.itu.int/ITU-T/e_business/bos.html>). The purpose of this meeting was to examine the variety ofsoftware objects being developed by various organizations in support of electronic business applications, and topropose means for harmonization and convergence, in order to derive a set of common business objects supportingthe full range of identified applications.

Reports from various groups were examined, in particular on the ebXML Consortium (electronic business XML,web-site <http://www.ebXML.org>) and on the ETSI M-Commerce project. Mobile e-commerce is an importantissue in which ITU should be involved. It was suggested that contacts between ITU and ETSI would be useful onthis matter.

It is important to distinguish standards for the telecom infrastructure supporting e-commerce, from standards for e-commerce itself. However in the former case, the specific requirements for e-commerce applications should be clearlyidentified. Therefore the MoU members already working on e-commerce were requested to provide descriptions oftheir applications from which such requirements could be derived. Draft ITU-T Recommendation F.USER (nowproposed for Decision as F.701), describing how to present scripts, i.e., scenarios of applications, was provided tothem for guidance.

The MoU is concerned with all aspects of electronic business, but will concentrate more on business to business (B-to-B) than business to consumer (B-to-C).The next MoU MG meeting will be held November 29-30, 2000.

An ITU-T Web-site was set up <http://www.itu.int/ITU-T/e_business/index.html>, accessible from the ITU-T homepage under “New initiatives.” It features information on the project and on the MoU, and links to the Web-sites ofthe other participating organizations.

Project M.3 on electronic commerce progressed at this meeting, with a preliminary list of study areas annexed to thereport and a liaison statement sent to the Study Groups concerned and also forwarded to ETSI. The study areas listedare: security, identification, server architecture, network capability, timing synchronization, interworking, andinterconnection.

Work progressed on the draft Recommendation, F.IEMS, Functional Requirements for an International EmergencyMultimedia Service to Support Critical Communications, leading to the text annexed to the WP2 report [TD-78(Plen) Annex 1 to the report of Q1/16] and sent for information to SG13. Appendix 1 to this Recommendationprovides two examples of existing IEPS/IEMS type services that are available today:

• In the United States, the Government Emergency Telecommunications Service (GETS) uses a High Probabilityof Completion (HPC) network capability for marking emergency calls. As specified in American NationalStandard T1.631-1993, the Calling Party’s Category parameter is used to mark emergency calls within the initialaddress message (IAM) for call set-up in Signalling System No 7 (SS7). This specific parameter has been setaside by ITU-T in Recommendation Q.763 for national use, and is used in the U.S. to trigger special applicationswithin the PSTN to enhance GETS call completion. Alternate carrier routing (ACR) is also employed in theGETS since there are multiple inter-exchange carriers (IXC) supporting toll services in the U.S. If one IXC isnot available, the call is redirected to another IXC until all possibilities are exhausted.

The dialing plan for GETS uses a universal access number with a non-geographic, toll free Numbering Plan Area(NPA) code that has been assigned by the North American Numbering Plan Administration (NANPA) to the U.S.



Government. After dialing the universal access number, the user is prompted for a Personal IdentificationNumber (PIN). If the PIN is authenticated, the originator is then requested to enter the desired destinationnumber.

• For the past five years, an emergency communications system has been under development in Japan to supportrecovery from major disasters such as the devastating earthquake that hit the city of Kobe in 1995. The WIDE(Widely Integrated Distributed Environment) project, a well-known research consortium on Internet technologiesin Japan, has developed an emergency system called IAA (“I am alive”). This is a scalable and robust distributeddatabase system that supports voice, touch-tone, cell phone, facsimile, www, and other user interfaces foremergency communications. IAA supports the many recovery activities in a disaster area, including registrationand retrieval of information for victims. IAA is based upon Internet technology to provide the diversity andflexibility required for supporting emergency communications under the most severe conditions. Thedevelopment of IAA has been a cooperative effort of Japanese universities, industry, and the CommunicationResearch Laboratory (CRL) of the Ministry of Posts and Telecommunications.

Discussion on future work under Question C for the new study period included a proposal to provide descriptions ofapplications, especially e-business applications, to draft Recommendations for multimedia services on IP networks,and to update Recommendation F.702, Multimedia conference services. An example of future work is provided inD.30, Extended Service of MCU (Republic of Korea) proposes the use of a MCU as a multimedia cache serverespecially for loosely coupled conferences (H.332).

QUESTION 2/16 WP2, INTERACTIVE MULTIMEDIA INFORMATION RETRIEVAL SERVICES (MIRS)

No contributions addressed to Q2/16 were received at this meeting; thus there was no Experts meeting on thisQuestion.

QUESTION 3/16 WP2, DATA PROTOCOLS FOR MULTIMEDIA CONFERENCING

In a liaison, Q10/7 thanked Q3/16 for their liaison, TD-14(2/16) on TPDU codes used in T.123. The liaisonstatement was discussed by Q10/7 during the SG7 meeting in March 2000. It has been noted that the ConnectionNegotiation Protocol (CNP) is designed for encapsulation within X.224 or for use as a stand-alone protocol over areliable network connection, and the TPDU codes “0100 0111” and “0100 0110” are used in CNP Control TPDUsand CNP Data TPDUs, respectively. Q10/7 recommended to Q3/16 that the sentence “The TPDU code points ofCNP only be used within the context of T.120 communications when CNP is directly used as a stand-alone protocolentity in transport layer.” be added to the scope of Annex B, Extended transport connection in page 34 ofRecommendation T.123.

Since only one contribution (the liaison statement) addressed to Q3/16 was received, there was no Experts meetingon this Question. A response (TD-86/WP2) to the liaison statement was prepared noting that, due to the absence ofappropriate Q3/16 experts, a liaison response statement was deferred to the first Q1/16 meeting.

QUESTION 4/16 WP1, HIGH SPEED MODEMS

The Q4/16 Rapporteur, B. Adams (Motorola) was not available to attend the meeting. WP1/16 addressed Q4/16under the chairmanship of L. Brown (Motorola, Q23/16 Rapporteur). The report of this meeting is contained in TD-58(1/16).

The Rapporteur asked if any members who had not already done so wished to indicate whether they had intellectualproperty pertaining to V.8, V.8bis, V.59, or V.moip. No additional oral IPR declarations were made.

TD-31R1(1/16) is the report of the Q4/16 and Q23/16 Rapporteurs meeting held November 8-10 in Geneva. Themain purpose of that meeting was to complete the draft of V.92 in preparation for Approval at this SG16 meeting.

Q4/16 also held a brief meeting to consider proposed V.250 commands to support V.59. D.11 (USA, F. Lucas,3Com), proposes a +TMO command to support new Recommendation V.59, for inclusion in the V.250Implementers Guide. This extended-format command causes the DCE to transmit one or more lines of informationtext in specific formats. The command provides three ways to retrieve information from the managed objects inRecommendation V.59. Q4/16 concluded that the command, as defined, meets their requirements. The Editor forV.8bis pointed out a small section numbering error in §10.1.1 of draft revised V.8bis.

COM16-R77 is Part II.B.2, draft new ITU-T Recommendations (Determined text) of the report of the June,Edinburgh meeting. It contains the following draft new ITU-T Recommendations:



• V.44 describes a data compression algorithm for use in DCEs. It achieves a better performance than V.42bis(Data compression procedures for DCE using error correction procedures) on many types of data. In addition tothe normal stream method, the algorithm has a packet method which can compress data already contained inframes in an efficient way.

• V.59 specifies a series of Modem Managed Objects (MMO) that can be used for modem diagnostics acrossstandardized interfaces.

• V.92 specifies the operation between two different modems, one a digital modem and the other an analog modem,both as defined in clause 3.

INCOMING LIAISONS

TD-04(1/16) is a liaison from Q4/8 in reply to a SG16 liaison on procedures for handling V.8 in T.38 applications.Q4/8 conducted a detailed delay analysis for V.8 operation over packet network. Q4/8 believes that V.8 should beable to work in the presence of about 600 msec of round-trip network delay without any special mechanism. Thisliaison includes a copy of GMD-29 (M. Mehta, Nortel), which describes the delay analysis for V.8 operation. It alsoincludes copies of two contributions discussed by Q4/8 (GMD-17 [R. Zhou, Nortel], GMD-18 [J. Li, Nortel]) thatdescribe the test results of V.8 handling procedure proposed in TD-272 (SG8, Geneva, February 2000) for V.8/V.34capable facsimile machines and V.8/V.34 capable data modems. Since a special mechanism to handle V.8 is notrequired for operation of V.34 over T.38, Q4/8 has decided not to specify such a mechanism for V.8 handling in Rec.T.38.

During discussion, there was a request that Q4/16 perform an analysis of V.8 to determine its latency limitations,since the result is pertinent not only to T.38 but also to the new modem-over-IP work.

TD-02(Gen) is a liaison from Q22/7 concerning migration from the obsolete X.208/X.209 versions of ASN.1 to thecurrent ASN.1 specifications in the X.680/X.690-series. This was considered with respect to the work on V.59; itwas agreed that no liaison reply was necessary.

REVISIONS TO V.8 AND V.8 BIS

TD-30(1/16) (J. Cookman, ESS Technology, Editor V.8/V.8bis) contains editorial corrections to the Determinedtexts of V.8 and V.8bis as published in COM16-R76. This was reviewed, and approved after revision for forwardingto the SG16 plenary for final approval. The final version is TD-35(Plen).

The revised Recommendations V.8 and V.8bis as contained in COM16-R76 and TD-35(Plen) were proposed forApproval.

V.59 (V.MMO), MODEM MANAGED OBJECTS

COM16-R77 contains the draft new Recommendation V.59, Managed objects for diagnostic information of publicswitched telephone network connected V-series modem DCEs.

TD-20(1/16) (K. Chu, Conexant Systems, Editor V.59) proposes modifications to the draft Recommendation V.59.The changes are both editorial and technical. This was reviewed, and approved (after revision) for forwarding to theSG16 plenary for final approval. The final version of this document is TD-31(Plen) (K. Chu, Conexant Systems,Editor V.59), which describes the agreed modifications to draft Recommendation V.59.

New Recommendation V.59, as contained in these contributions, was proposed for Approval.

V.MOIP, MODEM OVER IP

A new project has been initiated to define procedures for data transmission between terminals where, in addition tothe PSTN or ISDN, a portion of the transmission path between terminals includes an IP network, e.g., the Internet.Fax services are currently supported by T.38, which is implemented on gateways that are located between the IP andISDN/PSTN networks. This new work will support data services, e.g., V.34 and V.90 modem traffic, in a similarfashion. This work is called V.moip, modem-over-IP.

TD-14(Gen) (Rapporteurs for Q13/16 [D. Skran, Sonus Networks], Q14/16 [G. Freundlich, Lucent Technologies],and Q23/16 [L. Brown, Motorola]) contains the proposed ToR for the new project on modem-over-IP to beundertaken in WP1 and WP2 of SG16. This was considered. It was agreed that work on V.moip will be progressedunder new Q11/16 in cooperation with TIA TR-30.1, with meetings of the two committees alternating as was doneto expedite the V.90 work. It was also agreed to prepare and maintain an issues list to track the progress of thework. Based on the meeting discussions, a first draft of the issues list for V.moip was created (TD-60(1/16), L.



Brown, Motorola, Rapporteur Q23/16). Future versions will use revision control to show additions with respect tothis document.

Q4/16 authorized the Rapporteur to generate correspondence to several IETF groups and a liaison to SG13 informingthem of the new work on V.moip. The text of this is contained in TD-72(1/16).

FUTURE WORK

The future work of Q4/16 will be addressed by the new Q11/16. Plans for interim meetings of Q11/16 to work onV.moip are Jan 22-26, 2001 in California, and Apr. 30 - May 4, 2001, location to be determined.

QUESTION 5/16 WP1, ISDN TERMINAL ADAPTERS, AND INTERWORKING OF DTES ON ISDNSWITH DTES ON OTHER NETWORKS

WP1/16 addressed Q5/16 during the WP1/16 plenary meetings.

TD-57(1/16) (J. Magill, Lucent Technologies, UK, Chair WP1/16) proposes a correction to Appendix I of V.110,Support by an ISDN of data terminal equipments with V-series type interfaces. An error has been identified inV.110: additional data rates recently added to Table 2/V.110 are not provided for in Figure I.12, Parameter 3encoding. This contribution proposes that Figure I.12 be revised to rectify this, and that this amendment beconsidered for approval at the first meeting of SG16 in 2001, unless other contributions are received. WP1/16reviewed this proposal and accepted it, with the intention of approving a revision of V.110 Appendix I at the nextSG16 meeting.

QUESTION 6/16 WP1, DTE-DCE INTERCHANGE CIRCUITS

WP1/16 addressed Q6/16 during the WP1/16 plenary meetings. TD-38(1/16) (R.-R. Damm, Deutsche Telekom,Rapporteur) is the status report for Q6/16.

TD-06(Gen) is a liaison from ISO/IEC JTC 1/SC6/WG3 to SG16 on the Physical Layer, for information.SC6/WG3 appreciates SG16’s retention of the two additional octet timing circuits in their 2000 version ofRecommendation V.24. SC6/WG3 decided to retain the column in ISO/IEC 2110 that had been proposed for serialDTE-DCE interfaces where these octet timing leads are employed; they felt it worthwhile to keep this column toallow future implementations of the new SG16 circuits.

WG3 will discontinue as a standalone WG of SC6. The tentative decision is to join it with WG1. However, asexperts in the physical layer area who formerly attended WG3 meetings are unlikely to attend future WG1/WG3meetings, little expertise in this area will remain in SC6. In this liaison, SC6 lists the International Standards andTR (other than those relate to LAN) under the responsibility of WG3, to provide guidance for future maintenance, aswell as a list of relevant experts and their email addresses, as of June, 2000:

J. Frampton [email protected]. Haas [email protected]. Damm [email protected]. Yamaguchi [email protected]

The future work of Q6/16 (old) during the next Study Period will take place jointly with Q7/16 (old) under newQ13/16 (DTE-DCE interfaces and protocols). The long-standing liaison with ISO/IEC JTC1/SC6/WG3 on thephysical layer has ceased.

QUESTION 7/16 WP1, DTE-DCE INTERFACE PROTOCOLS

WP1/16 addressed Q7/16 under the chairmanship of F. Lucas (3Com, Q7/16 Rapporteur). TD-17(1/16) (F. Lucas,3Com, Q7/16 Rapporteur) contains the Q7/16 status report. TD-33(1/16) is the agenda, and TD-69(1/16) is thereport of this meeting.

The objectives of this meeting were to complete the Implementers Guide for Recommendation V.250, Serialasynchronous automatic dialing and control, and to consider changes to V.80, In-band DCE control and synchronousdata modes for asynchronous DTE.

V.250 IMPLEMENTERS GUIDE

TD-18(1/16) is draft 2 of the V.250 Implementers Guide. It contains all the agreements reached at the June 2000Rapporteurs meeting in Edinburgh.



The Rapporteur extended his thanks to TIA TR-30 for responding to Q7’s request for their assistance in completingthe V.250 Implementers Guide. He noted that the final draft of the V.250 Implementers Guide still required theaddition of informative references to Recommendations V.44, V.59, V.90, V.91, and V.92; it was agreed to addthese.

D.9 (USA, K. Chu, Conexant Systems) proposes that the +DCS command, which had been included in support ofnew Recommendation V.44, Data compression procedures, be deleted from the draft V.250 Implementers Guide.WP1/16 review of the data compression commands as described in TD-18(1/16) made it apparent that the +DCScommand is redundant: the same net effect can be achieved by using +DS=0 and +DS44=0. It was reported thatQ8/16 agreed with this proposal. Q7/16 WP1 agreed to accept this proposal.

D.11 (USA, F. Lucas, 3Com), proposes a +TMO command to support new Recommendation V.59, for inclusion inthe V.250 Implementers Guide. It was reported that Q4/16 reviewed this proposal and concluded that it satisfies theirrequirements; Q7/16 accepted this proposed text.

D.10 (USA, F. Lucas, 3Com) proposes seven +P commands in support of new Recommendation V.92:+PCW Call waiting enable+PMH Modem on hold enable+PMHT Modem on hold timer+PMHR Initiate modem on hold+PIG PCM upstream ignore+PMHF V.92 Modem on hold hook flash+PQC V.92 phase 1 and phase 2 control

The proposed text would replace the existing +P text in the draft of the V.250 Implementers Guide contained in TD-18(1/16) (see Q23/16 report also).

TD-31R1(1/16), the report of the Q23/16 and Q4/16 Rapporteur meetings in Geneva, November 8-10, 2000,contains minor changes to D.10 which were a result of discussions held at that meeting. Q7/16 agreed to accept theproposed text from D.10 with the changes contained in TD-31R1(1/16). It was agreed that the discussion of the +Pcommands under the V.250 Implementers Guide will be a joint discussion with Q23/16.

TD-51(1/16) (K. Chu, Conexant Systems) is the report of a joint Q7/Q23 ad hoc meeting which met to discuss themerits of a command to enhance the control of V.92 short start up procedures. At that meeting, it was agreed toappend the following sentence to the current description text of the +PQC command: “This command is used inconjunction with the +PSS command.” This report also contains proposed text for a new +P command (+PSS, Useshort sequences) to allow for the forced initiation of short, long, or automatic start up sequences by a calling DCE.Q7/16 considered these changes and additions, and accepted them. TD-39R1(1/16) is an earlier version of TD-51(1/16).

TD-54(1/16) (F. Lucas, 3Com, Q7/16 Rapporteur) is the third draft of the V.250 Implementers Guide; it contains allthe agreed changes. It was reviewed and approved.

TD-63(Plen) is the draft Recommendation V.250 Implementers Guide; the additions and changes contained in thisdraft were approved by WP1.

V.80, IN-BAND DCE CONTROL AND SYNCHRONOUS DATA MODES FOR ASYNCHRONOUS DTE

The V.80 protocol has been widely adopted for use with multimedia applications many of which are based on ITU-TRecommendation H.324. More specifically, it is the V.80 Synchronous Access Mode (SAM) that providesmechanisms for multimedia support. In this mode the information provided to the multimedia application by theDCE includes - among other things - indications and updates on connection data rate and on how the currentmultimedia output data stream is handled by the DCE’s encoding process. This information enables the multimediaapplication to optimize its output data rate to keep the data stream as smooth as possible.

D.58 (A. Pitkämäki, Nokia) proposes the addition of three synchronous data rates to Table 10/V.80. Five differentuser data rates have been specified by Third Generation Partnership Project (3GPP) for video telephony. Thespecified rates are 28.8 kbit/s, 32 kbit/s, 33.6 kbit/s, 56 kbit/s and 64 kbit/s. 3GPP is also considering supportingV.80 in the 3GPP Technical Recommendations. However, the current version of V.80 does not support 32 kbit/s,56kbit/s and 64 Kbit/s.

D.58 stimulated a discussion considering the possible review and revision of V.80. Concern was voiced that theremay be proprietary codes used that have not been specified in V.80. Q7/16 was asked to make known the existence



of any such code to the Rapporteurs group. This will be an issue if additional data rates and features are added to theRecommendation. Two possible approaches were considered: a revised V.80, with approval under A.8, or a newV.80 Implementers Guide, with approval of the Guide at the next SG16 meeting.

V.250 SUPPLEMENT

With the approval of the new commands in the V.250 Implementers Guide, there is a need to update the V.250Supplement. It was agreed that this should be ready for approval at the next SG16 meeting, in 2001.

FUTURE WORK

Q7/16 considered the possibility of incorporating the V.250 Implementers Guide into a formal revision of V.250.No decision was reached on this. Additional V.250 command support may become necessary if requirements comefrom the new V.moip work initiated under the future Q13/16.

Future work will take place under the new Q13/16. One interim Rapporteurs meeting was requested to progress thework on V.80, the week of April 30, 2001, co-located with new Q11/16 and Q12/16.

QUESTION 8/16 WP1, DCE-DCE PROTOCOLS

WP1 addressed Q8/16 under the chairmanship of W.L. Pechey (UK, Q8/16 Rapporteur). TD-24(1/16) (W. L.Pechey, Rapporteur) is the Q8/16 status report. TD-23(1/16) is the agenda. TD-70(1/16) is the draft report of thismeeting. TD-56(1/16) is an earlier version of this meeting report. The Rapporteur asked whether any memberspresent knew of any additional intellectual property rights relating to V.44. There was no response. (HughesElectronics Corporation has previously sent a statement to the TSB).

LIAISONS

TD-05(1/16) is a liaison from SG7 on the new Recommendation X.272 (formerly X.dcp), Data compression andprivacy over frame relay networks. It notes that the ITU-T has approved this Recommendation. Q11/7 has added tothe Recommendation the ability to include alternative data compression algorithms such as the one that is proposedby SG16. These algorithms can be incorporated into the X.272 Recommendation as new amendments.

Q8/16 examination of the Recommendation revealed that the facility is included, but there is no reference to eitherV.42bis or V.44; the only algorithms mentioned are IETF algorithms. A liaison back to SG7 Q11 was approved[TD-53(1/16)]. Q8/16 is pleased that SG7 has provided for the negotiation of various data compression algorithms,but they would have liked to see their two data compression Recommendations, V.42bis and V.44, included in thetext. Q8/16 hopes that SG7 can add them as soon as possible and, perhaps, make V.44 the default.

TD-06(1/16) is a liaison from ISO/IEC JTC1/SC06 containing the proposed final text for TR publication, ISO/IECTR 10171, List of standard data link layer protocols that utilize high-level data link control (HDLC) classes ofprocedures, list of standard XID format identifiers, list of standard mode-setting information field format identifiers,and list of standard user-defined parameter set identification values.

Q8/16 reviewed the text and was happy to see that all of their past amendments were included. It was suggested thatTable 4 might contain an error relating to standard private parameter set identification values. TD-52(1/16) (W.L.Pechey, UK) concludes that the ISO document, while not complete, is correct. It was concluded that a liaisonresponse was not necessary.

V.44 (V.DC2), DATA COMPRESSION

COM16-R77 contains the Determined text for V.44, Data compression procedures. TD-30(Plen) (W.L. Pechey, UK,Q8/16 Rapporteur, and N. King, Infineon Technologies, Editor V.44) is a revision of Recommendation V.44, as itappears in COM16-R77. This new Recommendation was proposed for Approval.

TD-12(Plen) (N. King, Infineon Technologies, Editor V.44) provides editorial changes to the Determined text of draftRecommendation V.44 (COM16-R77-E). This was considered. All the changes were agreed, with the exception ofthe change made to Annex B, B.2.1 paragraph 2, item 5, line 3, where the text was improved instead. J. Heath(Hughes Network Systems) pointed out that section B.2.2 was in need of some clarification; he agreed to draft sometext for this.

D.5 (USA, J. Heath, Hughes Network Systems) proposes two minor technical changes to the Determined version ofdraft Recommendation V.44: one to the default dictionary value for packet method, the other to the parameter



identifiers used for XID negotiation of V.44 data compression. It also proposes several editorial changes forclarification. Q8/16 WP1 considered these suggestions, and agreed to them all.

D.6 (USA, J. Heath, Hughes Network Systems) proposes the creation of a registry to track and assign datacompression parameter identifiers within the user data sub-field of the XID frame in V.42, and that parameteridentifiers x’40’ through x’5F’ be reserved for that purpose. Parameter identifiers x’40’ through x’48’ in the userdata sub-field are currently proposed for XID negotiation of Recommendation V.44 data compression. Thiscontribution proposes that parameter identifiers x’49’ through x’5F’ be reserved for additional future parameters fordata compression, either for V.44 or other algorithms.

After discussion, it was concluded that this would probably require a change to V.42 (and perhaps to V.120 and V.76as well). It was felt that this task would take more time than was available. Q8/16 decided that contributions onthis matter should be prepared for the next meeting, perhaps as a more general review of V.42. It was noted thatISO/IEC JTC1/SC06 provide registration of some parameters. The Rapporteur agreed to investigate this matter[TD-52(1/16)]; he determined that the responsibility for the parameter identifiers does lie within Q8/16 and that itwas therefore not necessary to send a liaison.

D.13 (M. Nicholas, 3Com) points out that, with the approval of new Recommendation V.44, it is necessary toinclude references to that new Recommendation in Recommendation V.42. In addition, V.44 has made use of themanufacturer-specific user data fields in the XID frame of V.42; this presents problems for some modems that alreadyutilize the user data sub-field. Since this field was defined to be manufacturer-specific, any variation from thespecific manufacturer’s ID is to be ignored. Thus, manufacturers already using the user data field cannot supportboth V.44 and manufacturer-specific features simultaneously, without some other way of knowing which type ofmodem is calling. This contribution proposes allowing that a modified ADP (answerer detection pattern) may besent in V.42 detection phase to indicate extended user data field capability. It includes proposed text, with revisionmarks relative to the current ITU-T V.42 recommendation.

In discussion, it was not agreed to modify the text of V.42, but the contributor offered to draft some text for anAppendix to V.42, to be Approved at this meeting, to explain the problem and show how it can be solved. Thistext is contained in TD-55(1/16), Additional information for V.42 Implementers regarding answerer detection patterns(W.L. Pechey, UK, Q8/16 Rapporteur). Q8/16 amended this text; the revision is in TD-48(Plen), Proposedappendix to V.42 (W.L. Pechey, UK); this was proposed for Approval.

D.9 (USA, K. Chu, Conexant Systems) proposes deletion of the +DCS command from the draft V.250Implementers Guide; this was also considered by Q7/16. Q8/16 agreed to support this document when it is presentedto Q7/16.

TD-20(1/16) (K. Chu, Conexant Systems, Editor V.59, Modem managed objects) proposes significant modificationsboth editorial and technical to the draft Recommendation V.59. Included are the changes necessary to support ASN.1based on X.680. Many of the changes apply to the support of V.44. Q8/16 agreed to these proposed changes.

TD-25(1/16) (W.L. Pechey, UK) contains the text for the summary of V.44, as agreed in Edinburgh in June. TheRapporteur pointed out that there was still time for any corrections or improvements. After some discussion aboutthe meanings and usage of the words “packet” and “frame,” and taking into account the French usage, a small changewas agreed. The complete agreed text now reads as follows:

“Recommendation V.44 describes a data compression algorithm for use in DCEs. It achieves a better performancethan V.42 bis on many types of data. In addition to the normal stream method, the algorithm has a method whichcan compress data already contained in packets in an efficient way.”

FUTURE WORK

Contributions are likely on the provision of a DCE-to-DCE channel for conveying management information relatedto V.59; now that SG16 is the lead Study Group on e-commerce, there could well be work in that area. It was alsosuggested that a “Call for Papers” be placed in some appropriate places to attract contributions, especially in the areaof new compression algorithms. A “Living Work Plan” could be created to give more detail about items beingworked on. The Rapporteur agreed to create such a document and post it on the FTP site.

It was also felt that the modem-over-IP work might result in requests for changes to Q8/16 Recommendations.

Two interim Rapporteur meetings were requested to progress the work of new Q12/16, to be held in conjunctionwith other WP1/16 Rapporteur Groups, Jan. 22-26 and April 30- May 4. Time will be allocated depending oncontributions received.



QUESTION 9/16 WP1, ACCESSIBILITY TO MULTIMEDIA FOR PEOPLE WITH DISABILITIES

WP1 addressed Q9/16 under the chairmanship of G. Hellström, (Ericsson, Q9/16 Rapporteur). TD-36(1/16) is theagenda.

The basic work with the Total Conversation concept was completed; thus, real-time text conversation has been addedto practically all multimedia protocols. Work with text functions in gateways was completed, as well as the workon harmonization of text telephony. Service definitions for text telephony and Total Conversation were alsocompleted.

This meeting represented a milestone in the Q9/16 accessibility work, in that all the main activities with texttelephone harmonization and real time text conversation inclusion as a normal part in the multimedia protocols arecomplete. Q9/16 proposed that this progress be made known by the ITU.

REVIEW OF ACTIVITIES SINCE FEBRUARY 2000

TD-22(1/16) (G. Hellström, Rapporteur) is the status report. After the February SG16 meeting, Q9/16 held oneRapporteur meeting in June (Edinburgh) with Q4/16. Revised V.18 was finalized; the white document COM16-125was produced. Additional work was carried out in Q14/16 and in collaboration with Q4/8 by correspondence to bringH.248 Annex G to white contribution status. This progress is reported in reports COM16-R75, COM16-R76, andCOM16-R77.

IETF RFC 2793, RTP Payload for Text Conversation RTP, which provided the text needed for H.323 Annex G, IPtext conversation and text SET, was approved by IETF on the last day of the February SG16 meeting, and publishedin May, 2000. H.323 Annex G was then Approved in February, 2000. Q9/16 elaborated additions to V.59 formanagement of V.18 modems jointly with Q4/16.

In Q14/16, Q9/16 has worked with fax experts to create H.248 Annex F, Facsimile, text conversation, and calldiscrimination packages. Work was progressed in the Q14/16 Osaka meeting, in SG8, and in the Q9/16 Edinburghmeeting. A white document was produced in June 2000; it was for Decision in this meeting as COM16-126.

Texts for the service definitions in F.700 Annex A3, Media component text, and F.703 (F.MCVS), Multimediaconversational services, were stable at the February meeting; they were progressed by Q1/16 and brought forDecision in this meeting as COM16-R67.

WORK OF RELEVANCE TO Q9/16 IN OTHER QUESTIONS

Media Gateway Control , H.248 Annex F (Q14/16)COM16-126 is H.248 Annex F, Facsimile, text conversation, and call discrimination packages. This is handled inQ14/16. TD-07(2/16) is a liaison from Q4/8 (June, 2000 Gaithersburg) to Q14/16 and Q13/16 on facsimile-relatedwork on draft H.248 Annex F; it notes some minor fax issues and provides a commented revision. It was noted thatcomments in this liaison were already addressed. COM16-126 was proposed by Q14/16 for Decision withoutmodifications.

Mult imedia Service Descr ipt ions (Q1/16)COM16-R67 is Part II.A.I (Determined Recommendations of the F-Series). The F.700 Annex A.3 modification forthe text medium and F.703, Multimedia conversation service description including text conversation and texttelephony, were handled in Q1/16, and proposed by Q1 for Decision without modifications.

REVISION OF RECOMMENDATION V.18 OPERATION IN TEXT TELEPHONE MODE

COM16-125 contains the revised Recommendation V.18, Operational and interworking requirements for DCEsoperating in the text telephone mode. No comments were received on this; it was proposed for Decision.

SIMULTANEOUS TEXT AND VOICE FOR V.18

The frequency division method for simultaneous voice and text was proposed by the UK in the February meeting inD.396 (CSR Vol. 11.3). One delegate announced an intent to make an objective quality measurement according toRecommendations from SG12 on both the method in D.396 and V.61, A simultaneous voice plus data modem,operating at a voice plus data signalling rate of 4800 bit/s, with optional automatic switching to data-only signallingrates of up to 14 400 bit/s. The report and a demonstration are anticipated at next SG16 meeting.

A project “Caption Life,” nr 3203 DE, within the European Commission <http://europa.eu.int/> project programTelematics Applications, has tested the usability of V.61-based simultaneous voice and text, and reported good



improvement in speed and efficiency of the text telephone conversation for hearing impaired users over regular texttelephones. Contact for the project is M. Soede, Institute for Rehabilitation Research, e-mail [email protected].

TRANSMISSION PROBLEMS FOR TEXT TELEPHONES DUE TO ECHO CANCELING EQUIPMENT

Reports keep coming about transmission problems for text telephones. These problems seem to be caused by activeecho cancelers on the line disturbing the FSK modem communication used in text telephony. The problem seems tobe increasing; it is starting to appear in domestic calls within countries, not only in international calls. The earlierconclusion, that phase reversals should be used on the ANS and ANSam tones, is not sufficient, because existinguser terminals cannot be modified, and their performance is affected when echo cancelers are introduced. Q9/16approved a liaison, TD-075(Plen), to SG15 alerting the manufacturers of echo cancelers about the increasingproblems and the need to meet the requirements of Test 14 in G.168.

WORKPLAN AND FUTURE WORK

In the new study period, accessibility issues in multimedia are to be handled in Question H/16. Accessibility is alsoa topic of the activities in Question A/16: Mediacom 2004. Maintenance of text telephony and total conversation isin the scope of these Questions, as well as new work areas related to accessibility to multimedia for people withdisabilities. No contributions to this meeting were received for new work, but are anticipated.

QUESTION 10/16 WP1, MODEM TESTING

As there is currently no Rapporteur for Q10/16, WP1/16 addressed Q10/16 under the chairmanship of L. Brown(Motorola, Q23/16 Rapporteur).

TD-14(1/16) is a correspondence from the TIA concerning the status of TIA/EIA-793, North American telephonenetwork transmission model for evaluating analog client and digitally connected server modems. TIA/EIA-793 isnow published and available on the ITU-T Q10/16 ftp site for information. TIA TR-30.3 is working on aninternational version of PN-3857, International telephone network transmission model for evaluating analog clientand digitally connected server modems. Real international network statistics are being gathered to help validate thisnetwork model.

The future work of Q10/16 will be addressed by the new Q11/16. Plans for interim meetings of Q11/16 to work onV.moip are Jan 22-26, 2001 in California, and Apr. 30 - May 4, 2001, location to be determined.

QUESTION 11/16 WP2, CIRCUIT SWITCHED NETWORK (CSN) MULTIMEDIA SYSTEMS ANDTERMINALS

T. Geary (Conexant) is the Q11/16 Rapporteur. TD-87(2/16) is the meeting report; TD-30(2/16) is the agenda. TD-32(2/16) presents the status of the work for Q11/16 as of this meeting. The goals of this meeting were to reviewthe proposed changes to draft text for revision of H.324 Annex H, review proposed changes to the text of H.324Annex D, and review the proposed revisions to the Implementers Guides for H.320 and H.324.

TD-31(2/16) (T. Geary, Rockwell) is the report of the interim Rapporteur meetings, May 2000 in Osaka Japan (inconjunction with Q12/16-Q15/16), and August 2000 in Portland, Oregon USA (in conjunction with Q12/16-Q15/16), and the intervening work by correspondence.

TD-77(2/16) is the living list for Q11. Q11/16 reviewed it, and agreed to attach the revised version to the Q11/16meeting report, as Annex A.

TD-11(Plen) is a liaison from ITU-R WP6M in response to a liaison from SG16 on multimedia studies – potentialoverlap: WP6M agrees with SG16’s suggestions for coordinating work between the two groups. This liaisonincludes the provisional workplan of WP6M for inclusion in Mediacom 2004 as appropriate. It also includes, forinformation, the proposal for the terms of reference and workplan for a new joint working party, JWP 10-11M(currently WP6M) - Interactivity and multimedia.

H.324 ANNEX H, FOR DECISION

COM16-119-E (T. Suzuki, NTT DoCoMo) is the Recommendation H.324 draft new Annex H - Mobile multilinkoperation (white document).

D.52 (NTT DoCoMo) proposes an editorial revision to COM 16-119-E to clarify the usage of “Stuffing Frame” insection H.5.3. This revision specifies that in the event a mobile multilink layer has no information to send on achannel, such as when a channel is no longer part of the multilink session but has not yet been disconnected, a flag



shown in Figure 3, followed by 5 zero octets shall be sent as the stuffing sequence. After discussion, Q11/16 agreedto submit this text to WP2/16 and SG16 for Decision.

H.324 ANNEX I

D.39 (T. Suzuki, NTT DoCoMo) proposes support of HTTP in H.324 as an optional data application protocol.This enables usage of H.324 terminals as terminals for non-conversational services with a user interface throughweb-like menus. This contribution also proposes new H.245 codepoints required to manage the logical channel forHTTP messages. This work was reviewed in Q11/16 and the joint meetings. This document appears as TD-40(Plen) for Determination by WP2/16 and SG16.

TD-40(Plen), Draft new Annex - H.324 Annex I: Usage of HTTP in H.324 terminals (T. Suzuki, DoCoMo), wasproposed for Determination at the WP2/16 and SG16 meeting; however, since the only approval process to befollowed at this meeting was AAP, this item was withdrawn from this meeting to be submitted at the next SG16meeting.

IMPLEMENTERS GUIDES

TD-45(Plen) (P. Luthi, PictureTel, Editor) is a text revision of the H.324 Implementers Guide approved in February2000. The changes from the previous v.4 of the Implementers Guide are clarifying procedures as they appeared andwere agreed in Q11-L-09r1 (Osaka). TD-20(2/16) (P. Luthi, PictureTel, Editor) is the draft revised ImplementersGuide for the H.324 Recommendation series. It was agreed to submit this Implementers Guide for Approval byWP2/16 and SG16.

TD-56(Plen) is the revised Implementers Guide for H.320. Q11/16 provisionally accepted this contribution, pendingfinal review of additions or changes as a result of discussion of D.36 at the joint Q11/Q15 meeting (see below), andwith the exception that section 7.2.7 will be deleted as the new Annex X/H.263 makes the current AppendixII/H.263 obsolete. The final version of this document was not available for review during the closing session of theQ11/16 meeting; it was submitted to SG16 for Approval.

H.320

TD-26(Plen) (T. Geary, Conexant, Rapporteur) proposes a corrigendum to Recommendation H.243. A couple ofeditorial typos in section 5.5 and in Appendix II of the published version H.243 (05/99) were discovered by TTC (astandardization body in Japan) when translating H.243 to Japanese. Q11/16 agreed to submit this to WP2/16 andSG16 for Consent by the AAP process. WP2 also agreed to include this information in TD-56(Plen) (P. Luthi,PictureTel, Editor), the revised H.320 Implementers Guide.

TD-08(Gen) (P. Luthi, PictureTel, Editor) is v.2 of the Implementers Guide for the H.320 Recommendation series(H.221, H.230, and H.242). Q11/16 provisionally accepted this contribution pending final review of additions orchanges as a result of discussion of D.36 at the joint Q11/Q15 meeting, and noting that section 7.2.7 (Textdescribing new H.263 profiles) will be deleted. The Editor was asked to prepare a revised text, to include changes asmay be agreed in the joint Q11/Q15 meeting, for review at the Working Party meeting. This text is reflected in TD-56(Plen).

JOINT MEETINGS OF Q11-15/16

TD-27(2/16) (G. Freundlich, Avaya, Q14/16 Rapporteur) lists the changes required to produce version 7 of H.245from COM16-120: Dynamic picture resizing by four, enforcing symmetric operation in the context of slow start forH.323v4, and clarification of OBJECT IDENTIFIER Encoding. Q11/16 asked that the appropriate content of TD-27(2/16) be included in the final version of H.245v.7 for Decision.

TD-27(2/16), discusses issues relating to Dynamic picture resizing by four as additions to H.245v.7. Q11/16 agreedthat TD-27(2/16), defining functionality in H-series terminals using H.245 to signal H.263 capabilities, is alignedwith the text of TD-08(Gen) [TD-56(Plen)] defining similar capabilities in H.320 terminals. It was requested thatthis document be included as a part of the H.245v.7 submitted for Decision by Q14/16. The group also agreed toincorporate related clarification in the revised H.320 Implementers Guide, TD-56(Plen).

D.39 (T. Suzuki, NTT DoCoMo) proposes the use of HTTP in H.324. Q11/16 requested that this text be includedin H.245v.8, which was expected to be put forward for Determination by Q14/16 at this meeting, with Decision atthe next SG16 meeting. However, in the joint meeting it was agreed to include it as an Annex in H.324 and as anentry in the Appendix for H.245v.8. Q11/16 agreed to take responsibility for this work.



D.29, Value added intelligent services for all applications of Q11-14/16 WP2 (R. Roy, AT&T), was deemed to berelevant to Q13/16 only.

D.43 (M. Schäfer, Siemens AG) aims to supply “kick off” information for improving H.324 security to render itH.235-compliant. It suggests an optional extension of the “historical” H.324 security based on H.233/H.234 (whichhad been taken over from the H.320 standards) with the “modern” security architecture of H.235. This approach isdesigned to provide security compatibility between H.324 and H.323 multimedia terminals. It integrates switchedcircuit with packet-based networks even for secure multimedia services covering POTS, ISDN, GSM, UMTS, and IPtechnologies. Many of the H.235 security features will be directly applicable to the QoS-based multimedia. Thus,H.324 will profit from this “state of the art” security framework by disposing of efficient means for userauthentication (instead of “trust by wire”), integrity and confidentiality, as well. Overall, these improvements favorthe development of interoperable, i.e., network-independent, security devices.

The work item suggested by this contribution will be added to Future work for H.324. It was noted that currentwork is being done on the H.246 Annexes that may address the H.324 interworking; the work relative to securitywill be coordinated with the H.246 Annexes. The Q11/16 Rapporteur expressed pleasure at seeing this work beingstarted, noting also that it has been a long-standing work item.

TD-72(2/16) (G. Freundlich, Avaya, Q14/16 Rapporteur) provides a correction to H.245 Annex G: an inconsistencyexists between the body text and table G.4. Q11/16 approved this; it will be included in H.245v.7 and added to theH.245 Implementers Guide.

D.34, RTP Payload Types in H.245 (P. Luthi, PictureTel), was assigned to an ad hoc; the results are reported in theQ14/16 meeting report.

D.35, Proposed new H.245 messages for H.263++ Annex U and Annex W.6.3.12 (P. Luthi, PictureTel), will beadded to the text of H.245v.7.

D.36 (P. Luthi, PictureTel) proposes New H.242 messages and H.230 MBE design for H.263 Annex U (extensionsto video coding for low bit rate communication, enhanced reference picture selection mode) and Annex W.6.3.12(additional supplemental enhancement information). H.263 Annex U and Annex W.6.3.12 both use picture numbersas a means to detect lost/corrupted pictures or partial pictures. However, there are no H.242 messages defined forAnnex W.6.3.12 to report the lost/corrupted pictures or partial pictures back to the far-end encoder for error recovery.Within Annex U, a back-channel message structure is defined. However, it requires the use of a separate logicalchannel. For some applications, for example gateways and MCUs, this separate logical channel could be a bigburden. TD-36 proposes some new messages within the H.242/H.230 framework, so that H.320 terminals will beable to use existing channel to report a lost picture/partial picture or request a picture using a picture number orpicture index. This was supported in principle, but it was noted that the Q15/16 wording change to D.35 resulted inthe need to align the text for the H.230 and H.242 portions of the revised H.320 Implementers Guide. This is alsothe case for the method for determining memory requirements.

TD-60(2/16) (P. Jones, Cisco) proposes corrections to H.245v.7 to support DTMF relay via RTP as specified inH.323v.4 and H.225.0v.4. This was accepted with minor syntax changes (which might force an editorial change inH.323v.4 for alignment).

TD-08(Gen) is the Revised H.320 Implementers Guide (Status of H.263 Annex X and its effects on this document).Since H.263 Annex X (when approved) will obsolete some profiles defined normatively in H.242, the Q11/16 andQ15/16 Rapporteurs agreed to draft a communication from SG16 asking IMTC to advertise this change to theirmembers in an effort to determine the effect on current implementations [TD-15(Gen)]. This was considerednecessary because few H.320 Implementers attended this Q11/16 session.

QUESTION 12/16 WP2, B-ISDN MULTIMEDIA SYSTEMS AND TERMINALS

The Rapporteur for Q12/16 is S. Okubo (Telecommunications Advancement Organization, Japan). The meetingreport is TD-78(Plen). TD-40(2/16) is the report of the interim joint Q12/Q13/Q14/16 Rapporteurs meetings heldsince the SG16 meeting in February 2000.

H.222.0 | ISO/IEC 13818-1, MPEG-2 SYSTEMS

TD-38(2/16/) (S. Okubo, TAO, Rapporteur) provides information on a new amendment to the common text ITU-TRecommendation H.222.0 | ISO/IEC 13818-1 regarding carriage of metadata over H.222.0 | ISO/IEC 13818-1(MPEG-2 Systems) multiplex. Metadata is various information associated with the multimedia content, which



facilitates searching, navigating, and retrieving the content. Metadata standardization is being carried out in MPEG-7, TV-Anytime Forum, SMPTE and other bodies. ISO/IEC JTC1/SC29/WG11 (MPEG) intends to develop thisamendment according to the following plan:

Proposed Draft Amendment (PDAM) Jan 2001Final Proposed Draft Amendment (FPDAM) Jul 2001Final Draft Amendment (FDAM) Dec 2001Amendment (AMD) Feb 2002

TD-39(2/16) (S. Okubo, TAO, Rapporteur) proposes a corrigendum to the common text ITU-T RecommendationH.222.0 | ISO/IEC 13818-1 regarding carriage of ISO/IEC 14496 (MPEG-4) contents over H.222.0 | ISO/IEC13818-1 (MPEG-2 Systems) multiplex. In February 2000, SG16 approved Amendment 7 for this purpose, but ithas been found that a descriptor (FlexMuxTiming_descriptor) was omitted. This corrigendum proposes syntax andsemantics to resolve this situation; ISO/IEC JTC1/SC29 approved this at the end of October 2000.

Q12/16 agreed to seek SG16 approval of TD-39(2/16) by applying AAP; TD-38(2/16) was noted for information.The remaining work of this Question will be continued in Q1/16 in the next study period.

QUESTION 13/16 WP2, PACKET SWITCHED MULTIMEDIA SYSTEMS AND TERMINALS

The Q13/16 Rapporteur is D. Skran (Sonus Networks). TD-99(2/16) is the meeting report. TD-100(2/16) is theQ13/16 document status.

TD-1(Plen) through TD-10(P) and TD-29(Plen) are all A.5 references needed by H.323 and related protocols.

LIAISONS

TD-01(2/16) is a liaison from Q21/15 (TIGIN gateways) providing information and requesting guidance ondeployment and control of echo cancelers used in association with voice over IP connections. Response to this wasmade during the May meeting (CSR Vol. 11.6, TD-13); no further action was taken at this meeting.

TD-03(2/16) is a liaison from Q21/15 on packet size negotiation logic in voice over IP networks. It providesinformation from SG12 on this issue: “ The delay associated with codec processing and packetization should be keptas short as possible. To accomplish this objective when G.729 or G.729A is used, two frames per packet should beconsidered as the maximum packet size. Similarly, G.711 may be used with packet sizes of 10 ms (80 frames) or 20ms (160 frames) to achieve this objective. Finally, when G.723.1 is used, only one frame should be included in eachpacket. The 30 ms frame size of G.723.1 results in speech collection and coding delay of at least 60 ms, contributingto difficulty of interactive communications.” It was suggested that Q13/16 capture this information in some mannerin H.323; Q21/15 is incorporating it in G.799.1. The suggestion was made that Q13/16 refer to SG12’s documentto get a reference to this information. It was agreed to draft a liaison to Q23/12 to request a reference to their work.The proposed text was added to the H.323-Series Implementers Guide.

TD-67(2/16) is a copy of a liaison from Q21/15 to SG13 on location of packet size negotiation logic in Voice overIP networks. Q21/15 asks where the logic process for packet size negotiation takes place, within the mediagateway or the media gateway controller.

TD-04(2/16) is a liaison from SG9 in reply to a liaison on VoIP and MoIP activities in SG16 which suggested tothem that their work to standardize a media gateway control protocol might duplicate the effort of Q14/16. SG9’sstudies in the provisioning of real time services over cable television networks using cable modems are rapidlyprogressing. Their initial series of Recommendations is focused on the cable operators primary market: residentialand small business. SG9 notes that they will consider SG16’s recommendation to use H.323, as they expand theirwork to include the more complex business applications.

TD-06(2/16) is a liaison from Q4/8, in reply to a Q13/16 liaison proposing a switching method of opening TCPchannels when using TCP in T.38 facsimile. Q4/8 agrees with this proposal, and is amending the text and ASN.1in T.38 Annex B to reflect it. It will be incorporated in the T.38 Amendment 3 package for approval at the nextStudy Group meeting. Q4/8 intends to revise Annex B in the future to point to H.323 to improve synchronizationbetween H.323 and T.38 and obviate the need to revise Annex B whenever H.323 is revised. No response wasnecessary.

TD-12(2/16) is a liaison from SG15 on the method for deciding on codec type and packet size; it was provided forinformation (directed to SG12). It asks the question: should codec selection be related to the packet size? Q13/16



agreed to ask SG12 about this; they posed the question in their liaison to SG16 on location of packet sizenegotiation logic in VoIP networks [TD-03(2/16)/TD-09(2/16)] (see also the Q14/16 report).

TD-13(2/16) is a liaison from ETSI TIPHON on the architecture document (DTS-02003). It notes that TIPHON ischanging its architecture to be protocol-independent, and to include the concept of “planes” that “separate thetelephony application-specific parts from generic (IP) transport issues.” The application has been defined infunctional layers: service control, call control, and bearer control. Usage of H.323 will be specified in an applicationprofile.

The question was asked whether TIPHON expects any changes in the H.323 architecture. M. Buckley (Lucent UK)responded that no changes were expected; H.323 will be mapped onto the architecture, as will SIP and otherprotocols. This liaison was provided for information; no response was required.

TD-68(2/16) is a liaison from ISO/IEC to SG16 on ISO/IEC 13818 (MPEG-2 systems and video) Common text andMPEG-4 on IP. This liaison was covered during the joint Q11/Q15 meeting. It suggests that the IETF draft forpacketizing MPEG-4 has too much overhead for low bit-rate communications. ISO is requesting that the IETF notstandardize the packetization of MPEG-4, and wanted to alert Q13/16 to their request.

Annex E and Annex F of H.225.0 reference the MPEG-4 coder and need a packetization format; Q13/16 wasplanning to reference the RFC once it was published by the IETF. The IETF have told Q13/16 that they planapprove their Internet Draft, in spite of ISO’s request. See the Q14/16 report below.

H.323V.3 IMPLEMENTERS GUIDE

TD-62(2/16) (P. Jones, Cisco, Editor) is the Implementers Guide for H.323, H.225.0, H.245, H.246, H.283, H.235,H.450 Series, and H.341 Recommendations.

TD-91(2/16) (D. Skran, Sonus Networks, Q13/16 Rapporteur) contains additional amendments to TD-62(2/16).Text is needed to state that user-to-user IE from Q.931 is placed in the user-information field in the H.225.0 user-to-user IE. It appears that 7.2.2.31 tries to address this. It was agreed to modify this text for H.225.0 and the IG.

The Editor produced text to accompany H.225.0 for Decision. But for the Implementers Guide, Q13/16 will use theexplanatory text contained in TD-64(2/16) (G. Freundlich, Avaya, Q14/16 Rapporteur), which identifies new itemsfor additions to the H.248 Implementers Guide as identified by the IETF Megaco list. (Note: the section numberpointing to where the correction should be placed is incorrect; the correct section should be 6.2.17 of theImplementers Guide.)

H.323V.4/H.225.0, FOR DECISION

TD-34(2/16) (P. Jones, Cisco, Editor) contains corrections to the H.323v.4 white document. These changes werereviewed and accepted, with the changes shown below:

The second change to Section 8.2.1 was not accepted: “should use” tunneling should be changed back to “shallsupport,” possibly with some kind of special case exception for non-terminals. One option proposed is that themaster can choose the mode of operation (tunneled or non-tunneled). Another option proposed is the “preferredmode” language. If “support” is used, its meaning must be clear. The general trend of the discussion was toward“shall support” tunneling, and with the option of having the master choose the mode.

Text will be added to section 10.5 to make it clear that for backward compatibility, v.4 and later terminals shallsupport UserInputIndication. Alphanumeric must be supported, even if signal is supported. It was noted that someother changes were needed. It also needs to be made clear that T.38 is used for fax, not RTP signals; the text on thisis ambiguous.

TD-36(2/16) (P. Jones, Cisco, Editor) shows open issues in H.323v.4 and H.225.0v.4. In discussion, ten issueswere resolved.

TD-80(2/16) (P Jones, Cisco, Editor) contains additional corrections to H.323v.4. The text in section 8.1.7 shall bemodified with this sentence:

A called endpoint may choose to repeat the fastStart element in all subsequent message up to and includingConnect: the contents of the fastStart element shall be the same.

It was suggested that the reference to RFC 1738 should to be updated to RFC 2396; but it appears that RFC 2396does not completely supersede RFC 1738.



It was agreed to put H.323v.4 forward for Decision, with changes from both TD-34(2/16) and TD-80(2/16).

D.2, Third Party Re-routing of a fast connect initiated call (Cisco Systems), was withdrawn.

D.3 (R. Nadimpalli, Cisco Systems) proposes to add support for local number portability (LNP) while interworkingwith ISUP signaling interface in a H.323 network. LNP allows subscribers to keep their existing phonenumbers/addressing scheme even when they move to another local service provider and/or when they move withinthe same rate center. LNP makes use of the generic extensibility framework specified in H.225.0v.4.

It was agreed that this would be done as a generic service, and that a new set of numbers (H.451.x perhaps) would beused for generic services. This was proposed for Determination at this meeting. L. Modahala (Cisco) will be Editor.A first draft appears as TD-37(2/16), Ported number indications in H.225.0 messages (D. Skran, Sonus Networks,Q13/16 Rapporteur); it will be addressed under H.GEF (see below). This version incorporates comments receivedprior to the meeting. A previous version of this document was submitted to the November 9-10 Rapporteursmeeting, as APC-1972 . TD-37(2/16) also incorporates comments on APC-1972 .

One of the problems experienced trying to route calls to the PSTN is that a gateway may receive more setupmessages than it has port capacity. While H.323 contains a number of mechanisms to prevent such problems, thefact remains that when the H.323 network is heavily utilized, some calls fail. Typically, such failures are rare andthe solution that “works” is the user placing the call again and hoping that a port becomes available. But,obviously, such a solution is not acceptable for certain classes of service, e.g., emergency numbers (911, 112, etc.).

D.4 (P. Jones, Cisco) presents a proposal for reserving resources for calls. It proposes to allow the gatekeeper to beprovisioned with information about various service classes and ports that should be reserved for each class of service.(Note: the definition and description of such classes are not proposed and should not be standardized.) The gatekeepershould have the ability to tell the endpoint, via an RCF message, what resources to reserve for calls in variousservice classes. In addition, the gatekeeper should be able to tell an entity that sends an ARQ or LRQ what serviceclass to indicate when placing a call. This contribution proposes a number of changes to H.323 and H.225.0

In discussion, it was suggested that the names of the fields be changed to differentiate from the QoS fields in AnnexN and the material on RSVP; this was agreed.

TD-61(2/16) (D. Skran, Sonus Networks, Q13/16 Rapporteur) provides Recommendation A.5 procedures for RFC-2833, RTP Payload for DTMF digits, telephony tones, and telephony signals. This was submitted as TD-29(Plen).

TD-05(2/16) is a liaison from Q4/8 on voice/fax switching in draft H.323 Annex Dv.2. Referring to the recent workby Q13/16 to revise the voice to fax switching mechanism in H.323 Annex Dv2, Q4/8 notes their concern about theprocess of discriminating the existence of facsimile call initiation on a voice line. They have been working withQ14/16 to devise a detailed call discrimination procedure for the call initiation tones of facsimile, text telephony, andmodems; this work is detailed in H.248 Annex F, slated for Decision in November 2000. This liaison includes aproposed modification to the fourth paragraph of the new section D.6. This text was presented at a previousRapporteurs meeting; it was integrated into Annex D/H.323.

H.225.0V.4, FOR DECISION

TD-35(2/16) (D. Skran, Sonus Networks, Q13/16 Rapporteur) contains changes to the white H.255.0v.4; it wasaccepted with the eight additional changes and recommendations.

D.1, Signaling of ingress and egress carrier/circuit identifier information in H.225.0 messages and Annex Gmessages (L. Modahala, R. Baird, Cisco), discusses the following three enhancements/changes:

• To support signaling the ingress PSTN interface on the originating side and a pre-determined egress PSTNinterface (determined using the routing logic in the originating H.323 zone) between two H.3\23 entities usingthe H.225.0 Annex G messages

• To support the communication of supported PSTN circuits and circuits used for a call between the administrativedomains using annex G

• Changes to the H.323v.4 proposed GroupID type

These were incorporated into TD-34(2/16) and TD-35(2/16).

TD-83(2/16) (C. Wilmot, M. Potter, BT) provides clarification for the implementation of the nested function andenumerated parameters in H.225v.4 to address a concern that nesting might lead to undesirable recursion. Maximumconstraints should be 16 nested levels and 512 enumerated parameters. This contribution proposes the correspondingchanges to H.225v.4 Annex H. This text was approved, to be part of the H.225.0v.4.



D.47, Identification of references to IETF Documents in H.225.0v.4 (per Recommendation A.5) (T. Suzuki, NTTDoCoMo; H. Harasaki NEC), contains references to MPEG-2 and MPEG-4 RFCs.

TD-88(2/16) (D. Skran, Sonus Networks, Q13/16 Rapporteur) contains a list of the changes in revision “h225v4n”of the draft H.225.0v4 versus revision “h225v4m”. These changes incorporate comments accepted on November 13,2000, at the SG16 meeting.

Text from TD-49(2/16), Draft H.323 Annex M.2 (J. Holm, Telia) will be added to 7.6 of H.225.0. It was agreedthat LRQ/LCF stimulus signalling, in section 7.13.2, should be used only for call-related events; that text will bemodified. It was agreed to put H.225.0 forward for Decision with corrections from TD-49(2/16) as well as othercorrections.

H.323 ANNEX J (SECURE SET), FOR DECISION

There were no contributions against the H.323 Annex J white document (COM 16-116); H.323 Annex J will beDecided.

H.323 ANNEX K, HTTP BASED SERVICE CONTROL TRANSPORT CHANNEL, FOR DECISION

TD-50(2/16) (E. Skjæran, Ericsson) is the current Annex K/H.323 draft, with changes shown against the whitepaper contribution (COM 16-127). This was approved for Decision.

D.57 (M. Ishii, Y. Chimura, S. Minono, Oki Electric) proposes to add ServiceControl fields to LRJ/LCF messages,and to make the appropriate corrections and additions to this Annex and to H.225.0v.4. This was agreed, with somesmall changes. Q13/16 agreed to put this forward for Decision.

H.323 ANNEX L (STIMULUS PROTOCOL), FOR DECISION

TD-79(2/16), Revision to draft New Annex L (Stimulus control protocol) to ITU-T Recommendation H.323 (D.Walker, SS8 Networks), lists a series of changes made to COM16-141 that were suggested by the Rapporteursmeeting in November 2000. Many of the changes seem quite substantial.

Referring to Section 3.3, the question was asked whether Annex L shall support only one stream; the Editor offeredto make changes to allow that. The point was raised that H.323 and H.225.0 contain references to Annex L. It wasagreed to remove explicit references to Annex L, but to leave text to support Annex L and the idea of a stimulus-based protocol in the text. That will be left for further study. The codepoints in H.225.0 will remain as publishedin the white paper contribution. The codepoints will contain a comment stating that they are “reserved by the ITUfor further study of a stimulus based protocol.” Q13/16 felt that this document should be approved under thealternate approval procedures and it was not approved at this meeting.

H.323 ANNEX M.1 (QSIG TUNNELING), FOR DECISION

TD-52(2/16) (F. Audet, Nortel, Editor) contains the changes to the white draft of H.323 Annex M.1, Tunneling ofsignaling protocols (QSIG), from COM16-118 (June 2000). This will become a Rapporteurs TD input into theSG16 meeting. There were no issues with these changes; it was agreed to put Annex M.1 forward for Decision.

H.323 ANNEX M.2 (ISUP TUNNELING), FOR DECISION

TD-49(2/16), Draft H.323 Annex M.2, Tunneling of signaling protocol (ISUP) in H.323 (J. Holm, Telia), showschanges against COM 16-129.

It was noted that the company name “Bellcore” has been changed to “Telcordia.” The Summary reads: “Other groupssuch as ITU-T are ultimately responsible for the ISUP procedures themselves,” yet Q13/16 is the ITU; it wasproposed to delete the sentence. The Editor agreed to clarify this sentence. In the document abstract, the textindicating the version of H.245 needs to be updated to read: version 7 or higher. This document will be put forwardfor Decision.

H.450.9 (CALL COMPLETION SERVICES), FOR DECISION

TD-46(2/16) (K. Klaghofer, Siemens, Editor) contains editorial corrections to the draft new RecommendationH.450.9 (Call completion supplementary services for H.323) white document (COM16-117-E). No issues wereraised. It was agreed to put this document forward for Decision.



H.323 ANNEX M.3 (DSS1 TUNNELING), FOR DETERMINATION

TD-42(2/16), H.323 Annex M.3 – Tunneling DSS1 in H.323 (R. Callaghan, Siemens, Editor), proposes to amendthe existing H.323 Annex M with a specification, which describes:

• A new object identifier for tunneled DSS1 signaling• Usage of generic tunneling mechanism• Mapping of the DSS1 messages to/from H.225.0 messages

While the ISUP and QSIG tunneling mechanisms that have recently been added to H.323v.4 can be used between thepublic and private media gateways respectively, what has not yet been addressed is the case where DSS1 subscribersare connected to an H.323 residential gateway. In this case there is also a need for feature transparency when thesesubscribers access the PSTN via DSS1 media gateway. The generic tunneling mechanism described in draftH.323v.4, Section 10.4 can also be used to guarantee the DSS1 feature transparency over H.323 networks. Thiscontribution affirms that this proposed new specification will allow a fully standard, conforming implementation ofthe residential gateways supporting DSS1 lines.

D.40 (R. Callaghan, Siemens, Editor) proposes text to add architecture information to the tunneling proposal toshow how a DSS1 system could use H.323 tunneling. It was agreed to include this text into Annex M.3.

D.41 (R. Callaghan, Siemens, Editor) discusses some of the deficiencies of H.225.0 for a native transport of DSS1.The discussion on H.323 Annex M.3 during the Portland Rapporteur Meeting (August) suggests that a technicalreport document be provided to justify the need for tunneling DSS1 (Q.931 and Q.932). The alternate view was thatDSS1 could be transported using the Q.931 elements contained in native H.225.0 D.41 discusses two problemareas: DSS1 is designed to operate on a single signaling link whereas H.225.0 can span over several links, especiallyif a gatekeeper is involved. H.225 has a reduced message set and does not support the same information elements inthe same messages as DSS1.

In discussion, it was noted that D.41 Section 2, Bullet 5, shows a string of forbidden messages. In fact, H.225.0allows any H.225.0 message to be processed. The same argument applies to the Information Elements, which maybe processed by H.323 endpoints. But, the proponents argue, ignoring messages or message elements preventsproper DSS1->H.225.0->DSS1 signaling; therefore, a tunnel is necessary.

The issue was raised that tunneling is “optional” and what Q13/16 has currently defined is “optional.” The questionwas asked whether an optional procedure is being added due to weakness in implementations.

It was argued that the text currently does show some messages as being forbidden for transmission by some entities,e.g., gatekeepers. But, while the H.225.0 text could be cleaned up to make allowances for the needed functionality,that cannot be done in H.225.0v.4 because this is a time-to-market issue.

Q13/16 agreed to put Annex M.3 forward for Determination, with material from D.40. However, they wereinformed that the traditional approval procedure was not available, so they elected to take no action at this meeting.

H.450.10 - CALL OFFER SUPPLEMENTARY SERVICES FOR H.323, FOR DETERMINATION

TD-47(2/16) (K, Klaghofer [Editor], E. Horvath, Siemens; D. Skran, Sonus Networks, Q13/16 Rapporteur) is draftnew Recommendation H.450.10 – Call offer supplementary service for H.323. Call offer (SS-CO) is asupplementary service which, on request from the calling user (or on that user’s behalf) enables a call to be offered toa busy called user and to wait for that called user to accept this call. The procedures and the signaling protocol ofthis Recommendation are derived from the call offer supplementary service specified in ISO/IEC 14841 and ISO/IEC14843.

There were no issues with this text. It was agreed to put this document forward for Approval using the alternateapproval procedure.

H.450.11 - CALL INTRUSION SUPPLEMENTARY SERVICES FOR H.323, FOR DETERMINATION

TD-48(2/16) (K, Klaghofer [Editor], E. Horvath, Siemens; D. Skran, Sonus Networks, Q13/16 Rapporteur) is draftnew Recommendation H.450.11 – Call intrusion supplementary service for H.323. The call intrusionsupplementary service (SS-CI) enables a calling user A, encountering a busy destination user B, to establishcommunication with user B by breaking into an established call between user B and a third user C. The proceduresand the signaling protocol of this Recommendation are derived from the call intrusion supplementary servicespecified in ISO/IEC 14845 and ISO/IEC 14846.



There were no issues with this text. It was agreed to put this document forward for Approval using the alternateapproval procedure.

H.450.12 - COMMON INFORMATION ADDITIONAL NETWORK SERVICES FOR H.323, FORDETERMINATION

TD-41(2/16) (R. Callaghan, Siemens, Editor) is new Recommendation H.450.12 - Common information additionalnetwork feature for H.323 (ANF-CMN). ANF-CMN enables the exchange of common information between ANF-CMN endpoints. This common information is a collection of miscellaneous information that relates to the user orequipment at one end of a connection and includes one or more of the following: Feature Identifiers, Party Category.This Recommendation makes use of the “Generic functional protocol for the support of supplementary services inH.323” as defined in Recommendation H.450.1. The procedures and the signaling protocol of this Recommendationare derived from the common information additional network feature specified in ISO/IEC 15771 and 15772.

The Editor will clarify the text to indicate that reserved codepoints are not for general usage, and that the version ofH.245 should be H.245v.3 or higher. The references section will be changed to not include the version number; itwill reference only the year of the publication.

Q13/16 agreed to put the document forward for Determination, but were informed that Determination was notpossible; they are holding the document for the next meeting.

H.225.0 ANNEX GV.2, INTER-DOMAIN , FOR DETERMINATION

TD-51(2/16) (M. Fortinsky, VocalTec, Editor) is H.225.0 Annex Gv.2; it contains revision marks reflectingchanges relative to the Decided version 1 of H.225.0 Annex G. No concerns were raised regarding this document.

D.55 (M. Fortinsky, VocalTec) discusses H.225.0 Annex G profile negotiation. TD-41 from the August 2000Rapporteur meeting in Portland (CSR Vol. 11.8) introduced the concept of a profile to H.225.0 Annex G, andspecified such an initial Annex G profile. It did not define any way for a border element to indicate which set ofprofiles was being used, nor did it define any way for border elements to negotiate the set of profiles to be used.D.55 proposes using the H.323 generic extensibility framework to do these things. This was accepted for AnnexGv.2.

D.56 (M. Fortinsky, VocalTec) discusses clarifications related to H.225.0 Annex G service IDs. A ServiceID inH.225.0 Annex G is an identifier of a service relationship between two border elements (BE). A ServiceID isallocated by the BE that receives a ServiceRequest message and returned in the ServiceConfirmation message. Thewording of Annex G is not clear on when a new service ID should be allocated and returned; the text defining aServiceID seems to imply that a new ServiceID should be allocated and returned in response to each ServiceRequestmessage. This was clearly not the intent; the intent was for a new ServiceID to be allocated and returned whenever anew service relationship should be created. This contribution proposes some changes to the text to clarify when anew ServiceID should be created and returned by a BE. This proposal applies to the Implementers Guide of AnnexGv.1, and to Annex Gv.2.

Annex Gv.2 was accepted as TD-51(2/16) and D.55 for Determination. Q13/16 agreed to put the document forwardfor Determination, but were informed that Determination was not possible; they are holding it for the next meeting.

H.323 ANNEX R, ROBUSTNESS , FOR DETERMINATION

TD-76(2/16) (T Anderson, Lucent, Editor) is draft H.323 Annex R - Robustness methods for H.323 entities.Q13/16 raised some concerns over the syntax of the value notion used in the ASN.1; it was agreed to make theseeditorial corrections before submitting to the plenary. The Table in section 11.1 includes a footnote with an “*”, butit is not associated with anything in the Table; this will be corrected.

Q13/16 agreed to put the document forward for Determination, but were informed that Determination was notpossible; they are holding the document for the next meeting.

H.323 ANNEX O - I NTERNET OPERATIONS

TD-90(2/16) (O. Levin, RADVision, Editor) is H.323 draft Annex O. This draft shows revision changes relative toAPC-1935 from the August 2000 Rapporteurs meeting in Portland, OR. This specification defines procedures forusing Internet protocols and technologies in the context of H.323. This was the first draft of the Annex O to bepresented at SG16. It was noted that if IETF working group IPTEL draft RFP Call processing language (CPL) is towork with H.323, Q13/16 must take up that work here or work jointly with the IETF. It was suggested to have



separate annexes or appendices for IPTEL draft RFC on TRIP and IETF ENUM working group (Telephony E.164Numbering Mapping), since those are informational. Q13/16 agreed to take that up at the next Rapporteursmeeting. Annex O is expected to go for Consent in 2001 and Approval in 2002.

H.323 ANNEX P - H.323 MODEM RELAY

TD-14(Gen) provides the proposed ToRs for the modem over IP work to be undertaken in SG16 WP1 and WP2.There were no contributions at this meeting. D. Wolfstein (Surf) is the H.323 Annex P editor. It is planned to gofor Consent in 2001 and Approval in 2002.

METHODS OF THIRD PARTY CALL CONTROL

TD-84(2/16) provides IPTEL comments on TD-44 from Q13/16 in Portland (CSR Vol. 11.8). It discusses thepossible use of CPL in the context of H.323, and provides remarks on the CPL specification. It asserts that theabstraction of the CPL draft is not so abstract; Q13/16 believes it shows a tremendous amount of influence fromSIP. It suggests mapping the CPL fields to H.323 within Annex O; Q13/16 felt that more than just mapping isinvolved. For example, CPL provides switching on the address, but H.323 supports multiple addresses. The IETFasked that Q13/16 not re-write CPL to create a competing standard. The Rapporteur asked for contributions on CPLfrom interested parties for inclusion in Annex O.

H.323 ANNEX I - E RROR-PRONE CHANNELS

Work did not progress on H.323 Annex I (Packet based MM telephony over error-prone channels). B. Aronson(Toshiba) is the Rapporteur. The work is expected to go to Consent in 2001, and Approval in 2002.

There are two competing proposals (APC-1905 , UCLA and Samsung; APC-1841 , Siemens, CSR Vol. 11.8) foraddressing transport over error prone channels. Each side agreed to produce test cases and test both their solution andthe opposing solution to try to come to consensus on which direction to take. A report from each side is expected atthe next Rapporteurs meeting.

During the joint Q11/Q15 meeting, Q15/16 was asked for advice relating to their simulations using video codecsH.263 and H.26L. The question was: which of the two video codecs would be the most appropriate for the scope ofAnnex I? The Q15/16 Rapporteur said that H.263 is mature and has better error resilience, whereas H.26L has notprogressed as far in this area. He suggested that the wireless profiles defined for H.263 should be examined.

It was noted that Siemens’ approach is more efficient when using “progressive” encoding in the codec, but mostcurrent codecs are not “progressive.” The Rapporteur asked if “progressive” is the Siemens term for fine granularityscalability (FGS); Q15/16 did not understand the word “progressive.” Essentially, FGS was proposed for H.26L, butno clear case was made for the characteristics assumed by FGS. In short, FGS does not exist for H.26L.

The Q15/16 Rapporteur’s final comment was that H.263 is the clear choice for testing that requires error resilience.A strong justification for using another codec is needed.

H.GEF (GENERIC EXTENSIBILITY FRAMEWORK)

This work item resulted from the review of TD-37(2/16) (see H.323v.4/H.225.0 above), Ported number indicationsin H.225.0 messages. It was suggested that H.GEF.1 would be a general list of IDs for services and would containrules for the usage of H.GEF.x services. It was noted that other annexes might use the generic framework withouthaving an H.GEF.x number, e.g., Annex R. The H.GEF.1 editor is R. Bowen (Cisco).

TD-92(2/16) (L. Modahala, Cisco, Editor) is draft Recommendation H.GEF.3 - Number portability interworkingbetween H.323/SCN networks. It was noted that the document is incorrectly numbered: it should be H.GEF.2. Italso includes a statement to the effect that a database query can be performed with H.323 systems; this needs to beclarified, since Q13/16 is not defining such procedures.

Q13/16 agreed to send a liaison to Q25/11 regarding this work, to show what they are doing on local numberportability and to describe the generic extensibility framework.

TD-93(2/16) is a draft liaison to SG11 regarding H.GEF.2. It was suggested that the last sentences be changed toread: “The first contribution in this area has initiated a new work item to recommend a means of transporting theSCN local number portability (LNP). The use of LNP directly by H.323 systems is for further study.”



EMERGENCY SERVICES

D.48 (USA) requests development of detailed specifications for the technical and operational requirements for anInternet-based international emergency preference scheme (IEPS) as defined by ITU-T Recommendation E.106. Thisincludes a number of requirements that will be expected of VoIP systems. It was agreed that these issues must beaddressed in H.323, and that this should not be addressed in Annex N (QoS). There was some feeling within Q13/16that this work should be coordinated with an effort toward a broader scope, e.g., including SG4 and Q1/16. It wasnoted that the IETF is doing related work in this area. These facilities need to work well with those of H.248, andthe terminology should be aligned.

TD-16(2/16) (G. Kelley, Artel, Associate Rapporteur) also relates to this activity. It provides the results of a specialediting group formed to establish a requirements baseline (“Application Script”/F.700) to be used in the developmentof a service description for an international emergency multimedia service to support critical communications(F.IEMS, formerly F.EMS).

Q13/16 agreed that this issue requires further study. It was also agreed to not introduce D.4 (above) into H.323v.4.A new work item and terms of reference will be developed.

It was noted that SG4 had extended an informal invitation to SG16 to attend their meeting, where they will discussthis issue. Q13/16 agreed to draft a liaison to SG4 expressing their interest in this work. It was also noted that thiswork overlaps with Annex N/H.323.

TD-97(2/16) (R.Coldren, Lucent) is the report of the ad hoc meeting on Emergency Services. This ad hoc met todiscuss furthering the work recommended by D.48 and TD-16(2/16). It was determined that support for emergencyservices in multimedia systems is desirable and will require continued work in SG16. However, it was decided thatmore research is necessary before a specific documentation plan, e.g., H.323 Annex or otherwise, can berecommended.

The ad hoc noted that TD-13(Plen), Questions assigned to ITU-T SG16, refers to F.EMS in Question C. It is theirbelief that F.IEMS is the correct name and that this document will provide requirements for support of IEMS. Thisdocument is likely to based on TD-16(2/16), and will serve as requirements for further development in SG16.

TD-97(2/16) provides a preliminary list of currently available emergency services documentation , as well as a list ofexisting SG16 documents which are likely to be affected by support for such emergency services. H. Folts of the USNational Communications Service supports a related web site at <http://www.iepscheme.net>.

Q13/16 noted that this work appears to overlap with Q1/16. There were no other comments, but a liaison wasgenerated [TD-98(2/16)], to provide information on this work to IETF, TIPHON, and SGs 2, 4, 11 and 13. R.Coldren (Lucent) is the Emergency Services editor.

H.323 ANNEX N (QOS)

TD-66(2/16) (M. Buckley, Lucent UK, Editor) is the latest draft of Annex N of H.323 - End-to-end QoS control andsignaling in H.323 systems. This draft is based on the earlier draft presented in APC-2004 , with changes discussedin the November 9 - 10 Rapporteurs meeting. It is planned for Consent in 2001 and Approval in 2002.

The Editor outlined the concepts of Annex N, which are borrowed from the ETSI TIPHON QoS work:

• There are multiple planes, including the IP transport and application planes. There are aspects that need to becontrolled on each plane. The application plane can, for example, handle “business” issues for the purposes ofbilling, etc. The transport plane is utilized to actually provide the QoS; it is also the plane that handles all callrouting issues. The procedures used in the transport are left to the service provider.

• The concept of “budget” was introduced: going between each domain, there will be delay, so this needs to becontrolled.

• The QoS management element is defined on the application plane, which manages many aspects of the QoS, i.e.,authorization, coordination with other QoS managers, billing interfacing, etc.

• A policy element will contain the user profile.

The Editor also presented a document on QoS for Voice. TIPHON examined four classes for defining QoS for voicewith delay recommendations for each class. The classes range from better than G.711 to best effort.

Q13/16 asked where the “budget” is negotiated in TIPHON’s model: This occurs between service domains; thetransport operators will query one another.



D.28, Application layer QoS signaling architecture and protocol: H.323 application specific and generic value addedservices (R. Roy, AT&T), provides the methodology for extension of the base H.323 protocol (H.225.0 [RAS,Q.931], H.245) to support the application layer QoS. This extension of H.323 to support QoS is H.323 protocol-specific because it needs to use the H.323 signaling messages with extension.

In addition, D.28 proposes that the QoS-related value-added services can be common to all applications includingH.323. It describes the relationship between the application layer H.323 QoS and its implementation over thenetwork layer QoS. It also shows that the decomposition of the H.323 entities (e.g., terminals, GKs, GWs) tohandle QoS functions require the development of a separate sets of new protocols.

D.28 proposes the following:

• The present scope of H.323 QoS (Annex N) should be limited for extensions of the base H.323 protocol(H.225.0 [RAS, Q.931], H.245):- Phase 1 – Pre-call Setup and Phase 2 – Call Setup Phase.- No new H.323 QoS functional entity that further decomposes the functions of terminals or GKs should be

considered as a part of the base extension work.• The decomposition of the H.323 functional entities (e.g., terminals, GKs, GWs, etc.) for the purpose of handling

QoS should be taken as a global approach where the H.323 system needs to perform many other functions suchas address resolution services, redirection services, registration services, and others.- The overall decomposition of the H.323 system may require separate sets of protocols (e.g., H.248 for the

decomposed GW, GK decomposition protocol [APC-1884 , D. Skran, Sonus Networks]). So, the QoSfunctional entities like the QoS Service Manager or Resource Manager should not be a part of H.323 QoSAnnex N that deals with the present base extension.

• The common value-added services that also include some sort of QoS-related functions and others should bedeveloped as a common protocol for each service that can be used by all applications including H.323.- For example, policy server, directory server, security server, and other services protocols can be developed

that also accommodate the QoS-related value-added features.- Similarly, the QoS policy element should not be a part of the present base extension (rather, it should be a

part of the policy protocol).

Q13/16 noted that some of the interfaces are out of the scope for Annex N; they may be within the scope forQuestion F. The architecture in Annex N may be removed and put into a separate document. There may be somefundamental issues with Annex N and this may not be the right solution to the problem.

D.29, Common value added intelligent backend services (BES) protocols for all applications (R. Roy, AT&T),explains why and how WP2/16 needs to open work items, like H.245, to develop the common BES protocols todeal with intelligence for all applications in the following areas, but not limited to: policy, directory, security,billing/accounting, visitor/home location functions, and other value added services. In addition, each applicationprotocol (e.g., H.323, H.310, H.324) needs to be extended to include the intelligence of those value-added servicesamong its own existing system entities in an application-specific way because the signaling messages are specific tothat particular application protocol.

TD-08(2/16) is a liaison from SG13 on QoS in H.323 systems (Draft Annex N of H.323) as related toRecommendations Y.1541 and I.356. SG13 has begun work on a new Recommendation, tentatively titled: Y.1541– Internet protocol communication service - IP performance and availability objectives and allocations. Thisdocument will define quantitative IP QoS classes similar to those in I.356 and suitable for multiple applications.Y.1541 will also provide allocation rules that will allow each network to know what it must achieve to support theend-to-end objectives.

Q13/16 noted that Annex N/H.323 has a different approach, which they consider preferable for H.323 entities. Theend points characterization of QoS may be in terms of some high level service class definition, in which caserequests will need to be translated into network and equipment parameters by the Quality of Service Manger functionin the network. Guarantees will only be achievable by either Service Level Agreements or signalling betweenservice domains and network domains and between all domains involved in establishing and transporting each mediastream. Annex N will define the H.323 signalling required to do this. Other interfaces between policy servers andbetween domains may also need definition in order to make the objective of end-to-end guarantees achievable. Animportant requirement is that the application QoS mechanisms should be independent of transport QoS mechanisms.TD-96(2/16) is a liaison on draft Annex N of H.323 to SG13 in response to TD-08(2/16).



H.323 ANNEX H (USER, TERMINAL , AND SERVICE MOBILITY )

TD-17(2/16) (J. Sundquist, Nokia, Editor) is draft H.323 Annex H, User, service, and terminal mobility in H.323.Annex H introduces new functionalities to H.323 that enable mobility in H.323 systems (user mobility, terminalmobility, and service mobility). It defines four new functional entities for the introduction of mobility managementfunctionalities: home location function (HLF), visitor location function (VLF), authentication function (AuF), andinterworking function (IWF). It is planned for Consent in 2001 and Approval in 2002.

In addition to Annex H, two other annexes deal with mobility issues related to H.323: H.323 Annex I and H.246Annex E (MAP/H.225 interworking). TD-17(2/16) describes the scopes of these three annexes as well as theirrelationships with each other, thus illustrating the division of mobility-related issues between them.

An ad hoc meeting convened to discuss this. It became apparent that there are two competing ideas relating tomobility: the H.225 Annex G protocol, extended with some new messages, and the Q.MMP protocol (as discussedin D.27 and D.75 below) that will be defined by the Special SG on IMT-2000 (currently the work is being done inSG11). TD-89(2/16) (J. Sundquist, Nokia, Editor) presents a summary and comparison of the two alternateproposals for H.323 Annex H mobility management protocol.

Summary of the pros and cons for each alternative:

Issue H.225Annex Gprotocol

Q. MMP

Speed of specification + (?) - (?)Suitability for other networks than H.323 systems (globality) - +Avoiding redundancy of work - +Ease of incorporation to current H.323 implementations + -Ease of interworking with 3G and other systems - + (?)Interoperability with H.323 implementations already using H.225 Annex G + -Scalability to small systems + - (?)Scalability to large systems + (?) +Security provided + -

D.62 (J. Sundquist, Nokia, Editor) proposes new messages and message fields to be added to the H.225 Annex Gprotocol. The additions are due to the proposed usage of the H.225 Annex G protocol for mobility management-related information flows defined in H.323 Annex H. The added messages are the authentication related messagesAuthenticationRequest, AuthenticationConfirmation and AuthenticationRejection. D.62 also proposes a field forconveying user profile information for the DescriptorUpdateAck message.

Fundamental architecture issues need to be worked out before a decision is made on how to extend Annex G. TheEditor noted that these new messages proposed for Annex G might be useful even outside the context of mobility;there was some agreement with this. The UserProfile appears to be the only addition that might have restricted userelating to mobility.

It was proposed that the AuthenticationRequest message should not require the tunneledMessage field, which shouldbe optional. The Editor will correct this issue.

Two companies expressed their view that a common protocol is needed to support the HLF/VLF functions thatmight be used by all H.3xx series terminals. This protocol would not be explicitly related to H.323 by name.Q13/16 agreed this will take some time, as it would require coordinating the work with other study groups.

Other companies expressed their view that time-to-market is important and that a protocol within the context ofH.323 is desired. It was their contention that the general-purpose protocol being proposed is for large carriers andthey want a smaller-scale solution for the enterprise and small carriers, in addition to a solution for larger-scaleenvironments.

D.61 (J. Sundquist, Nokia, Editor) proposes changes to the current draft of H.323 Annex H. These changes include arefinement of the architecture diagram, and propositions to leave most of the reference points undefined in the firstversion of the annex and to use the new proposed H.225 Annex G messages in the information flows.

This document raised a lot of controversy. Intel and Nokia hold an opinion about the scope of the Annex H workdifferent from that held by France Telecom and AT&T.



D.27, Mobility architecture and protocol: H.323 Application specific and generic value added services (R. Roy,AT&T), proposes that the application-specific protocol that is unique to each multimedia application (e.g., H.323,H.310, H.324, or IMT-2000) for supporting mobility be developed in the respective Question of that application.Accordingly, the scope of H.323 Annex H should be limited to extend the base H.323 protocol to support mobility.

The value-added services that are common to all multimedia applications (e.g., H.323, H.310, H.324, and IMT-2000) for mobility services should be developed as a common protocol, like H.245, to prevent duplication andprovide interoperability. In this way, the common protocol standard for the value-added mobility services will savecritical resources for both service providers and equipment manufacturers throughout the world, which is, in fact, afundamental objective of the ITU standardization.

This was considered. D.27 Figure 2 shows a BES protocol used to connect between the H.323 GK and a range ofvalue added services. It was noted that Annex G/H.225.0 could be used to perform some of the BES functionsshown. That figure and most of the document sparked considerable controversy.

D.75 (France Telecom) discusses mobility management protocol in H.323 Annex H. It identifies areas of H.323Annex H where additional requirements and specifications are needed for mobility management. It asserts that AnnexH is not currently well enough defined to implement. It notes that currently SG11 and, in the near future, theSpecial SG on IMT-2000 are working on a mobility management protocol (this work in its current status isappended to D.75). The needs on mobility management between IMT-2000 and H.323 Annex H prove to be verysimilar. D.75 proposes that common work be considered to enhance this protocol, and that the Determination ofH.323 Annex H be delayed to ensure that H.323 Annex H will be applicable to all mobile environments.

The Annex H Editor noted that D.75 contains a number of good comments that he would like to incorporate into thedocument. It was also noted that security was left “for further study;” Annex G has security already defined.

There was some feeling within Q13/16 to harmonize with the IMT-2000 work, and to liase with that group asQ13/16 progresses according to their ToR. Q13/16 agreed to not expand the scope of Annex H at this meeting.

PLANS FOR INTERIM MEETINGS

An interim meeting is planned for Q13/16 and Question F, to be held in Melbourne, Australia March 5-9, 2001.

QUESTION 14/16 WP2, COMMON PROTOCOLS, MCUS AND PROTOCOLS FORINTERWORKING WITH H.300- SERIES TERMINALS

TD-104(2/16) (G. Freundlich, Avaya, Q14/16 Rapporteur) is the Q14/16 meeting report. TD-105(2/16) is asimplified Q14/16 report. TD-58(2/16) is the agenda.

TD-33(2/16) is the Q14/16 status report. It provides an update on activity in Q14/16 since the February 2000 SG16meeting. Since then, Q14/16 met jointly with Q12/16 and Q13/16 in Osaka (May) and Portland (August). Inaddition, there was a special session of SG16 in June.

LIAISONS

TD-02(2/16) is a liaison providing information on a reference in H.248 to G.165 echo cancelers in IP networks,from the Rapporteurs meeting of Q9/11 held in Arendal, Norway, in August 2000. Q9/11 has observed thatRecommendation H.248, which is a product of the work of Q13/16, includes the ability to select either a G.165- orG.168-compliant echo canceler for a VoIP call. Q9/11 points out that for voice calls over an IP network, ITU-TRecommendation G.177, Transmission planning for voiceband services over hybrid Internet/PSTN connections,supports only G.168-compliant echo cancelers. It was noted that SG11 is creating a package for detailed echocanceler control.

TD-81(2/16) is a liaison response informing SG11 that an Implementers Guide has been issued for H.248. Thecodepoints in H.248 Annex C were deprecated in the Implementers Guide, leaving only the TDM circuit packagefound in Annex E to provide echo canceler control. The TDM circuit package provides simple control to add orremove echo cancelers. Q14/16 understands that SG11 is working on a package that includes more complete echocanceler control. Q14/16 is interested in this work, and asks that SG11 report on its progress.

TD-12(2/16) is a liaison from SG15 on the method for deciding on codec type and packet size; it was provided forinformation (directed to SG12). It asks the question: should codec selection be related to the packet size? Thisliaison was noted; a response is contained in TD-71(2/16) (see also the Q13/16 report).



TD-71(2/16) is a liaison to Q23/12 asking whether the information Q23/12 sent to Q21/15 on optimum packet sizefor VoIP packets is contained in a specific ITU-T Recommendation that should be referenced in Q14/16 work onH.323 and H.248. It also notes that Q21/15 sent Q23/12 a liaison requesting guidance on logic for selecting theoptimum codec to be used in a VoIP call. Q14/16 asks that Q23/12 take into account information on codecnegotiation included in H.245 when considering this issue, and that they inform Q13/16 and Q14/16 of any furtherwork in these areas.

TD-10(2/16) is a liaison noting the beginning of work in Question ITU-R 223/8, Internet protocol applications overmobile systems, to determine the technical characteristics needed to support IP applications over mobile systems.

TD-11(2/16) is a liaison response from Q7/15 thanking Q13/16 and Q14/16 for their liaison on echo control inVoIP networks (see CSR Vol. 11.3, TD-121(2/16) from the February 2000 SG16 meeting). Q7/15 experts havelooked at and agree with the statements given in the Q13/16-Q14/16 liaison.

TD-02(Gen) is a liaison from Q22/7 to all Study Groups currently defining communication protocols, concerningthe planned deletion of obsolete ASN.1 Recommendations X.208/X.209, and encouraging the use of X.680/X.690-Series ASN.1 Recommendations. It was pointed out that all the Q14/16 work seems to be based on the laterversions (X.680, X.690).

TD-54(2/16) is a liaison from Q.BICC/11 to SGs 12, 13, and 16 asking for guidance on QoS to be supported withthe BICC protocol. This liaison informs that, as part of the development of the BICC protocol, the issue of QoSwas discussed. The BICC Capability Set 1 (BICC CS1) protocol offers the transparent support of PSTN/ISDNservices over an ATM-based backbone network and was Decided in June, 2000 (ITU-T Recommendation Q.1901).The BICC Capability Set 2 (BICC CS2) protocol now in development will offer the transparent support ofPSTN/ISDN services over either an ATM backbone network (as defined in CS1) or an IP backbone network (beingadded in CS2). Q.BICC ask SGs 12, 13, and 16 to identify their ongoing and planned work on QoS with IP, and therelationship between this work and the ETSI TIPHON work. This liaison includes two attachments:

• BICC Temporary Document, BLA-061, ETSI TS 101 329 part 2, with the definition of the four TIPHON QoSclasses

• BICC Temporary Document, BLA-062, ETSI TS 101 329 part 3, with the signaling and control of end-to-endQoS in TIPHON systems

Q14/16 agreed to send a response with Q13/16 to describe the state of QoS work in Q13/16. It was noted that theattachments to the liaison were the basis of the presentation by M. Buckley (Lucent UK) on QoS work in Q13/16.

TD-102(2/16) contains the liaison response from Q13-Q14. It notes that Q13-Q14 has nothing concrete to report atthis point. QoS support has been a contentious matter, so progress has been slow. Q13/16 has been following thework in ETSI TIPHON, and the current draft of Annex N is aligned with TIPHON’s work [as represented in theattachments to TD-54(2/16)].

TD-55(2/16) is a liaison from SG11 BICC Special Rapporteurs to SG16. It notes that the interworking between theH.225.0 Multimedia call control protocol and BICC is being specified as part of the development of BICC CS2 andis based on the interworking between H.225.0 and ISUP as defined in H.246 Annex C. SG11 BICC has reviewedthe contents of H.246 Annex C and the additional information in the H.323 Implementers Guide (based on theresults of the SG16 Osaka meeting in May 2000). Based on their analysis, BICC proposes some additionalstatements to be included in the H.323 Implementers Guide for H.246 Annex C.

This liaison was reviewed at the joint Q12-14/16 Rapporteurs meeting of November 9-10, 2000, with the followingresults:

• In checking the latest Implementers Guide to see what was previously approved, it appeared that the Q14/16Implementers Guide differed from that referenced in this proposal - the continuity test procedures appearedinconsistent.

• After checking the Implementers Guide, there appeared to be a conflict with the request from Q.BICC regardingthe backward call indicators in ACM. It was agreed to draft a liaison response to ask their guidance in resolvingthis conflict, and further, to admit that carriage of user-to-user information is not well defined, and that clarifyingtext will be added to the Implementers Guide.

• The third issue of cut-through needs further study which the liaison response indicates and requests assistancefrom Q.BICC/11 on this point.

TD-101(2/16) contains the Q14/16 response.



TD-10(Gen) is a liaison from SG9/WP1 on the harmonization of security and possible use of the IPCablecomsecurity draft Recommendation (J.Sec) as a basis for a generic network security Recommendation. It informs thatSG9 is developing a coordinated suite of IPCablecom draft Recommendations for the delivery of interactive servicesover cable television networks using cable modems and IP at layer 3. The IPCablecom draft Recommendationsspecify an architecture and a set of integrated protocol interfaces for cable telecom networks using IP. Among thesuite of IPCablecom draft Recommendations, the Security draft Recommendation defines the security architecture,protocols, algorithms, associated functional requirements, and any technological requirements that can provide forsystem security of the IPCablecom network. Recommendation J.sec specifies mechanisms for authentication, accesscontrol, message and bearer content integrity, confidentiality, and non-repudiation security services for the networkelement interfaces as appropriate.

Harmonization of security across the relevant SGs would be beneficial. The SG9 draft Security Recommendationprovides a comprehensive security solution for many different network elements. Thus, SG9 proposes it forconsideration for different network technologies; SG9 recommends that SGs 7, 11, and 16, SSG, and ETSI TIPHONWG8 consider adopting this draft new Recommendation J.sec.

TD-82(2/16) contains the Q13-Q14 response to TD-10(Gen). It informs that H.235, which SG16 approved inFebruary of 1998, describes security procedures for H-series systems such as H.323 or H.324. Q14/16 is completingwork on H.235v.2 and certain profiles. Security experts who participate in SG16 have not yet had the opportunityto review J.sec, but have promised to do so. As part of SG16’s reorganization for the next study period, a newquestion has been formed to focus on security issues. Any comments on J.sec will likely originate from this newquestion. Also, coordination among various standards definition organizations, fora, and consortia (especially withinthe ITU) should improve with the start of the ITU’s MediaCom 2004 project.

TD-11(Gen) is a liaison from SG9/WP1 on IPCablecom trunking gateway control protocol draft RecommendationJ.tgcp, and harmonization of trunking gateway control protocol requirements. Among the suite of IPCablecom draftRecommendations, the trunking gateway control protocol (TGCP) is a control protocol for use in a centralized callcontrol architecture, and assumes relatively simple endpoint devices. TGCP is designed to meet the protocolrequirements for the media gateway controller to media gateway interface. Draft new Recommendation J.tgcp hasachieved WP1/9 Consent, and the four-week last call period for comments is expected to begin in early January2001.

SG9 acknowledges that some of the draft IPCablecom Recommendations follow an approach different from thattaken in SG16, and explains that this is due to unique cable requirements resulting from a several-years developmentin the cable industry and urgent time-to-market requirements. SG9 believes that it is necessary to have these draftRecommendations approved at this juncture since it is important for ITU-T to have influence over the emergingcable standards. SG9 hopes, in the future, to work towards convergence of the SG9 and SG16 approaches (H.248and J.tgcp).

This liaison was noted. Some frustration was expressed about the fact that gateway control protocols continue toproliferate when H.248 appears suitable.

TD-70(2/16) contains the Q14/16 response to TD-11(Gen). It offers a few comments on PSTN trunking gateways,and notes SG16’s willingness to work with SG9 to elaborate a complete set of requirements for PSTN trunkinggateways on the basis of IETF RFC 2805, and to create an Annex B referring to H.248 as a response to theserequirements.

TD-103(2/16) contains an amended response. In addition to the comments included in TD-70(2/16), this liaisonacknowledges that SG16 Questions 13 and 14 are not expert in cable television networks matters, but are intelecommunications matters; Q13/16 and Q14/16 are disappointed that J.tgcp has not specified the use ofH.248/Megaco in the interface between a media gateway and media gateway controller.

TD-68(2/16) is a liaison from ISO/IEC to SG16 on ISO/IEC 13818 (MPEG-2 systems and video) Common text andMPEG-4 on IP. MPEG believes that the Internet Draft that defines payload formats for MPEG-4 elementary streamshas too much overhead for low bitrate audio, and that it also does not support system stream. MPEG would preferthat payload format not be adopted. There was a strong desire within Q14/16 to see the Internet Draft Approved (ithas completed last call); if it is not, then H.225.0 Annexes E and F must be changed.

TD-63(2/16) is a communication from Q13/16 to IETF regarding MPEG ES payload formats. It notes the MPEGrequest for a suspension of MPEG-4 audio/visual RTP payload format promotion, and that the consensus ofQuestions 12, 13, and 14 is to move forward as if an RFC number will be assigned in time. This liaison asks that



the RFC number be assigned by November 17; otherwise it might be necessary to postpone the inclusion of theMPEG-4 RTP payload format specification in H.225.0v.4.

MATERIAL FOR THE IMPLEMENTERS GUIDE

H . 2 4 5TD-72(2/16) (Q14/16 Rapporteur) provides a correction to both the body text and Table G4 of the current Annex Gto H.245. The error in Annex G identified in this contribution was introduced in H.245v.6. The proposed changeswere accepted, to be added to H.245v.7 and the Implementers Guide.

H.246 Annex ATD-73(2/16) was withdrawn.

H.246 Annex CD.3, Ported number indications in H.225.0 and RAS messages (R. Nadimpalli, Cisco Systems): See the Q13/16report.

TD-37(2/16), Ported number indications in H.225.0 messages (D. Skran, Sonus Networks, Q13/16 Rapporteur): Seethe Q13/16 report.

H . 2 4 8TD-24(2/16) (C. Groves, Ericsson, Editor) is the draft H.248 Implementers Guide. This draft of the ImplementersGuide was reviewed in the November 9 - 10, 2000 joint Q12-14 Rapporteurs meeting. Ten comments/correctionsresulted from that meeting.

TD-59(2/16), Proposed H.248 Implementers Guide (C. Groves, Ericsson, Editor), is an updated version of TD-24(2/16); it includes the changes accepted at the joint Q12/Q13/Q14 Rapporteurs’ meeting held November 9-10,2000.

TD-64(2/16) (C. Groves, Ericsson, Editor) contains proposed additions to the Implementers Guide for H.248; itidentifies new items for additions to the Guide as identified by the IETF Megaco list. The Editor will remove theEditor’s note for section A.2. No text has been proposed for a requested clarification marked as section 8.x+5 in TD-64(2/16), so the Editor will remove this description. No other comments were raised. TD-64(2/16) will become theH.248 Implementers Guide, The Editor issued TD-39(Plen), H.248 IG, for approval.

H.235V.2, FOR DECISION (JOINT WITH Q13/16)

TD-65(2/16) (M. Euchner, Siemens, Editor) is the revised ITU-T Recommendation H.235v.2 - Security andencryption for H-Series (H.323 and other H.245-based) multimedia terminals – Corrected version for Decision. Thisdocument reflects modifications approved at the November 9-10, 2000 joint Q12/Q13/Q14 Rapporteurs meeting.There were no comments. TD-023(Plen) provides the changes against COM16-122 of H.325 version 2.

TD-18(2/16) is a communication to SG16 from the ATM Forum on the normative reference to ATM securityspecification version 1.0 within H.235 version 2. It informs that ATM Forum has reworked their approach toelliptic curve cryptography for ATM security services. In particular, they eliminated the use of point compression,removed the sample curves, increased the minimum field sizes, and added references to the ISO/IEC 15946-1 and15946-2. This document was reviewed during the November 9-10, 2000 joint Q12/Q13/Q14 Rapporteurs meeting.Attendees noted that the use of point compression was removed from H.235v.2 by an earlier contribution; referencesmust be changed to reflect the new ATM Forum document designation.

H.245V.7, FOR DECISION (JOINT WITH Q11-15/16)

TD-27(2/16), Changes for H.245v.7 (M. Nilsson, BT, Editor), lists the changes required to produce version 7 ofH.245 from COM16-120; these changes were agreed at the August, Portland meeting (held after the white draft wasissued). Presentation of TD-27(2/16) raised no comments. The changes shown in this contribution will be added toH.245v.7.

D.34 (P. Luthi, PictureTel) discusses a problem with RTP payload types in H.245: H.245 is unclear about how toproperly signal the use of a dynamic RTP payload type for a standardized codec (for example, G.711 or G.722).D.34 proposes a solution.

An ad hoc group met to discuss this, and drafted change text. D. Lindbergh (PictureTel) presented the correctionsorally. It was agreed to add the proposed changes to the H.245v.7 change document.



D.35 (P. Luthi, PictureTel) proposes new H.245 messages for H.263++ Annex U and Annex W.6.3.12. H.263++Annex U and Annex W.6.3.12 both use picture numbers to detect lost/corrupted pictures or partial pictures.However, no H.245 messages are defined for Annex W.6.3.12 to report the lost/corrupted pictures or partial picturesback to the far-end encoder for error recovery. A back-channel message structure is defined in Annex U, but itrequires the use of a separate logical channel. For some applications (e.g., gateways and MCUs), this separatelogical channel could be a burden. D.35 proposes some new messages within the H.245 framework to allow H.323terminals to use an existing H.245 channel to report a lost or partial picture, or request a picture using a picturenumber or picture index.

It was noted that Q15/16 reviewed D.35 and was happy with the spirit of the proposals, but they did suggest a fewminor changes. V.7 includes support for H.263++ features, but needs the additions proposed in D.35 to completesupport. Q11/16 tries to keep text in H.320 aligned with related text in H.323. D.36 proposes similar changes toH.320/230; if these changes are in H.320, it would be desirable to also add them to H.245. The proposed changes inD.35 were accepted for H.245v.7.

TD-60(2/16) (P. Jones, Cisco) proposes corrections to H.245v.7 to support DTMF relay via RTP as specified inH.323v.4 and H.225.0v.4. The changes indicated in this proposal were accepted during the November 9-10, 2000joint Q12/Q13/Q14 Rapporteurs meeting.

In discussion, the following questions, comments, and agreements on syntax resulted:

• Should the proposed alphanumeric field use IA5String instead of GeneralString? GeneralString was proposedbecause the existing alphanumeric field in UserInputIndication is a GeneralString. The field should have beenIA5String in original H.245, but the new field could be defined as IA5String here. It was decided to leave thenew field defined as GeneralString.

• NULL OPTIONAL vs. BOOLEAN: Change to BOOLEAN and change relevant text in H.323V4? NULLOPTIONAL was chosen to avoid 3-state possibilities.

• ExtendedAlphanumeric should be a SEQUENCE.

The proposed changes, with the addition of the SEQUENCE type to extendedAlphanumeric, were accepted forH.245v.7. The necessary references to RFC- 2833, RTP Payload for DTMF Digits, Telephony Tones andTelephony Signals are in TD-29(Plen), per Recommendation A.5 procedures.

H.248 ANNEX F, FOR DECISION

TD-07(2/16) is a liaison from Q4/8 on draft H.248 Annex F, Facsimile, text conversation, and call discriminationpackages. Q4/8 lists some minor facsimile issues along with a commented revision for Q14/16. The Editor ofAnnex F included in the white draft the changes requested in this liaison. Q14/16 expressed their appreciation for theexamples provided by the Q4/8. These examples have apparently been added to COM8-114 (T.38).

H.248 ANNEX G, USER INTERFACE ELEMENTS AND ACTIONS , FOR DECISION

TD-43(2/16) (P. Blatherwick, Nortel) contains a change to draft Recommendation H.248 Annex G, as shown inCOM16-130-E, to remove text that was inadvertently left in the document. This change affects the Keypad Package;in the introductory paragraph, the final sentence should be deleted. There were no comments. T. Taylor (Nortel)expressed a desire to make an editorial change; he reissued this contribution with the editorial change as TD-025(Plen).

H.248 ANNEX H, SCTP TRANSPORT, FOR DECISION

TD-22(2/16) (A Heidermark, Ericsson, Editor) proposes two editorial changes to the proposed H.248 Annex H,Simple control transmission protocol (SCTP) package, as contained in COM16-131-E. The proposed changes wereaccepted without comment; it was agreed to submit A.5 documentation to the SG16 meeting as TD-14(Plen); it wasagreed to submit the change document for Annex H to the SG16 meeting as TD-22(2/16). TD-036(Plen) providesthe changes.

H.248 ANNEX I, ATM TRANSPORT, FOR DECISION

TD-23(2/16) (A Heidermark, Ericsson, Editor) proposes two editorial changes to H.248 Annex I, as contained inCOM16-132-E. The following comments and agreements were expressed: addition of a reference to Q.2210 wasneeded; the other proposed changes were accepted; it was agreed to submit APC-2008 to the SG16 meeting as TD-23(2/16); TD-040(Plen) is the updated change document.



H.248 ANNEX K, FOR DECISION

TD-25(2/16) (C. Groves, Ericsson, Editor) is the current draft of H.248 Annex K - Generic announcement package.It is the result of the Portland rapporteur meeting; it shows changes compared to the H.248 Annex K white paper(COM16-124). The proposed modifications were accepted.

TD-56(2/16), Direction in H.248 Annex K (G. Freundlich, Avaya, Q14/16 Rapporteur), presents an unresolved issuein H.248 Annex K that was noted at the Portland meeting. A liaison from SG11 [TD-53(2/16)] supports adding adirection indicator to H.248 Annex K, while a contribution from France Telecom (D.54, Support of a directionindication in the generic announcement package) recommends avoiding the inclusion of such an indicator andproposes three alternative methods (use H.248 as is, use external equipment{e.g., IVR}, extension to H.248) toachieve the same objective.

It was noted that the main issue is to provide optimization. Regarding the event problem described in D.54, theMGC could receive an event on one termination and send control to the appropriate termination. There is noproblem with needing to restart a signal to all other terminations when a new termination is added; the KeepActiveflag keeps the signal active. The MGC gets knowledge of the MG supporting direction indication by provisioning,or else an audit can supply information. H.248 already has text that would allow a direction indicator.

Q14/16 questioned the urgency for this. A SG11 meeting will be held in December to finalize the current CS2,which has a need for this package and the direction indication. However, the liaison came from the BICCRapporteurs meeting – it was not approved by the general SG11.

T. Taylor (Nortel) commented that there seems to be some direction in packages that would define signals to be akind of procedure call, and be less specific to media streams, which may allow more power for the protocol. SinceSG11 could create a package with direction support, there would be no benefit from multiple similar packages.

Q14/16 consensus was to move Annex K for Decision, with the addition of direction information. The editorprepared TD-68(Plen), marking changes from the white paper.

RECOMMENDATIONS SCHEDULED FOR DETERMINATION NOVEMBER 2000

No documents were Determined at this SG16 meeting. The alternative approval procedure (AAP) was appliedinstead. The documents indicated below as ready for Determination may instead be considered “stable content” at thenext SG16 meeting.

H.245V.8, READY FOR DETERMINATION

D.39 (T. Suzuki, NTT DoCoMo) proposes support of HTTP in H.324 as an optional data application protocol.This will enable the use of H.324 terminals for non-conversational services with a user interface through web-likemenus. It also proposes the new H.245 codepoints required to manage the logical channel for HTTP messages.

The relationship (or conflict) between this proposal and H.323 Annex K was discussed. Annex K considered usingH.245, but wanted a channel to the gatekeeper as well (it would not have been supported if it only used H.245). Theproposed annex should add procedures to define how the http channel will be used (e.g., get vs. post). Proceduresmight not be needed for this application.

The http channel was questioned as a part of H.324 mux, or is it something else? The channel is carried inside muxstream; a more detailed explanation of this is needed.

Should this be an annex to H.245 or to H.324? If it is annexed to H.324, there must be an addition to H.245 Table8.1 in Appendix 8. The Q14/16 preference is to annex it to H.324 to avoid confusion with H.323 Annex K.

A future change will be made to H.245 V8 Table 8.1 to track the HTTP Annex (this table is in an informativeannex). The annex proposed in D.39 will be added as an annex to H.324 (see Q11/16 report).

TD-95(2/16), Changes for H.245v.7 (M. Nilsson, BT, Editor) captures additions to v.7 to create v.8. Since v.8 wasnot to be Determined at this meeting, and considering the lack of time, presentation of this material was deferred tothe next meeting.

H.248 ANNEX L, READY FOR DETERMINATION

TD-26(2/16) (C. Groves, Ericsson, Editor) proposes a new draft H.248 Annex L - Error code and service changereason description. At the May Osaka Rapporteurs meeting, it was proposed that error codes defined in the H.248



core protocol need to be better defined as to when to use them and what the appropriate action is when an error codeis generated or received. Service change reasons were added, as it was seen that these also needed definition.

TD-26(2/16) was reviewed during the November joint Q12-Q14/16 Rapporteurs meeting. At that meeting a newerror code was added to the document. TD-57(2/16), Draft H.248 Annex L (C. Groves, Ericsson, Editor), is theupdated version of TD-26(2/16). Q14/16 consensus was that Annex L is ready for Determination.

H.248 ANNEX M, READY FOR DETERMINATION

TD-69(2/16) (T. Taylor, Nortel, Editor) provides draft text for H.248 Annex M - Advanced audio server packages. Itadds two new event/signal packages to the Megaco/H.248 protocol to control an audio resource function (ARF)which may reside on a media gateway or specialized audio server. Q14/16 asked the following questions and madecomments:

• How does this align with Megaco? It contributes nothing to Megaco.• Note references to MGCP and PacketCable specs – are these the same? Not sure – they are probably close.• What is the relationship between Annex K and Annex M? Are there rules for when to extend an existing package

or to create a new package? Annex K was originally meant to be a simple announcement package; Annex M wastargeted for much more advanced functionality.

• Does Annex M support unicode? Annex M shows the ability to turn text to speech. Annex M probably needs toexamine extended character sets.

• What is the relationship between the KeepActive flag and the make persistent parameter? The intent is tooverride the absence of the KeepActive flag in an event.

• Annex M seems to be using a signal for some purpose other than generating some media stream. Should theoriginal intent of a signal be extended?

Q14/16 agreed that the general functionality of this looks good. Some editorial cleanup appears to be needed.Clarification on the support of extended character sets is needed. There was no objection to moving Annex Mforward for Determination.

H.235V.3, NEW WORK (JOINT WITH Q13/16)

TD-74(2/16) (M. Euchner, Siemens, Editor) is draft H.235v.3 - Security and encryption for H-Series (H.323 andother H.245-based) multimedia terminals. Version 3 of H.235 features a hybrid security profile in Annex F takingadvantage of security profiles in Annex D (Baseline security profile) and in Annex E (Signature profile). Thisversion also provides support for the OFB (Output feedback, ref. ISO 10116 Security techniques - Modes ofoperation for an n-bit block cipher) mode when encrypting voice streams. TD-74(2/16) contains the changesincorporated into APC-1965© resulting from the Rapporteurs meeting, and the editorial corrections made uponH.235v.2.

TD-75(2/16) (M. Euchner, Siemens, Editor) is draft H.235v.3 Annex F - Hybrid security profile. The hybridsecurity profile is for scalable “global” IP telephony. This security profile overcomes the limitations of the simple,baseline security profile of H.235 Annex D when applying it strictly. Furthermore, this security profile overcomescertain drawbacks of H.235 Annex E such as the need for higher bandwidth and increased performance needs forprocessing when applying it strictly. For example, the hybrid security profile does not depend on the (static)administration of mutual shared secrets of the hops in different domains. Thus, users can choose their VoIP providermuch easier. It applies asymmetric cryptography with signatures and certificates only where necessary and usesotherwise simpler and more efficient symmetric techniques. TD-75(2/16) was created from TD-40 (Portland), withsome editorial improvements; it is the unchanged APC-1966r1© from the November Rapporteurs meeting.

TD-28(2/16) (M. Euchner, Siemens, Editor) is the initial draft text of H.235v.3 Annex G - Security for H.323Annex H in H.323 mobile environments. It is an updated version of interim’s MD-109. It is based on APC-1937(Portland Meeting), and on interim discussions since then. It was submitted as APC-1967© to the GenevaRapporteurs meeting.

H.248V.2, NEW WORK

D.83 (Lucent Technologies) proposes to create an SDL representation of H.248. During discussion, the followingcomments were made:

• Looks good, but add it as an informative annex. It may be difficult to keep text and SDLs aligned. Need todecide how to handle discrepancies.



• Should be normative, otherwise the material will not be used by Implementers, thus possibly impedinginteroperability among vendors. Could add a clause that states that in case of discrepancy, text takes precedenceover SDL.

• Some question about the reception this work might receive in the IETF.• Not sure how SDLs would work for text encoding. Tools that use SDL as input also take ASN.1 – not sure if

anything exists for ABNF. Regardless of encoding, procedures are the same and should be specified more exactly.

Q14/16 agreed that creation of SDLs is generally viewed as positive, so work will continue on completing the SDLdefinition. There is no need to decide at this point whether the SDL annex should be normative or informative.Delegates will review the current SDL definitions and provide comment. As the SDL definitions are rather lengthy,completion of this annex is expected to require significant effort. Lucent has indicated a willingness to make theSDL source freely available.

NEW PACKAGES

D.59, H.324 Annex C multimedia call package for H.248 (Lucent Technologies, NTT DoCoMo), proposes tosupport H.324 Annex C multimedia calls in a decomposed gateway, and describes two call scenarios; H.323 toH.324 Annex C interworking, and IP tunneling of H.324 Annex C stream, with their call flows. It also proposes todefine an H.324 Annex C multimedia call package and an H.245 package for H.248 to support these multimedia callscenarios. The H.324 Annex C multimedia call package and the H.245 package are organized following the structureof Section 12, Package definition, of H.248. The terminology used in describing the functions of the media gateway(MG) and media gateway controller (MGC) is based on material from H.323v.4 Section 6.3.1, GatewayDecomposition.

D.59 was reviewed during the November joint Q12/Q13/Q14 Rapporteurs meeting. The following contains thecomments and disposition:

• How would the H.245 package work when H.323 fast start or H.245 tunneling are used? Might not be able touse this package with fast start. Timing may not be a concern.

• Is source port needed?• Since H.245 is in MG, can’t support functions like video transcoding. Assuming transcoding resources exist in

MG.• How could the system work if tunneling were not used? Tunneling is proposed as the way to support end-to-end

H.324.• The scope of the work may be more than just defining packages – some system architecture is needed, as well as

details on how H.248 is used. Need to include scenarios for H.324-H.323, H.324-H.324. Need to explaingeneral procedures.

• May need to consider an annex to H.246.• Need to explain how circuit-side signaling gets to the MGC. How does the MGC know the call is voice vs.

multimedia? How is destination addressed? Is two-stage dialing needed?• Pointers to relevant 3GPP material would be helpful.• An H.245 package may have application outside of H.324.• Need to consider other address types for source and remote addresses (e.g., IPv4, IPv6, ATM).

Q14/16 agreed that this is a good start at addressing H.324-H.323 calling in a decomposed gateway. There appears tobe a need for work beyond defining the packages:

• Consider the need for a new annex for H.246.• This annex to H.248 needs to describe the use of packages and application in H.248, including a description of

how MGC receives call signaling.• Some additional support is required in the packages (e.g., supporting address types other than IPv4).

The authors were requested to continue the work on this topic.

D.53 (France Telecom) proposes a package for data transmission over analog lines. A number of services: CallingLine Identification Presentation (CLIP), Calling Name Identity Presentation (CNIP), Message Waiting Indication(MWI), Calling Line Identification Presentation during Call Waiting, and Advice of Charge (AOC) require specialtransmission techniques on the UNI when delivered to analog terminals. Within a Voice of IP network servinganalog lines, there is a need for similar capabilities. D.53 proposes two package definitions to support suchcapabilities in an MG. The following comments and questions resulted:



• Is there any coordination with the authors of the IETF Internet Draft that has similar material?• Is there a need to get information for the inward direction, e.g., an event or property? This functionality probably

belongs in a different package.• The name may be somewhat misleading.

Q14/16 agreed that this is a good first start at a generic approach for providing these services.

H.324 RELATIONSHIP TO H.235, H.246, NEW WORK

D.43 (M. Schäfer, Siemens) discusses security interoperation - providing H.235-based security for H.324. Thiscontribution was also presented in Q11/16 (See the Q11/16 report, above). Q14/16 agreed that this appears to be agood basis for future work.

FUNCTIONAL REQUIREMENTS FOR PRIORITY SERVICES

D.48, Functional requirements for priority services to support critical communications (USA), was presented in ajoint session of Questions 12, 13, and 14 (See the Q13/16 report, above). TD-16(2/16) (G. Kelley, Artel, AssociateRapporteur) provides for requirements in progress. A web site has been set up to provide information. Work on thisis being done in Q1/16.

An ad hoc group met to discuss a plan for progressing this work, and to consider its relationship to the proposal inQ13/16 to add resource reservation (D.4, P. Jones, Cisco). The ad hoc concluded that current work in IETF shouldbe investigated. Work will be needed in Q14/16 in addition to the work in Q1/16. It was noted that a recentframework document in the IETF appears to be useful. The ad hoc concluded that the proposal in D.4 should bewithheld for the time being.

R. Coldren (Lucent) agreed to draft terms of reference in coordination with Q1/16. SG4 is also working to definerequirements, and has asked for a SG16 representative. This work and D.4 intersect with Annex N. A report of thead hoc group appears in TD-97(2/16), Emergency services ad hoc meeting report.

PLANS FOR INTERIM MEETINGS

Two interim meetings are planned for Questions 3, D, and G. The first is tentatively scheduled for March 2001, inMelbourne, Australia. A second interim meeting is planned for May or June 2001, immediately preceding the SG16meeting.

QUESTION 15/16 WP3, ADVANCED VIDEO CODING

The Q15/16 Rapporteur is G. Sullivan (Microsoft). TD-36(3/16) contains the meeting report and agenda. The workof Q15/16 progressed well at the two interim Rapporteur meetings (Osaka, Japan, May 16-18, 2000 [TD-17(3/16)]and Portland, Oregon, August 22-24, 2000 [TD-18(3/16)]).

LIAISONS

TD-04(3/16) is a liaison from ISO/IEC JTC 1/SC 29/WG11 in response to a previous liaison from SG16 regardingvideo coding activities and IDCT specification. WG11 has concluded that their efforts at developing a more stringentIDCT specification are motivated by significantly different requirements than those under way in the ITU-T. WithinMPEG, this effort is being conducted as work toward high quality tools (tentatively called “Studio Profile”) forVersion 3 of the MPEG-4 Visual coding specification (ISO/IEC 14496-2) to be capable of achieving lossless ornear-lossless coding fidelity. As a result, WG11 is working on specification of an IDCT requirement with higherinverse-transformation fidelity. This contrasts with the requirements of the work currently under way withinH.263++ in the ITU-T, which is motivated to eliminate encoder-decoder drift rather than to improve high bit-ratecoding fidelity. Due to the differing requirements of these two projects, specification of the same IDCT requirementsfor both standards may not be appropriate.

TD-05(3/16) is a liaison from ISO/IEC WG11 in reply to a liaison from SG16 on the ITU-T H.26L project and thepotential future video coding efforts in MPEG. In regard to the future work planned by MPEG, WG11 has decided toconduct an evaluation of new technologies to enhance video coding performance to determine the need for theadoption of such new technology by MPEG. WG11 invites ITU-T to participate in this technology evaluation byproviding a demonstration of the performance of the draft H.26L design as a reference point for this technologyevaluation effort. This liaison was noted in the Q15/16 consideration of the inclusion of ITU-T video codingtechnology in the testing to be performed by ISO/IEC WG11.



TD-06(3/16) is a liaison from ISO/IEC WG11 on ISO/IEC 13818 (MPEG-2 Systems and video) common text, andMPEG-4 on IP; it informs of the following:

With regard to H.262 | ISO/IEC 13818-2 (MPEG-2 Video) common text coordination, the work on finalization oftext for H.262 | ISO/IEC 13818-2:2000 FDAM1 and Corrigendum (Cor)1 has been completed. WG11 has approvedthe balloted text of H.262 | ISO/IEC 13818-2:2000 DCOR1, and has therefore promoted this text to COR status(N3668) without alteration. They have made a few modifications to the balloted text of H.262 | ISO/IEC 13818-2:2000 FPDAM1 in response to national body ballot responses, and have promoted this amendment to FDAMstatus (N3666). WG11 therefore recommends approval of these final approved WG11 documents by SG16 at itsNovember meeting for achievement of common text approval.

There is also a Corrigendum (COR1 to the 2000 edition) to the MPEG-2 Systems standard H.222.0 | ISO/IEC13818-1 that completes its ballot phase prior to the November SG16 meeting, and should therefore be ready for ITU-T final approval as well.

With regard to MPEG-4 on IP, WG11 has recognized that existing IETF drafts for the carriage of MPEG-4 contentover IP networks are not capable of satisfying all application areas. WG11 has made considerable progress towardsthe development of a generic solution that includes framework and payload formats and that is capable of satisfyingall MPEG-4 application domains.

WG11 has requested that IETF suspend promotion to standards track RFC of all IETF drafts related to the carriage ofMPEG-4 content over IP networks. In doing so, it is now unlikely that IETF can provide ITU-T with a standardstrack RFC number. Because of the importance of a timely standard way to carry MPEG-4 content, WG11 requestsITU-T to either delay the Decision for the affected H.323 suite Recommendations or allow an interim revisionwithout incurring a long delay such as two years.

MAINTENANCE AND COORDINATION ISSUES FOR H.263

D.49 (G. Sullivan, Microsoft) notes the presence of four minor problems in the white document draft (COM16-140)containing the H.263 Annexes U (enhanced reference picture selection), V (data partitioned slice), and W (optionaladditional supplemental enhancement information), and asks that these problems be corrected:

• Confusion of GOB and Video Picture Segment in Annex U• Confusion of SPHI and SPWI in Annex U• Confusion between Decrementing and Incrementing of Indices in Annex U• Conditions for Presence of PNI parameter in Annex U

Q15/16 review of the draft text of Annex X to Rec. H.263v3 (H.263++) for Determination (Q15-K-51r3, fromPortland), included consideration of the changes proposed by PictureTel.

D.37 (Q. Gu, PictureTel) proposes a new profile for H.263++ Annex X, which defines a series of profiles and levelsto simplify cap exchange, and to promote inter-operability. Under SDP, these profiles and levels may become theonly options available for cap exchange and/or announcement. In view of this, the profiles and levels should have agradual change in complexity and should include most of the useful tools available. Currently, profile 3, and 4 areintended for wireless applications; they belong to a league of their own. The change in complexity from profile 1and profile 2 to profile 5 (or profile 6) represents too big of a jump. This may prevent the common, wide spread useof Annex U. Additionally, the coding efficiency improvement of combining Annexes J and F may not justify theincrease in complexity. Further, the coding gain by Annex I may not be sufficient to prevent the skip frame understressful motion conditions. Finally, Annex P Reference Resampling by a factor of 4 is not included in any of thelow latency profiles; essentially this excludes the use of this very powerful annex under SIP. D.37 asserts, as it wasagreed in Portland, that Annex P RPR4 should be included in high latency profile based on its technical merit; thelow latency profiles need this annex more than the high latency profile.

Coordinating with Q12/Q13/Q14 regarding the system support and capability exchange requirements forRecommendation H.263, Q15/16 considered the following contributions:

D.35 (P. Luthi, PictureTel) proposes new H.245 messages for H.263++ Annex U and Annex W.6.3.12 (see Q14/16H.245v7 report).

D.36 (P. Luthi, PictureTel) proposes new H.242 messages and H.230 MBE design for H.263 Annex U and AnnexW.6.3.12 (see Q11/16 Q11-Q15 joint report).

There was also progress on the work of adopting a test model encoding description as Appendix II.



H.262 | ISO/IEC 13818-2, IN COORDINATION WITH ISO/IEC JTC1/SC29/WG11

Q15/16 reviewed COM16-136, draft text of Amendment 1 (content description data) to the second (2000) edition ofRecommendation H.262 | ISO/IEC 13818-2, (G. Sullivan, Rapporteur), for Decision. This amendment provides anability to send supplemental “content description data” within H.262 video elementary streams. The contentdescription data that can be carried includes picture capture timing information, additional pan-scan parameters, anindication of the visual active region within the video picture, and a coded representation of the picture size in bytes.Review included consideration of the modifications made by ISO/IEC JTC1/SC29/WG11, as conveyed in TD-06(3/16).

Q15/16 reviewed COM16-135, draft text of Corrigendum 1 (reserved extension syntax correction) to the second(2000) edition of common text Recommendation H.262 | ISO/IEC 13818-2 (G. Sullivan, Rapporteur), for Approval.This technical corrigendum corrects the description of the handling of reserved extension data within an H.262elementary video bitstream. To enable the future adoption of backward-compatible extensions to the H.262 syntax,the proper decoder response to the presence of reserved extension data must be clearly specified. This technicalcorrigendum corrects an oversight in the description of the decoder response to such data. Review includedconsideration of the remarks made by ISO/IEC JTC1/SC29/WG11 as conveyed in TD-06(3/16).

OTHER HIGHLIGHTS

The H.26L project has matured to become closer to a fully-formed video coding standard; it is necessary to ensurethat the aspects of the design other than the compression method are properly addressed. D.50 (G. Sullivan,Microsoft) contains a number of proposals toward specification of header data for H.26L in a manner capable ofsupporting the maximum range of appropriate applications. In particular it address the specification of the samplingstructure of the video data in terms of the size and shape of the decoded video, the size and shape of the displayed partof the video, the sampling format in space, time, color space, and bits per sample. It proposes these indications asappropriate for inclusion in the sequence level and picture level header data.

Q15/16 planned three interim meetings:

• Germany: January 8-12, 2001• April 2001• July 2001

QUESTIONS 16/16 AND 17/16, MULTIMEDIA HARMONIZATION AND COORDINATION

Questions 16/16 and 17/16 are not associated with a specific Working Party and meet jointly under the Rapporteur,M. Matsumoto (NTT/Waseda, Japan). The report of this meeting is in TD-47(Plen). The meeting agenda iscontained in TD-12(Gen). No recommendations were to be Approved at this meeting.

The Chair noted that the Q16&17/16 Harmonization and Coordination meeting has, in the past four years, completedits work; it will be newly reborn, and continue for the next four years, as Mediacom 2004 (and beyond) Project. TheChair thanked all the participants for their collaboration.

PROJECT M.3

TD-09(Gen) (Y. Robin-Champigneul, FT/CNET, France) is the progress report for Project M.3. Project M.3coordinates ITU-T activities within the framework of the MoU on electronic business signed with ISO, IEC, andUN/ECE; its main task is to seek cooperation from other SGs and participate in the management of the MoU.Project M.3 work may also be undertaken within SG16 if it relates to SG16’s domain of expertise.

At the February plenary, an informative liaison on Project M.3 and the MoU was issued to other SGs, requestingtheir participation in the Project as well as information on their related work. Responses were received from SG7[TD-04(Gen)] and SG13 [TD-05(Gen)] asserting their interest in the Project. TD-04(Gen) includes information onSG7’s proposed draft new Question 20/7 – Security services, mechanisms and protocols, which has been modified toreflect support for electronic business.

MoU Management Group

The fifth meeting of the MoU MG was held in Geneva May 17 - 18. This was the first meeting since ITU-T hadofficially joined the MoU, and the second meeting where ITU-T was represented.

One of the main points on the agenda was the Business Object Summit (BOS) planned for November 27-28, 2000,in Geneva, to be hosted by the United Nations Economic Commission for Europe (<http://www.itu.int/ITU-



T/e_business/bos.html>. The purpose of this meeting is to examine the variety of software objects being developedby various organizations in support of electronic business applications, and to propose means for harmonization andconvergence to derive a set of common business objects supporting the full range of identified applications.

MoU MG examined reports from various groups, in particular on the ebXML Consortium (electronic business XML<www.ebXML.org>) and on the ETSI M-Commerce project. Mobile e-commerce is an important issue in whichITU should be involved. It was suggested that contacts between ITU and ETSI would be useful on this matter.

It is important to distinguish standards for the telecom infrastructure supporting e-commerce, from standards for e-commerce itself. And, in the former case, the specific requirements for e-commerce applications need to be clearlyidentified. Considering this, MoU members already working on e-commerce were asked to provide descriptions oftheir applications from which such specific requirements could be derived. Draft ITU-T Recommendation F.USER(now proposed for decision as F.701), was provided for guidance. It describes how to present scripts, i.e., scenariosof applications.

The MoU is concerned with all aspects of electronic business, but will concentrate more on business to business (B-to-B) than business to consumer (B-to-C). The next MoU MG meeting is scheduled for November 29-30, 2000.

An ITU-T website was set up <http://www.itu.int/ITU-T/e_business/index.html>, accessible from the ITU-T homepage under “New initiatives.” It features information on the Project and on the MoU, and includes links to the websites of the other participating organizations.

MEDIACOM 2004

TD-11(Plen) is a liaison from ITU-R WP6M (Interactivity and Multimedia - formerly TG 11/5 and JTG 10-11) toSG16 on multimedia studies – potential overlap. WP6M accepts the SG16 invitation to join the steering committeeof Mediacom 2004; C. Weinzweig, Co-Chair, will represent WP6M. TD-11(Plen) proposes a WP6M workplan forinclusion in Mediacom 2004. It also includes, for information, the calling notice for Joint Task Group 1-6-8-9:Annex 1 to Administrative Circular CACE/186 of August 7, 2000 <http://www.itu.int/itudoc/itu-r/ac/cace/186s.html>. This JTG has been established by ITU-R and concerns technical and regulatory requirementsof terrestrial wireless interactive multimedia applications.

Q16&17/16 discussed the WP6M workplan; it shows considerable overlap of multimedia application work. It wasagreed that the coordination work between SG16 and WP6M must be urgently developed.

TD-07(Gen), a liaison from ITU-R Joint Task Group 1-6-8-9, is a note to the TSB Director. The ITU-R Sector isseeking views to assist with their work on terrestrial wireless interactive multimedia systems. Their work isprimarily concerned with spectrum issues and possible regulatory impact; they are therefore not seeking an inputfrom the ITU-T Sector at this stage, but would appreciate the TSB bringing their activity to the attention of theappropriate ITU-T SGs. This liaison also introduced the ITU-R JWG activity related to Mediacom.

TD-10(Gen) is a liaison from ITU-T WP1/9 on harmonization of security, and the possible use of the IPCablecomsecurity draft Recommendation J.sec. See also the Q14/16 report. SG9 holds that harmonization of security acrossthe relevant SGs would be beneficial. Thus, SG9 proposes it for consideration for different network technologies.SG9 recommends that SGs 7, 11, and 16, SSG, and ETSI TIPHON WG8 consider adopting draft newRecommendation J.sec.

In discussion, it was agreed that the IPCablecom work also includes many overlap issues with the Mediacom project.It was agreed to send a liaison to show the harmonization work related to multimedia work.

TD-13(Gen) is a liaison from ISO/IEC JTC1/SC29/WG11 on Mediacom 2004. SC29/WG11 has reached proposeddraft technical report (PDTR) stage for MPEG-21 (ISO/IEC PDTR 18034-1). It sets out a vision for the future of anenvironment that is capable of supporting the delivery and use of all content types by different categories of users inmultiple application domains. SC29/WG11 seeks to establish a collaboration with appropriate organizations, likeQ16&17/16, to share a view of the multimedia framework, toward identifying the standardization needs and thenjointly agreeing the disposition of any resulting work. They intend to move to the next phase of the MPEG-21 TRat their January 2001 meeting.

Q16&17/16 noted that a lot of common work exists between SG16 and SC29/WG11; it was agreed thatharmonization work is urgently needed. The document on MPEG21, Planned draft technical report (PDTR), isavailable at <http://www.cselt.it/mpeg/standards.htm>.



LIAISONS

TD-94(2/16) is a liaison from SG16 informing other SGs of the present state of SG16 studies in electroniccommerce. It requests information from other SGs on their projected work in this area. It includes a draft table ofthe Questions involved (SGs 7, 13, and 16), and a provisional list of some issues on which work is planned. Theother SDOs participating in the MoU are conducting work on the content of electronic business applications, andITU-T is expected to provide support for communications required by these applications, including mobilecommunications. Q16&17/16 approved this liaison. The liaison, TD-94(2/16), sent from the Q1/16 Rapporteur tothe relevant Study Groups was approved.

Q16 &17/16 decided to send a liaison to all of the relevant SGs and Organizations, describing the SG16 planningMediacom2004 Workshop and its Steering Committee meeting provisionally to be held April 24-27, 2001 inGeneva. The liaison, TD-101(Plen) from J. Magill, acting Rapporteur for QA/16, Mediacom2004 Project, wasapproved.

QUESTION 19/16 WP3, EXTENSION TO EXISTING ITU-T S PEECH CODING STANDARDS AT BITRATES BELOW 16 KBIT/S

The Q19/16 Rapporteur is S. Hayashi (NTT). TD-27(3/16) is the meeting report.

The floating-point implementation of G.729 lacks the test vectors and extensive verification procedures. TheRapporteur encouraged participants to contribute on this issue. However, no contribution was submitted to thismeeting.

MAINTENANCE OF EXISTING SPEECH CODING RECOMMENDATIONS, ESPECIALLY G.729

D.71 (J. Thyssen, Conexant) investigates the discrepancy between the textual description of G.729 Annex B and theC-code of G.729 Annex B (silence compression), reported via e-mail by TI-Telogy Networks. The discrepancyrelates to the initial multi-boundary voice activity decision in Section B.3.5. Since the G.729 Annex B has recentlybeen integrated with Annexes D (6.4 kbit/s CS-ACELP), E (11.8 kbit/s CS-ACELP), and C (8 kbit/s floatingpoint) resulting in the new annexes F (DTX functionality for Annex D), G (DTX functionality for Annex E), I(Reference implementation for integrating the C code of G.729 main body, Annexes, B, D, and E), and C+(Reference floating-point implementation for integrating G.729 CS-ACELP speech coding main body, Annex B, D,and E), the discrepancy would affect those annexes as well. It is the common rule that whenever discrepanciesbetween the C code and the textual descriptions are found, that the C code should have precedence, since the C codewas actually used in the extensive subjective assessments that preceded the standardization work. However, in somecases, changes to the C code might be warranted, hence this investigation. Extensive simulation results indicate thatthe discrepancy has minor impact on the coder performance; it is therefore proposed that the description in theaffected G.729 Annexes be modified to reflect the C-code.

It was noted that no major quality effects were proven to result from this discrepancy; Q19/16 preferred correction ofthe textual description to solve the discrepancy.

D.79 (K. Mano, NTT) proposes editorial corrections to ITU-T G.729 Annexes C+, F, G, and I. Q19/16 agreed toissue a corrigendum.

TD-42(Plen) (S. Hayashi, NTT, Rapporteur) contains proposed corrigenda to G.729 Annexes B, C+, F, G, and I.Q19/16 agreed to issue a corrigendum.

TD-19(3/16) (S. Hayashi, NTT/Japan) contains a summary of the algorithm changes of the speech codingRecommendations published in Implementers Guide. Q19/16 recognized the need of issuing formal corrigenda torevise the set of C-source code available at ITU Sale Service so that it fully reflects the changes. An editing groupwill prepare both proper texts of the corrigenda and a clean line-up of the fully corrected set of C-source code ofrelated G.729 Annexes.

EXTERNAL RESET IN G.728 AND G.729 ANNEXES UNDER DTX OPERATION

TD-01(3/16) is a liaison from Q6/15 on synchronous reset of G.728 and G.729 codecs in CME. It notes that Q6/15has been developing new Recommendations G.768 (DCME using G.729 codecs) and I.733 (VAME: Voice on ATMmultiplication equipment using G.728 and G.729 codecs). G.728 codecs are already used in G.767, DCME using 16kbit/s LD-CELP, digital speech interpolation and facsimile demodulation/remodulation. Q6/15 asks that SG16provide guidance on the usage of synchronous reset when G.728 and G.729 codecs are used in DCME and VAME.



In a liaison response to SG15, TD-29(3/16) notes that SG 16 experts discussed the issue and the experts showed apreference for the existence of a synchronous reset capability in CME using the G.728 algorithm. Aligning theinternal status of the encoder and decoder of G.728 using an external synchronous reset will be beneficial in speechquality, particularly at the transient from silence to active speech when the codec is used under DTX condition inCME. The SG16 experts expect no negative effects on speech quality because of synchronous reset for G.729 underDTX function in CME. Experts present at the SG16 meeting intend to submit experimental results to SG15addressing the effect of synchronous reset on the speech quality for G.729.

TD-02(3/16) is a liaison from SG15 thanking Q19/16 for the information on the Approval of G.711 Appendix II ,Approval of G.729 Annexes C, F, G, and H, and the availability of test vectors for G.728 Annex J (Variable bit ratecompression for voice band data). Q6/15 notes that use of these low-bit-rate codecs is essential for CME. Q6/15expects further coordination with Q19/16 on these aspects.

QUESTION 20/16 WP3, AUDIO AND WIDEBAND CODING IN PUBLIC TELECOMMUNICATIONNETWORKS

The Question 20/16 Rapporteur is R. Drogo De Iacovo (CSELT S.p.A./Italy). TD-32(3/16) is the meeting report.TD-15(3/16) contains the report of the Q20/16 Rapporteurs meeting of November 8-10, 2000, in Geneva.

I. Sebestyen (Siemens) gave a brief oral report on the audio coding activities carried out within IMTC during its lastmeeting in San Antonio, Texas, USA. He informed Q20/16 that one current activity is related to the possible use ofthe ITU-T G.722.1 at bit-rates lower than the specified bit-rates of 24 and 32 kbit/s for videoconferencing andstreaming applications. It was pointed out that there is no unanimous consensus within IMTC on this matter.Q20/16 experts were invited to attend the IMTC meetings and participate in their email workgroups on audio coding.

The general feeling of Q20/16 was that if a new coding activity is to be started within ITU-T, then Terms ofReference should be agreed on the basis of received contributions.

The Delayed contributions listed below were addressed during the Rapporteurs meeting November 8-10 (TD-15(3/16)):

D.19, Codec description and IPR Statement for the Motorola 16 kHz wideband codec candidate (Motorola UK)D.20, WP Experiment 1 qualification test results for the Motorola candidate (Motorola UK)D.21, WP Experiment 2 qualification test results for the Motorola candidate (Motorola UK)D.63, High-level description for proposed wideband (7kHz) codec algorithm (Matsushita)D.64, WB Experiment 1 qualification test results for candidate codec F (Matsushita codec) (Matsushita)D.65, WB Experiment 2 qualification test results for candidate codec F (Matsushita codec) (Matsushita )D.67, Comments for consideration during the drafting of the selection test plan for “a wideband speech coding

algorithm around 16 kbit/s” (Lucent )D.68, High level description and qualification test results of the Lucent Technologies candidate wideband coding

algorithm at 12.8 to 24 kbit/s (Lucent )D.69, Intellectual property statement relating to the Lucent Technologies candidate wideband speech codec algorithm

at bit rates around 16 kbit/s (Lucent )D.76, Communication with ITU-T Q20/16, Audio and wideband coding (Nokia)D.77, BER/RBER/FER mapping used in 3GPP/GSM AMR wideband codec selection tests (Nokia)D.78, High level description of the 3GPP/GSM AMR-WB codec recommended for selection in 3GPP (Nokia)D.80, High level description of NTT’s wideband coder around 16 kbit/s (NTT)D.81, WB experiment 1 qualifications test results for NTT’s wideband speech coder (NTT)D.82, WB experiment 2 qualification test results for NTT’s wideband speech coder (NTT)D.84, Experiment 1 test results of Texas Instruments’ 16kbit/s wideband speech codec (TI)D.85, Experiment 2 test results of Texas Instruments’ 16 kbit/s wideband speech codec (TI)D.86, High level descriptions of Texas Instruments’ wideband coder (TI)D.87, IPR statement for Texas Instruments’ wideband coder (TI)D.88, High level description of TI/Nokia/Ericsson 4kb/s coder (TI)D.90, WB Experiment 1 qualification test results for VoiceAge’s candidate codec (Canada)D.91, WB Experiment 2 qualifications test results for VoiceAge’s candidate codec (Canada)D.92, High level description of VoiceAge’s candidate codec for ITU-T WB speech coding standard (Canada)



WB CODING AROUND 16 KBIT/S

The draft time schedule contained in TD(3/16)15 was revised according to the next planned WP3 meeting in July2001 (Determination of Recommendation). Decision is planned for February, 2002. The updated time schedule iscontained in Annex A (ToR for the ITU-T Wideband (7 kHz) speech coding algorithm around 16 kbit/s) to themeeting report.

A liaison to SQEG/SG12 was drafted to request support in developing an appropriate selection test plan for thewideband coding algorithm around 16 kbit/s [TD-30(3/16)]. This liaison further asks that SG12 consider, duringtheir upcoming February 2001 meeting, the identification of organizations willing to perform the host laboratory,cross-checking laboratory, listening laboratory, and global analysis functions, including the associated cost.

The following issues were briefly introduced for further discussion within the ad hoc group via e-mail:

• Definition of the kind of global analysis to be performed• Definition of a completely blind procedure in evaluating the selection test results• Definition and generation of appropriate background noise material• Issues related to the use of soundcards for playback in the listening sessions• Drafting of the selection test plan• Definition of the processing stages for the host laboratory function• Guidelines for production of demonstration material (random BER and music conditions)• Computation of the codec frequency response using white noise

G.722.1 CORRIGENDUM

COM16-133 (R. Drogo de Iacovo, Rapporteur) is a proposed corrigendum to G.722.1. It corrects three changesnecessary to the existing C code (Release 1.1) that is supplied with ITU-T Recommendation G.722.1. In each case,it corrects an error that was introduced when the original C code (know as release code3.003 at the time ofDetermination) was converted to use basic operators. The corrected code will be labeled as Release 1.2. It wasagreed to submit this corrigendum to the plenary for Decision.

G.722.1 ANNEX B

COM16-121 (R. Drogo de Iacovo, Rapporteur) is draft new Annex B to Recommendation G.722.1 – Floating pointversion of G.772.1. G.722.1, 7kHz audio coding at 24 and 32 kbit/s for hands-free operation in systems with lowframe loss, implements a fixed point algorithm. This Annex contains the description of a floating point extensionto G.722.1, which will allow for easier implementation of the standard in general purpose processors. It was agreedto submit this new Annex B of G.722.1 to the SG16 plenary for Decision. The new C code of G.722.1 Annex B(Release 1.1) will be made available to TSB.

COM16-142 (PictureTel) presents the results of experiments 1, 2, and 3 in the float-fixed point interoperability testfor G.722.1. The results of experiment 1 were previously presented at SG16 in February 2000 and found to besatisfactory. Experiments 2 and 3 represent newly published data for consideration by Q20/16. The resultsdemonstrate good interoperability between the fixed point version of G.722.1 and the proposed floating-pointversion. The subjective tests reported here were conducted by AT&T in New Jersey.

D.32 (P. Luthi, PictureTel) presents a summary of the G.722.1 interoperability tests.

D.33 (P. Luthi, PictureTel) proposes corrections to G.722.1 Annex B floating point source code. PictureTeldiscovered what they believe to be a typographic error in the draft floating-point code for G.722.1 Annex B. Thiserror can cause some music signals to suffer from perceptible distortion when interoperating between fixed andfloating-point versions. The solution is to make a single change to a #define constant in the floating-point code, andadd a scaling factor to avoid overflow when interoperating with the fixed point version.

TD-07(3/16) (P. Luthi, PictureTel, Editor) proposes an editorial correction to draft new Annex B to RecommendationG.722.1. An editorial anomaly related to the list of files comprising the floating point C code was discovered in thewhite document of Annex B to G.722.1 (COM16-121). One of the files listed in Table B.1 has no relation with thefloating point implementation of G.722.1 and should, therefore, be removed from the list. This contributionproposes the correction to Table B.1.

TD-08(3/16) (P. Luthi, PictureTel, Editor) summarizes the results from additional listening tests run at PictureTel.These experiments were designed to verify the interoperability performance of the corrected floating point version ofG.722.1 with the fixed point version of G.722.1.



TD-043(Plen) summarizes the agreed changes (editorial and related to the C source code) contained in TD-07(3/16),TD-08(3/16), and D.33.

FUTURE WORK

A Q20/16 Rapporteurs meeting, followed by a WP3/16 meeting, is tentatively planned for July 23-27, 2001, toaddress the following items:

• Evaluation of the results of the selection phase• Evaluation of the algorithm complexity• Determination of Recommendation and C source code.• Draft version of the characterization test plan

QUESTION 21/16 WP3, ENCODING OF SPEECH S IGNALS AT BIT RATES AROUND 4-KBIT/S

The Q21/16 Rapporteur is P. Barrett (BT, UK). TD-31(3/16) is the meeting report. TD-23(3/16) contains theagenda and meeting objectives. TD-24(3/16) is the report and TD-14(3/16) is the summary of the Q21/16Rapporteurs meeting held November 8–10, 2000.

The current objective of this Question is to select an algorithm or algorithms likely to meet the terms of referencefor the future ITU-T 4 kbit/s speech coding standard (G.4k). The specific objective of this meeting was to review theresults of the floating-point selection phase of the 4 kbit/s speech coding work. Q21/16 agreed to begin a fixedpoint selection phase in August 2001 with two of the three candidates presented at this meeting. The target forselection and Determination of the fixed point Recommendation is October 2001.

The following Delayed contributions were addressed during the November Rapporteurs meeting; they were providedonly for information at this meeting:

D.23, LMGT ITU-T 4 kbit/s Selection host laboratory report (LMGT)D.24, ITU-T 4 kbit/s Selection host laboratory cross-check procedures (LMGT)D.25, ITU-T 4 kbit/s Selection experiments 1A and 3B - LMGT results (LMGT)D.26, High level description of LMGT-Samsung 4 kbit/s coder (LMGT, Samsung)D.70, High level description of the 4 kbit/s algorithm submitted by AT&T, Conexant, Deutsche Telekom, France

Télécom, Matsushita, and NTT (ACDFMN)D.74, Notice of audio demonstration of 2.4 and 6.4 kbit/s extensions and DTX-enabled version of ACDFMN’s 4-

kbit/s speech coding candidate (ACDFMN)D.88, High level description of TI/Nokia/Ericsson 4 kbit/s coder (Ericsson, Nokia, TI)D.89, France Télécom R&D Results for the ITU-T 4 kbit/s Selection Phase – Experiments 1 & 3b (FT)

The main interim activity of Q21/16 was the floating point selection phase. The results of this selection phase werereviewed at the November Rapporteurs meeting. The main decisions made at that meeting are summarized below:

Q21/16 agreed that the two host laboratories, ARCON and LMGT (formerly COMSAT) and the six listeninglaboratories (BT, DT, DYNASTAT, FT, NTT-AT, and LMGT) had fulfilled the terms of their memoranda ofunderstanding (MoU) with the ITU.

Candidate algorithms were presented by the following three consortia:

• A: AT&T, Conexant, Deutsche Telekom, France Télécom, Matsushita, and NTT• B: Texas Instruments Incorporated, Nokia Corporation, and Ericsson Radio Systems AB• C: COMSAT Corporation and Samsung

All eleven consortia members verbally declared that they will abide by Option 2.2 of the ITU patent policy.

RESULTS OF THE FLOATING-POINT SELECTION

Q21/16 reviewed the results of the floating-point selection phase in TD-25(3/16), which are summarized in Annex Aof TD-24(3/16), and in Tables 5-7, below. Candidates A and B will proceed to a fixed point selection phase startingin August, 2001. Candidate C will not be considered any further. The new deadline of August 2001 is intended toallow codec developers time to both implement their algorithms in fixed point arithmetic and to effect performanceimprovements.



Proponent CuT Algorithm Frame-size/ms

Look-ahead/ms

Total delay/ms

AT&T,CONEXANT,DT, FT,MATSUSHITA,NTT

A eX-CELP 20 12.5 (encoder)+/- 2.5ms

52.5+/- 2.5ms

Ericsson, Nokia,TI

B MELP/CELP 20 15 (encoder) 55

LMGT,Samsung

C HE-LPC 20 10 (encoder)5 (decoder)

55

Table 5. Codec overview

CuT MIPS ROM/kword RAM/kword NoiseSuppression

A <38 6 (program)

9 (table)

7 Yes

B 70 20 (program)

25 (table)

5 Yes

C 40 10 (program)

30 (table)

5 Yes

Table 6. Codec Complexity.

Requirements Exp Language CuT A CuT B CuT C1 NAE n Pass -

Normal Level (-26 dBov) 1 F n - -1 J Pass Pass -

1 NAE - Pass -High Input Level (-16 dBov) 1 F n n -

1 J Pass Pass -

1 NAE - n -Low input Level (-36 dBov) 1 F Pass Pass -

1 J Pass Pass -

1 NAE Pass Pass -Tandem 1 F Pass Pass -

1 J Pass Pass Pass

2 G Pass Pass -3% Frame erasure 2 J Pass Pass Pass

2 S Pass Pass Pass

Vehicle noise at 15dB SNR 3a BE Pass Pass -3a J Pass Pass -

Babble noise at 30dB SNR 3b NAE Pass Pass -3b F Pass Pass -

Interfering Talker at 20dB 3c BE - - -3c S - - -

Table 7. Qualification requirements achieved.



Notes to tables:a) “Exp” denotes in which experiment the requirement was tested.b) Key to languages: BE - British English; F - French; G - German; J - Japanese; NAE - North American English;

S - Spanish.c) “Pass” denotes a pass at the 95% confidence interval; “n” denotes a pass at the 99% confidence interval; “-”

denotes a fail.d) CuT denotes codec under test

FIXED POINT SELECTION PHASE

At an ad hoc meeting, the members were unable to reach consensus on a set of hard selection rules or procedures forthe fixed point selection phase. Q21/16 decided that an independent party should perform a detailed global analysis ofthe fixed point selection phase. The calculations and presentation of results for the global analysis will be agreed andfrozen at the first SG16 meeting in 2001. The global analysis will be performed on blind-mapped data, and will befunded by the candidate proponents.

As an aid to the codec proponents, Q21/16 identified which requirements and objectives are seen as particularlyimportant in the development of a 4-kbit/s speech coding standard. This list is provided in Annex C of TD-24(3/16).

Q21/16 agreed to follow the following double-blind procedure for the fixed point selection phase. The candidateexecutables will be delivered to the Q21/16 Rapporteur on August 1, 2001. The Rapporteur will forward the twoexecutables to the host laboratories using a blind mapping (Codecs 1 and 2). After processing the speech materialfor the selection phase experiments, the host laboratory will forward the processed speech material to the listeninglaboratories using a second blind mapping (Codecs A and B). The same mapping will be used for all experiments.The global analysis laboratory will perform its analysis on the double-blind data and forward the results to theRapporteur. After receiving the global analysis, the Rapporteur will request the second mapping from the hostlaboratories, and will upload the global analysis information with the first and second mapping labels to the Q21/16informal ftp site prior to the deadline for submissions to the selection meeting. The selection meeting will thereforediscuss the codecs under their consortium names rather than under blind labels.

Ericsson Radio Systems stated that in their opinion, by not requesting a 2.4 kbit/s extension for the fixed pointselection phase, the ITU-T is missing the opportunity to fill a market need in a timely manner. This view wassupported by Texas Instruments. But France Telecom and Conexant stated that codec developers should concentrateon fulfilling the requirements at 4 kbit/s in all languages before considering the bit-rate extensions. The Rapporteurreminded Q21/16 that this subject had been addressed during the November 8 - 10 Rapporteurs meeting, and that theproposal to include the 2.4 kbit/s extension in the selection phase was rejected because it represented a significantchange to the existing work-plan of Q21/16.

REVIEW OF SCHEDULE

Q21/16 reviewed the revised schedule and list of deliverables attached in Annex B to the meeting report. Due to thelack of a future meeting calendar, this schedule and the use of the new alternative approval procedure (AAP) areprovisional; this will be reviewed at the next SG16 meeting.

LIAISONS

TD-26(3/16) is a liaison to Q22/12 (SQEG) requesting the following actions:

• Preparation of a subjective test plan for the 4 kbit/s speech coding fixed point selection phase• Identification of organizations to perform the host laboratory, listening laboratory, and global analysis functions• Guidance on the preparation of the global analysis

During the presentation of the floating point selection phase at the November 8-10 Q21/16 Rapporteurs meeting,Q21/16 identified several experimental procedures that could be improved or refined in the fixed-point selectionphase.

For the floating point selection phase, one listening laboratory reused listeners across three experiments (Q21/16 andQ22/12 were notified of this before testing began); SG16 asks that in future subjective experiments, listeners not bereused across multiple experiments.

SG16 emphasizes the need to use speech and noise material that has not been available to codec developers, andproposes the following refined principles for the fixed point selection phase:



• Speech source material must not be used if either samples from the same speaker or recordings from the samerecording session are, or have been, available to candidate proponents.

• A segment of noise taken from a longer noise recording must not be used if any section of the longer sample is,or has been, available to codec developers.

QUESTION 22/16 WP3, SOFTWARE AND HARDWARE TOOLS FOR STANDARDIZATION OFSPEECH AND AUDIO CODING ALGORITHMS

The Q22/16 rapporteur is S. Campos-Neto (COMSAT). TD-13(3/16) is the report of the interim activities ofQ22/16.

Currently Q22/16 is dealing with the maintenance and future enhancements of the STL96. At the last SG16meeting, Q22/16 agreed to officially issue a new release of the ITU-T Software tool library (STL2000), reflected as arevision to G.191 Annex A.

After reviewing the “informal” updates that were done over the last four years for the STL96, Q22/16 unanimouslyagreed with the Determination of a new (full) release of the STL, dubbed STL2000, which will incorporate allevolving STL (eSTL) releases made available so far (eSTL9801 and eSTL9901), plus the set of basic operatorsagreed upon in Santiago (May 1999). This update will impact on revising G.191 Annex A (which is the textformally submitted for Determination), and will require the preparation of a new release of the STL User’s Manual.Editorial contributions on the last item were invited.

Release 1 of the STL2000 was made available at the February meeting both via the TSB as well as in the IFA forSG16. Some minor bugs were corrected and identified in two subsequent releases (R2 and R3). R3 was delivered tothe ITU on July 13, together with the final text for G.191 Annex A (see COM16-139E). The draft revised G.191Annex A was proposed for Decision at this meeting; it was unanimously agreed to forward G.191 to SG16 forDecision.

PROGRESS ON SOFTWARE TOOLS

The following are the changes from the STL2000R1 to STL2000R3:

General. Updated pre-defined symbol for compilation under Win32/gcc (from __CYGWIN32__ to __CYGWIN__)for modules G711, G722, BASOP, FIR, UTL, and UNSUP. Compilation scripts were updated and tested forautomatic binary generation and testing from the STL2000 root directory (covering modules EID, FIR, G711, G722,G726, G727, IIR, IS54, MNRU, RPELTP, SV56, UNSUP, and UTL) for several platforms/compilers (HPUX/gcc;Win32/cl; CygWin/gcc; Sol7-Sparc/gcc).

Basic operators. Work by correspondence confirmed inclusion of shiftless 32-bit multiplication operatorsL_mult0(), L_mac0(), and L_msu0(). No discussions were held on the revision of the weights for the 32-bitoperators.

EID. No functional changes performed in the module core (eid.c). Added a global variablePORTABILITY_TEST_OPERATION to eid.c that does not affect the module operation but allows thedemonstration programs to print a warning to the user that the C code has been compiled with the portability testoperation (which causes the module to produce systematic error patterns for portability purposes). Modified thedemo programs to use this feature (eiddemo.c, eid8k.c, and gen-patt.c). Identified execution problems ofgen-patt.c and ep-stats.c with Win32/cl and Win32/gcc while the same code works properly in Unixsystems. It seems that both Win32 compilers share a buggy malloc run time library. The problem has not beencorrected.

G711. Corrected g711demo.c for the calculation of the number of blocks to process under Win32/cl andWin32/gcc by including <math.h>. No changes performed in the module core (g711.c).

G722. The ZIP file with the restricted set of test vectors was renamed from g722-unx.zip to tst-g722.zip, for consistency with other modules. Changed makefiles accordingly. Found a bug in g722demo.c (notsolved), whereby options N1 and N2 are ignored by the code and the whole file is processed. No changes performedin the module core (g722.c).

G726. Corrected bug in vbr-g726.c when the user does not specify the bit-rate. The array for bit rates was notinitialized and caused a segmentation fault, and now it defaults to 32 kbit/s operation. Also fixed the incorrect



calculation of the total number of blocks to process when the block size is not a multiple of the file size. Nochanges performed in the module core (g711.c).

G727. Editorial corrections were done in the C code self-documentation (comments). No changes performed in themodule core (g727.c).

MNRU. In mnrudemo.c, changed memory allocation of floating point buffers in[ ] and out[ ] from static todynamic, to prevent memory invasion when block sizes larger than 256 are specified. No changes performed in themodule core (mnru.c).

FIR. In fir-irs.c, replaced the RXIRS filter coefficients (8 and 16 kHz) with a new set that more closelyfollows the Modified-IRS receive mask and generated new test vectors and updated the relevant makefiles. Removedcompilation warnings observed with Win32/cl in modules fir-{dsm,irs,pso,tia}.c. Updated filter.cto display online help for option -delay. Also in filter.c, disabled down-sampling with FIR filters whenblock size is 1 (i.e., sample-based operation) because of a bug in fir_downsampling_kernel() [in fir-lib.c] that causesthe output file to be one sample long. Until the function is corrected, this operation will be disabled in thisprogram. In the makefiles, purged test files that had the same CRC32: test022.ref & test023.ref, test009.ref &test011.ref, test014.ref & test016.ref, test004.ref & test006.ref, test020.ref & test021.ref, test008.ref & test010.ref,test012.ref & test013.ref, and test005.ref & test007.ref.

SV56. Changed memory allocation in sv56demo.c and actlevel.c from static to dynamic, command lineadded options (-blk, -start, -end, and -n) options, updated makefiles and revised the read-me files. Nochanges performed in the module core (sv-p56.c).

UTL. Added a new informational symbol definition in ugstdemo.h, labeled COMPILER, which contains a textstring describing the compiler used in a given built. No changes performed in the module core (ugst-utl.c).

Unsupported tools. (Note: This portion of the STL2000 is non-normative.) A minor bug was corrected insb.c for the temporary filename (-over) when compiled with Win32/cl and added an option for conditional byte-swapping when overwriting a file (depending on whether the system is little or big-endian). Changed memoryallocation in sine.c for data buffer from static to dynamic, to prevent memory invasion when block sizes largerthan 256 are used. Corrected bug in oper.c that made incorrect calculation on total number of blocks to processwhen the block size is not a multiple of the file size. Added two new unsupported tools: astrip.c, concat.cto the UNSUP directory with test vectors. Updated makefiles and test vectors, as well as the top-levelmakefiles/batchs for automatic compilation of the STL.

After review of the changes, Q22/16 unanimously agreed to forward G.191 Annex A for Approval (Decision) bySG16.

BASIC OPERATORS

A set of 40-bit operators was circulated to the reflector before the meeting but no feedback was received. It wasmentioned at the meeting that 3GPP-2 is likely to use the 40-bit operators in their upcoming SMV variable bit ratecoding standard. The group also reviewed TD-10(3/16) liaison from 3GPP TSG-SA WG4, which indicates that theyforesee usage of the 32 bit operators. Q22/16 agreed to inform both groups of the approval of the STL2000,including the 32-bit basic operator set, and of the on-going work on the basic operators.

Q22/16 agreed to continue the work on the 40-bit basic operators.

STL USER’S MANUAL

Q22/16 agreed that the STL User’s Manual should cover maintenance. The Rapporteur provided a draft version ofthe STL2000 User’s Manual, which is also available in the SG16 IFA. Q22/16 discussed ways to publish theManual, but reached no firm conclusion. Options discussed included: current means (an attachment to the C codedistribution), an Annex, or an Appendix (either in paper or as a one-page paper with electronic attachment). Thecurrent text is available as a postscript/PDF file, since the source of the document is typeset with LaTeX, and notMS Word. The possibility of converting the text into MS Word was noted. The Rapporteur will consult with theTSB to identify the best means of publication. The Rapporteur invited interested parties to review Manual chaptersin the meantime, and provide feedback. Discussions towards a final version of the Manual will continue via theWP3 reflector ([email protected]).



LIAISONS

TD-30(3/16), a joint Q20/Q21/Q22 liaison, informs Q22/12 (SQEG) that a new release of the ITU-T Software toollibrary (STL2000) has been Decided.

TD-29(3/16) Annex B is the liaison to ETSI/3GPP and TIA TR-45.5/3GPP-2 with information on the status ofbasic operators in the STL.

FUTURE WORK I

Q22/16 agreed to try to identify a frequency-response tool that will have direct use in the Q20/16 work. It wasagreed that at least a framework of the tool should be agreed in the reflector discussions by mid February 2001.Other possible relevant work items include:

• G.728 implementation• Linear interface to G.726 and G.727 (i.e., Annex A to G.726 and G.727)• G.711 packet loss concealment (G.711 Appendix I)

Annex A of TD-013 contains the revised list of action items for Q22/16. The group also reviewed the list inCOM16R-71 eliminating a number of work items that were obsolete. The remaining action items will beprogressed by correspondence.

QUESTION 23/16 WP1, PCM MODEMS

WP1/16 addressed Q23/16 under the chairmanship of L. Brown (Motorola, Q23/16 Rapporteur). TD-32(1/16) is theagenda. TD-29R1(1/16) (L. Brown, Rapporteur) is the Q23/16 status report.

The following companies have indicated that they may have intellectual property pertaining to V.92: 3Com, AnalogDevices, Broadcom, Conexant, ESS, Intel, Lake Datacomms, Lucent, Motorola, Panasonic (MGCS), PCTel,Siemens, and Texas Instruments. No further verbal IPR declarations were made at this meeting.

COM16-R77, Report of the June, Edinburgh Rapporteur’s meeting, contains the Determined text of draft newRecommendation V.92, Enhancements to Recommendation V.90. The Editor prepared TD-37(1/16) incorporatingall of the agreed changes to the Determined text of V.92 in COM16-R77. This was approved after revision forforwarding to the SG16 plenary for final approval. TD-44(Plen) (K. Jones, Lucent Technologies, Editor V.92) is thefinal version of the document; it contains the agreed changes to the Determined text of V.92, marked againstCOM16-R77.

TD-31R1(1/16) is the report of the Q23/16 Rapporteur meeting held in Geneva, November 10-12, 2000. The mainpurpose of that meeting was to complete the draft of V.92 in preparation for final approval at this SG16 meeting. Abrief Q4/16 meeting was also held, primarily to consider proposed V.250 commands to support V.59. Thefollowing contributions were considered at that meeting:

D.7, Proposed Appendix for V.92 on modem on hold (USA, K. Chu, Conexant Systems). Q23/16 WP1 agreed tomake changes to the draft text in § 9.10.2.1 (2 places), § 9.10.2.3, and Figures 18, 20 and 22/V.92, to define thesilent interval as < 80 ms prior to ANSam. However, concerning the Appendix itself, it was felt that the materialwas not mature enough to seek approval at that meeting; it was therefore proposed to continue work on theAppendix with the goal of approval at the next SG16 meeting.

D.8, Proposed changes to draft Recommendation V.92 (USA, K. Jones, Lucent Technologies), was accepted.Additionally, in Tables 3, 5, 12, and 14/V.92, it was agreed to replace “revision number” with “V.8 bis revisionnumber (Note)” and to add the note “At the time of publication the V.8 bis revision number is 0100. The receivingmodem shall ignore this field.”

Q23/16 agreed to request that Q7/16 make the following changes in D.10, Proposed +P commands to supportRecommendation V.92 for inclusion in the V.250 Implementers Guide (see Q7/16 report for the list of commands):

• Remove “recommended” from “recommended default” throughout• Remove the default setting from the +PMHT command in § 6.8.3• In the description of the +PQC command in § 6.8.7, indicate that this command does not “initiate” the short

Phase 1 and Phase 2 startup procedures. Specifically, append the phrase “, not the initiation thereof” to thedescription



Furthermore, Q23/16 found that the “enabled” state is unclear and also wondered whether there might not be a needfor a command to initiate (force) a short Phase 1 or Phase 2 procedure.

TD-51(1/16) (K. Chu, Conexant Systems, Editor) is the report of the joint Q7/Q23 ad hoc meeting considering theproposals contained in D.10, Proposed +P commands to support Recommendation V.92 for inclusion in the V.250Implementers Guide (F. Lucas, 3Com) This was reviewed and approved during the joint session with Q7/16 (seeQ7/16 report for additional detail).

D.12 (USA, K. Chu, Conexant Systems) proposes modifications to short phase 1 to ensure proper operation withnetwork echo cancelers. A problem has been observed in the field while testing the short phase 1 operatingprocedure of the determined V.92 draft. It is believed that this problem may be due to network echo cancelers that arenot compliant with Annex B of G.165. The modified short phase 1 operating procedure contained in D.12 avoidsthis problem by requiring a full second of ANSam to be received before initiating a QC1-QCA1 exchange. This, inturn, requires changes to the error recovery procedures. Some problems with the existing error recovery procedureswere also discovered and corrected. To avoid excessive increase in connect time when connecting to legacy modems,CM is transmitted after QC1. To avoid similarity to TONEq on the boundary of QC1 and CM, the last 10 bits ofQC1a and QC1d are removed. This was approved for inclusion in V.92. Additionally it was agreed to define theappropriate silent interval durations as 75 ± 5 ms throughout the short Phase 1 procedure, and to fix an error in newFigure 7/V.92.

TD-02(1/16) is a liaison from Q6/15 and Q7/15 in reponse to 23/16’s liaison on ANSpcm (TD-006, 2/15 , CSRVol 11.5). The experts of SG15 looked at the description for this new answer tone signal and, from an inspection ofthe information contained in the liaison and the spectral plots, they believe that this signal will reliably disable echocontrol equipment that is compatible with Recommendations G.164, G.165 and G.168. One concern is notedregarding the –18.0 dBm transmit power option for the ANSpcm echo canceller disable tone. The concern is that inthe upstream direction, the disable tone signal level received by the network echo canceller may be too low to berecognized as a valid disable tone.

D.14 (M. Nichols, 3Com; Texas Instruments) compares the properties of TRN1u both differentially encoded and notdifferentially encoded. In the Determined text for V.92, the phase 3 signal, TRN1u, is not differentially encoded.The signals following TRN1u, Ja and CPt, are differentially encoded. This makes detecting the first occurrence of Jaand CPt difficult and unreliable. Because Ja, in particular, is somewhat long, it is advantageous to allow itsdetection the first time. Simulation results show that differentially encoding TRN1u has almost no effect on theequalizer training convergence. This contribution was presented for information.

FUTURE WORK

The future work of Q23/16 will be addressed by the new Q11/16. Plans for interim meetings of Q11/16 to work onV.moip are Jan 22-26, 2001, in California, and Apr. 30 - May 4, 2001, location to be determined.

QFAX1/16 WP1 (FORMER QUESTIONS 1/8, 4/8, AND 5/8)

WP1/16 addressed the work of former SG8 Questions 1, 4, and 5, under the chairmanship of L. McIntyre (Xerox,previous Q5/8 Rapporteur). TD-26(1/16) is the agenda. TD-73(1/16) is the meeting report.

T.38 AMENDMENT 3, FOR APPROVAL

COM8-114 (SG8) is the draft Amendment 3 (TPKT, IAF Support, Amendment to Annex D, E, Appendix V) toITU-T Recommendation T.38, Real-time fax over IP. COM8-R15 (TSB) is the report of the SG8 meeting,February 2 - 10 2000, Part II.2, specifying draft Recommendations for T.4 Amd2, T.30 Amd2, and T.38 Amd3.

The IFax ad hoc convened to address T.38 and T.37 related items, generated clarifying amendments to Section 1 ofCOM8-R15, based on the Gaithersburg Q4/8 Rapporteur meeting June, 2000. These amendments are documented inTD-50(1/16), Texts for draft Amendment 3 to T.38 (J. Rafferty, Brooktrout). QFax1 agreed to these amendmentsand to TD-50(1/16) [TD-102(Plen)], to be forwarded to SG16 for approval.

TD-29(Plen) (D. Skran, Sonus Networks, Q13/16 Rapporteur) contains Recommendation A.5 references to RFC2833, RTP Payload for DTMF digits, telephony tones, and telephony signals, as referenced by T.38 Amd3.



T.89, FOR APPROVAL

COM8-115 (SG8) is the draft new ITU-T Recommendation T.89, Application profiles for Recommendation T.88,Lossy/lossless coding of bi-level images (JBIG2) for facsimile. T.89 was Determined during the September 1999SG8 meeting, and published in COM8-108.

TD-01(1/16) (L. McIntyre, Xerox, Editor T.89) is a liaison from ISO/IEC JTC1 SC29 JBIG; it contains the JBIGCommittee’s recommended modifications to Profile 0x00000102 (Profile 2) of draft Recommendation T.89: no“mixing” constraint of T.89 Profile 2, retention of a two-stripe minimum requirement. The ISO recommendationsare largely based on the findings of a study on the impact of constraining the JBIG2 stripe count and restrictingstripes that contain text image regions from containing other image regions, such as generic or halftone. TD-19(1/16) (L. McIntyre, Xerox, Editor T.89) contains a copy of the referenced study (N1766). This study showssignificant negative impact on decoder memory requirement associated with the proposed “mixing” constraint, and noimpact of the two-stripe minimum constraint on the T.89 JBIG2 application profiles.

TD-11(1/16) (L. McIntyre, Xerox, Editor T.89) contains a proposed revision to the version of draft T.89 that isdocumented in COM8-115. The edits include correction for an omission in the “Symbol coding - memory limit”definition, specified as item 7 in Section 4.2 of the draft. It also includes an editorial clean up of rows 27 and 28 ofthe JBIG2 Fax Profiles table, specified in Section 4.1. These edits do not change the intent of the COM8-115 draftfrom that communicated in TD-01(1/16). QFax1 discussed these proposed amendments, and generated some minoreditorial clarifications. The revised text was agreed as documented in TD-50(Plen), Proposed revision of the T.89draft, documented in COM8-115 (L. McIntyre, Xerox, Editor T.89).

TD-12(1/16) (L. McIntyre, Xerox, Editor T.89) proposes revision of draft Recommendation T.89, ApplicationProfiles for Recommendation T.88. Draft T.89, Determined during the Sept. 24, 1999 SG8 meeting and publishedin COM 8-108, defines three profiles of JBIG2 (draft Rec. T.88 | ISO/IEC 14492) for facsimile applications. TheT.89 facsimile profiles are based on the relatively general JBIG2 profiles, as documented in COM 8-96. During theirDecember 1999 meeting, motivated by the desire for IPR-free base profiles, ISO/IEC JTC1 SC29 JBIG Committeeadded two new base-level profiles to the list in COM8-96. In a liaison to SG8, they proposed revision of T.89 toaccommodate the two new profiles. TD-12(1/16) contains a mark-up of COM8-108 accommodating profile changesand editorial enhancements based on ISO’s proposals. Based on recommendations from TD-245 (SG8 February,2000, CSR Vol. 11.2), TD-12(1/16) also defines the “JBIG2 Fax Profiles” table memory level, i.e., rows 18 and 22,which were designated as TBD.

TD-27(1/16) (L. McIntyre, Xerox, Editor T.89) provides the status of draft Recommendation T.89. It recommendsrevision of the draft per TD-01(1/16), and asks that SG16 consider approval of T.89. COM8-115 and TD-50(Plen)contain the text for draft Recommendation T.89; this was forwarded to SG16 for approval.

T.4 AMENDMENT 2, K FACTOR PARAMETERS AND REFERENCES, FOR APPROVAL

COM8-R15 contains the agreed text for Recommendation T.4 Amd2, and was forwarded to SG16 for approval. Kfactors support optional higher resolutions. See CSR Vol. 11.2 for additional details.

T.30 AMENDMENT 2, FOR APPROVAL

D.17 (Japan, Y. Yoshura, Canon) provides comments on the use of third generation mobile network connection bit,as approved at the February 2000, SG8 meeting (COM8-106 add, CSR Vol. 11.2). It notes that 3GPP does notdiscuss any action for the use of such a mobile connection bit for facsimile terminals, nor does the first 3GPPspecification include any functions to do something when detecting the mobile bit indication of facsimile terminals.Furthermore, the next version of the 3GPP specification does not consider such functions either. At the beginningof the discussion of the 3GPP specification, it was suggested that a procedure to control a data receiving buffer at thenetwork when a facsimile terminal scans papers in communication might be necessary, and that therefore such a bitmight be required. But now the network itself copes with such issues. Therefore, neither Japan nor the 3GPPexperts group requires this bit. QFax1/16 agreed that this bit should be designated as “reserved for third generationmobile network.”

TD-10(1/16) (L. McIntyre, Xerox, Rapporteur of former Q5/8) is a request for former Q1/8 to define the values ofTable 2/T.30 “memory capacity” bits X+10 and X+11. Q5/8 recommends that Q1/8 fix the three discrete values forthe memory capacity levels, represented by bits X+10 and X+11 in Table 2/T.30 of COM8-106. The benefit ofdefining the values of the three memory levels within Table 2/T.30 is that other applications, i.e., other than JBIG2,may use these bits to negotiate working buffer requirements. This document is a reproduction of TD-307 (SG8



February, 2000, CSR Vol. 11.2) on Table 2/T.30 memory capacity bits assignment, from the February 2000 SG8meeting; it is to be referenced in amending the definitions.

QFax1/16 agreed to clarification (add “T.38 mode”) of the name of the bit proposed in COM8-R15 for Internet-awareT.38 fax. This is documented in TD-61(1/16) [TD-94(Plen)], T.30 Amendment 2 for approval (L. McIntyre, Xerox,QFax1 Rapporteur).

COM8-106 introduces Table 2/T.30 bits X+10 and X+11 for use in negotiating the capacity of a working buffersupported by a receiver and the corresponding capacity required in accommodating a transmission. COM8-106 alsostates that the values of the three memory levels will be defined in T.89 for each of the T.89 profiles. TD-245 (SG8February, 2000) proposes values for the three memory levels; it also proposes that the same three values be used forall of the T.89 profiles.

QFax1/16 revised bits and notes designated in COM8-106 Add.1 for JBIG2 Application Profiles (draft T.89) forclarification; they are to be included in T.30 Amd2. The note associated with bit 116 “T.45 (Run length colorencoding),” which was not included in T.30 Amd1, because of reference to T.89, was amended for clarification and isto be included in T.30 Amd2. The name of bits 117 and 118 “Memory capacity” and the associated Note 70 wereclarified to more accurately reflect the intention for use by a decoder when data (i.e., meta data) must be stored to beused in decoding the data stream. TD-61(1/16) [TD-94(Plen)], T.30 Amendment 2 for approval (L. McIntyre, Xerox,QFax1 Rapporteur) documents all the agreed versions for all of these COM8-106 Add.1-related bits; TD-61(1/16)was agreed.

Other T.30 Amd2 items from COM8-R15:

• Section 2: The flow diagram of Figure 2 was clarified by removing duplication of the “Reset 6s Timer T2.”• Section 6: Proposed text for T.30 Section 6.1.1 was removed from consideration due to insufficient information

in designation Option 1 or 2 of the proposed text. Upon receiving requested clarification from SG15, QFax1/16may include the appropriate text in a future T.30 amendment.

• Section 7: New Annex K was removed from consideration due to Japan’s belief that the text referenced in COM8-106 was revised during a February 2000 SG8 ad hoc meeting and is not reflected COM8-106. UK has submitteda formal objection to approval of Annex K.

• Section 8: The flow diagrams of Figures IV.13 and IV.14/T.30 were revised to correct formatting issues.

All these revisions were agreed; they are documented in TD-61(1/16). QFax1/16 agreed to consolidate all of the T.30Amd2 items in TD-61(1/16).

T.30 AMENDMENT 3, FOR CONSENT

TD-95(Plen) (L. McIntyre, Xerox, QFax1 Rapporteur) is Amendment 3 to Recommendation T.30 for consent; itspecifies the changes to be applied to the Recommendation T.30 based on D.42.

D.42, Proposal for T.38 IAF device with respect to minimum scan line time (H. Endo, Oki Electric; Canon,Matsushita Electric, NEC, Ricoh, Toshiba), amends Note 8 of Table 2/T.30 to specify MSLT of 0 msec fortransactions between T.38 IAF implementations. The example illustrated shows a configuration whereby IAFdevices are connected directly to each other via an IP network, in which case communication is established byinserting a T.30 signal into a frame defined in T.38. But, as both terminals are directly connected to the IP network,there is no transfer speed value to be set in the DIS and DCS signals; consequently, minimum scan line time cannotbe decided. This problem can be resolved by deciding that minimum scan line time be 0ms (same as error correctionmode) when IAF devices are directly connected through an IP network. QFax1/16 agreed to seek Determinationduring the plenary session so that this may be reflected in a future T.30 Amendment 3. The appropriate summary isdocumented in TD-63(1/16), Summary for T.38 IAF device with regard to minimum scan line time (L. McIntyre,Xerox, Temporary Editor T.30).

T.37 AMENDMENT 2, FOR CONSENT

TD-08(1/16) (H. Tamura, Ricoh, Editor) presents a memo from the Internet Society (RFC 2879) which describes themedia content feature schema for Internet fax. The memo defines a profile of the media feature registrationmechanisms for use in performing capability identification between extended Internet fax systems. RFC 2879replaces RFC 2531 in IETF.

TD-09(1/16) (H. Tamura, Ricoh, Editor) presents a memo from the Internet Society which describes how to mapGroup 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in



RFC 2879. At the previous Q4/8 meeting in 1998, the internet draft <draft-ietf-fax-feature-T30-mapping-02.txt>was submitted; that draft has become RFC 2880.

QFax1/16 agreed to revise the T.37 RFC 2531 and RFC Mapping references to reflect the new RFC 2879 and RFC2880. The appropriate T.37 amendments and the necessary summary are in TD-47(1/16), Proposed Amendment 2 toRec. T. 37 and summary to Rec. T.37 Amendment 2 (T. Maeda, Canon, T.37 Editor).

IFAX AD HOC

The QFax1/16 IFax ad hoc convened to address all T.37 and T.38 matters. TD-68(1/16) (H. Tamura, Ricoh) is therevised IFax ad hoc report (replaces TD-45(1/16)). The IFax ad hoc agreed to T.38 amendment 3 for approval. TD-50(1/16), Texts for draft Amendment 3 to T.38 (J. Rafferty, Brooktrout), contains all the references and modified andadditional sentences for the version proposed for Decision at this meeting.

T.38 Support over V.34 Half-Duplex

D.44 (USA, I. McCallum, Intel) proposes a draft amendment (GMD-40) generated during the Gaithersburg Q4/8Rapporteur meeting) to Recommendation T.38 to allow Group 3 facsimile terminals implemented with V.34 half-duplex modulation capability, as specified in Recommendation T.30, to transfer facsimile documents in real-timebetween two standard Group 3 facsimile terminals over the Internet or over other networks using IP protocols. D.44proposes text to amend Sections 2, 3, 4, 2.3.2, 2.3.3, Annex A, and Annex B of T.38. It also provides a new T.38Section 10 and Appendix II. Support for V.34 fax using full-duplex modulation is for further study.

TD-03(1/16) is a liaison from the former Q4/8: Q4/8 was working on adding V.34 support for Rec. T.38; theyexpected to Determine an amendment to support this at a future meeting. This liaison includes a copy of GMD 31(I. McCallum, V.34/T.38 ad hoc in Gaithersburg), Control channel data rate change handling for V.34 half-duplexfax operation over T.38, for information. The content of this document is included in D.44.

Discussion on D.44 generated some editorial clarifications from D.15, Proposal for amendment in T.38 regardingmessage flow for V.8 signals (Canon, Matsushita Electric, NEC, Oki Electric, Ricoh, Toshiba). D.15 proposes anamendment to T.38 regarding the V.8 start-up sequence over IP network, as discussed at the June 2000, Gaithersburgmeeting. As a result of that meeting, the description of the spoofing mechanism in Appendix II was deleted becauseit was considered that network delay tolerance can be satisfactory. However, from the facsimile terminalmanufacturers’ point of view, when ANSam transmission timeout expires at the receiving side due to any troubles,it is desirable that the receiving terminal should be able to fall back to standard Group 3 procedures. This procedurewas described in the spoofing proposal of TD-272 as follows: Once receiving a “t30-data(HDLCdata, info)” messagefrom G2, G1 disables V8 capabilities bit in DIS sequence and falls back to standard Group 3 procedures. On theother hand, according to the new Section 10.1, V.8 negotiation, which was introduced in GMD-40, it is appropriateto add such a description; this contribution proposes text to this effect, to be added to section 10.1.

It was suggested that the real issue here is the case where network delay occurs, so that the response to ANSam isnot CM, but the initiation of V.21 operations. It was also suggested that in such a case, either gateway might electto drop back to V.21 operations. QFax1/16 IFax ad hoc agreed to modify the proposed text as follows:

“In the event that there is a timeout in response to an ANSam generated by the emitting gateway, resulting in aV.21 response, either gateway may elect to prevent a possible return to V.8 negotiations by resetting the V.8DIS bit.”

This was inserted into D.44 as a new paragraph 3 within section 10.1. It was agreed that D.44, with this addition, isthe base text.

D.31 (Y. Sivan, Surf Communication Solutions) discusses data rate change handling for V.34 half-duplex faxoperation over T.38, using externally initiated retrains. In the V.34 half-duplex over IP, a mechanism is required toavoid data overflow and underflow in the gateways. This can be obtained by rate adaptation between the two V.34half-duplex connections; rate adaptation must take place at initial training, control and primary retrain, controlrestart, and control resynchronization if one of the fax requests change. Recommendation T.38 must clearly definethese operations to ensure proper functionality of the V.34 half-duplex standard. To avoid interoperability problems,this procedure should not involve any changes in the current V.34 standard. D.31 suggests a process for coordinatingboth gateways based on control channel retrains rather than “Non functional MPh”; such a sequence is not defined inthe V.34 half-duplex and might cause interoperability problems. It also suggests a mechanism for coordinating thebeginning of the control channel data transmission between both gateways based on delaying the transmission of E:in this case a new indicator “start control channel data” should be added to T.38.



A small ad hoc considered D.31. It includes useful information for Implementers. TD-71(1/16) is the report of thisad hoc meeting; it lists changes that resulted in a new revision of D.44 as WD9. The following is the outcome ofthis meeting:

• It was agreed to remove reference to non-functional MPh signal from the T.38 amendment. Last paragraph ofsection 10.2.2 of D.44 was modified accordingly.

• Figures 5, 6, 7, and 8 of D.44 were modified to remove reference to non-functional MPh sequence.• Added line in section 10.2.2 of D.44. “If a Gateway receives MPh sequence from local G3FE that is different

from the previously received MPh sequence from local G3FE, Gateway shall forward the new “combined MPh”sequence to the Remote Gateway.”

• Change suggested by D.15 is included as a new paragraph 3 within section 10.1 of D.44. “In the event that thereis a timeout in response to an ANSam generated by the emitting gateway, resulting in a V.21 response, eithergateway may elect to prevent a possible return to V.8 negotiations by resetting the V.8 DIS bit.”

TD-49(Plen), Draft amendment to Recommendation T.38 to support the use of V.34 modulation (QFax1/16, IFax adhoc), is the new version. QFax1/16 agreed that this draft will serve as the base for future discussions, and should beconsidered for Determination during the next SG16 meeting.

TD-04(1/16) is a liaison from Q4/8 in reply to the liaison from SG16 on procedures for handling V.8 in T.38applications; it was presented for information. See Q4/16 report for additional details.

T.38 IAF (Internet-Aware Fax) device

D.42 (H. Endo, Oki Electric; Canon, Matsushita Electric, NEC, Ricoh, Toshiba) is a proposal to amend Note 8 ofTable 2/T.30 to specify MSLT of 0 msec for transactions between T.38 IAF implementations; the Ifax ad hoc hadno opposition to this proposal. See T.30 Amd 3 above for additional details.

D.38 (H. Tamura, Ricoh; Canon, Matsushita Electric, Oki Electric, NEC, Toshiba) proposes to clarify timingsassociated with sending and receiving T.30 signals, as documented in T.38 Appendix 1. It was agreed to accept theproposal in the section 3.1 of D.38, in which the word “considering” is replaced with “taking into account” and theword “signals” after DCS and CFR in the example texts. The content will be added to T.38 Appendix I at the nextSG16 meeting. It was noted that the t38FaxMaxDatagram should be used within the UDP mode by an IAF orgateway to specify a datagram size that is less than the maximum legal value of 64 kilobytes. For example, thiswould enable a terminal to identify a value for the t38FaxMaxDatagram that will reduce the possibility of dataoverflow. IFax ad hoc agreed that the D.38 request for clarification with regard to t38FaxMaxbuffer andt38FaxMaxDatagram parameters will require further contributions.

T.38 Cal l Contro l

D.16 (Canon, Matsushita Electric, NEC, Oki Electric, Ricoh, Toshiba) proposes an amendment to T.38 Annex B,Normal connection and disconnection sequence, which was proposed in TD-299 (T.38 Appendix II, IG of callestablishment procedures described in T.38 Annex B) at the February 2000, SG8 meeting, and approved for Decision.At the June Gaithersburg meeting, draft H.323 Annex D v.2 was introduced; it describes a detail switching sequencebetween voice and fax. In comparison with that, the normal connection and disconnection sequence of TD-299seems to be insufficient. It is not appropriate to repeat a detail sequence in T.38 Annex B just to maintaincompatibility; D.16 proposes addition of a note to the sequence figure in Section II.1.2.2 of T.38 Annex B, asfollows: *4 The switching mechanism should refer to section “D.6 replacing an existing audio stream with a T.38fax stream” in H.323 Annex D.

D.16 was agreed, with some the small modifications documented in TD-34(2/16), Corrections to the H.323v.4 whitepaper contribution (D. Skran, Sonus Networks, Q13/16 Rapporteur). These amendments are to be considered forT.38 Appendix 2 amendment during the next SG16 meeting; they are documented in TD-68(1/16).

Other T.38 Issues

TD-35(1/16) (D. Mactaggart, Cyberfax) addresses the history of fax-as-data services, performance over the Internet,and suggests solutions to unsolved issues for T.38 implementation. It identifies the T.38 performance issues from aseries of studies conducted by more than one independent party. It holds that improvement in forward error correctionschemes would be the best source of T.38 performance enhancement. In particular, it describes the followingfundamental deficiencies of T.38:



• “Extreme” spoofing is discouraged due to its high latency. Possible solution: SCTP• A higher level of error protection for FCFs that image data is invited. In the network service that was

implemented, typically 10-fold redundancy with parity was used for FCFs, but 2-fold redundancy for image data.This resulted in an average bandwidth consumption of 25 kbits/channel in T1 (24 channel groups).

This document includes useful information for Implementers. Future work should include work efficient errorcorrection. Contributions were invited.

Other T.37 Issues

D.45 (T. Maeda, Canon) provides information for the T.37 Internet fax work plan for SG16, which took over theremaining work in SG8. T.37, Procedures for the transfer of facsimile data via store and forward on the Internet, waspublished in 1998 and 1999 for Internet fax simple mode and full mode. D.45 notes that TD-280Rev.2, from theFebruary meeting, summarizes further areas of study for T.37 including FFPIM (Full-Mode Fax Profile for InternetMail) and Terminal mode. Terminal mode enables the same functions as Group 3 fax using T.30 signals inconfirmation and capability exchange and was proposed at Q4/8 Rapporteur’s meeting at Gaithersburg in June 2000.D.45 lists some other further study items to be resolved in T.37, including extending Internet fax capabilities toenable Internet support of all features of Group 3 and Group 4. It also notes activities related to T.37 Internet faxQoS issues in IETF Qualdocs and IEEE-ISTO PWG (see below). The IFax ad hoc reviewed D.45. No action wastaken.

TD-28(1/16) (L. McIntyre, Xerox, QFax1 Rapporteur) provides information on the status of IPP Fax, previouslyknown as Qualdocs. The primary objective of IPP Fax is the enhancement of Internet fax service, relative to thatdefined in T.37. IPP Fax enhancements are targeted at increased document quality (e.g., higher resolution and color)and more timely delivery (i.e., consistent with the real-time delivery of G3 fax). The IPP Fax effort, initiated withinthe IETF , has recently moved to the Printer Working Group (PWG), an IEEE affiliated group, after it failed toachieve Working Group status within the IETF for over a year. The first PWG chartered IPP Fax meeting was heldon September 15, 2000 in Chicago Illinois, as one of the sessions within the week of PWG meetings. The secondmeeting is scheduled for the October 26 session of that weeks’ PWG meeting. TD-28(1/16) provides a summary ofresults and discussions from the first PWG IPP Fax meeting. The name change to “IPP Fax” was one of the resultsof this first meeting. No action was taken on TD-28(1/16).

D.46 (Canon, Oki Electric) proposes T.37 terminal mode based on the results of the Gaithersburg discussions. Thisamendment adds functionality to include support for the transmission and receipt of additional TIFF image formats,capabilities exchange, and acknowledgment of receipt for small memory IFAX devices. H. Tamura (Ricoh), IETFFaxWG Co-Chair, reported that IETF FaxWG is concerned that the terminal mode is incompatible with existingInternet fax RFCs and T.37. The objective of Terminal Mode is a simple protocol for ROM oriented fax devices,not for PC based E-mail clients. Terminal mode is intended to allow communication over existing emailenvironments, but it may not be able to communicate with existing email clients. It was noted that only twoJapanese manufacturers contributed to the work on terminal mode. Another concern was raised that the servicedocument, F.185, should be amended to include terminal mode in T.37. H. Tamura suggested an IETF/ITU-Tcollaboration on terminal mode work. It was agreed to send TD-65(1/16) to IETF FaxWG on the Internet faxterminal mode, including D.46, to ask if the IETF is willing to study Terminal mode further.

TD-34(1/16) is a communication from IETF FaxWG; it informs on their current activities, and responds to a requestby the previous Q4/8 on full mode. In discussion, a concern was raised that FFPIM may no longer be discussed inIETF, since draft-ietf-fax-ffpim-00.txt has been deleted from the IETF database. H. Tamura responded that he willask the author of the FFPIM draft to release a new version of the FFPIM draft to keep the discussion going in IETF;he will send a further communication on its status to ITU-T.

Another concern was expressed that Item b) in Section 2, Response on full mode, is insufficient for the ITU-Trequest; it was agreed to request additional clarification on this. Items a) and c) in Section 2 were accepted.

TD-64(1/16) (revision to TD-48(1/16)) is a communication to IETF in response to TD-34(1/16) expressing theseconcerns of the IFax ad hoc.

ADDITIONAL OUTGOING LIAISONS

TD-42(1/16) is a liaison to Q7/15 in response to the Q7/15 liaison input to the February 2000 SG8 meeting (TD-293) which informed about an issue regarding international V.34 fax performance through network echo cancelers.Q7/15 experts felt that it would be beneficial for fax and data performance to amend Recommendation G.168 (2000)to include an optional tone disabler capability that turns off the NLP on detection of a 2100Hz tone without phase



reversals and with or without amplitude modulation (ANSam). This issue was originally discussed by SG8 in theirMarch, 1999 meeting, and SG15 was asked to comment on it. In their February 2000 meeting, SG8 postponed theamendment of Recommendation T.30 to make the phase reversal mandatory to ANSam for disabling the echocanceler. This liaison notes that this issue is still open for QFax1/16; QFax1/16 asks that SG15 inform them of theconclusion of the further tests and the final decision on G.168 (2000).

TD-41(1/16) is a liaison to ISO/IEC JTC 1/SC29 WG1 (JPEG/JBIG) asking that SC29/WG1 retain the announcedschedule for Part2 approval (June 2001) so that SG16 may target development of related application standards.

QFAX2/16 WP1 (FORMER QUESTION 6/8)

WP1/16 addressed the work of former Q6/8 under the chairmanship of I. Sebestyen (Siemens, former RapporteurQ6/8). TD-44(1/16) is the agenda. TD-59(1/16) is the meeting report. TD-07(1/16) lists the work program carriedover from former SG8 to SG16.

The following draft Recommendations were for Consent under Recommendation A.8 at this meeting:

Draft ITU-T Recommendation T.800 | ISO/IEC CD15444-1, Information technology - JPEG 2000 image codingsystem - Core coding system (COM8-116).

Draft ITU-T Recommendation T.870 | ISO/IEC 14495-2, Information technology - Lossless and near-losslesscompression of continuous-tone still images: Extensions (TD-77(Plen).

Corrigendum to T.82 (JBIG-1) – Text of corrigendum of this joint text standard agreed at the Arles Meeting of JBIG(July 2000) will be submitted by the Former Rapporteur to the TSB.

TD-13(1/16) (I. Sebestyen, Siemens) gives a short status report on the current work on JPEG2000 (complete), JPEGLS Extensions (T.870) and JBIG1 (Corrigendum to T.82). SG16 approvals are necessary for the T.870 and theCorrigendum to T.82.

T.800 (JPEG 2000), FOR CONSENT

D.51 (I. Sebestyen, Siemens, Q6/8 Ex-Rapporteur) presents a compilation of the IPR status of draft JPEG2000 –Part 1 (T.800). Patent numbers are not included. This notes the complexity of the IPR associated with T.800 andlists 22 organizations including TeraLogic.

TD-15(1/16) contains a patent statement and licensing declaration on draft JPEG2000, submitted by Teralogic and itssubsidiary PicSurf, Inc. TD-15(1/16) states that TeraLogic and PicSurf may be willing to enter into negotiationswith entities that wish to obtain licenses under their patents, but, at this time, they are not undertaking anyobligation to license these patents and patent applications in connection with the JPEG2000 (Draft ITU-T T.800)standard or any other standard. Accordingly, they have attached the ITU patent form with paragraph 3 selected.

COM8-116 contains the draft Recommendation T.800 | ISO/IEC CD15444-1, Information technology - JPEG 2000image coding system - Core coding system. It was conditionally agreed to Determine this (now Consent for AAP),pending the successful resolution of the IPR problem of collecting final information and solving the 2.3 Statementfrom Teralogic (TD-15(1/16)). The text is final.

TD-62(1/16) is a liaison to ISO/IEC JTC1 SC29 WG1 JPEG addressing IPR issues around JPEG2000 Part 1 IPRstatus and asking JPEG what patent statements actually apply to the final draft T.800.

T.801 (JPEG2000 PART 2 – EXTENSIONS )

D.18 (Japan, Y. Yoshura, Canon) provides comments on JPEG2000 standardization in ISO/IEC JTC1/SC29 WG1.SG8 members read Part 1 at the February 2000, SG8 meeting in Geneva and sent a liaison to WG1 asking thatCIELab color space be adopted in Part 1. WG1 discussed this at their Tokyo meeting, and decided to adopt CIELabcolor space in Part 2; they also decided to issue additional parts in the succeeding WG1 meetings. D.18 proposesthat:



• T.801 (Part 2) be designated as required for facsimile applications because CIELab, mandatory for color facsimileapplications, is only available in JPEG2000 Part-2. This was agreed.

• ITU-T produce a Recommendation to define appropriate profiles for JPEG2000 facsimile implementation. Thiswas agreed

• A liaison be sent to SC29/WG1 to urge that WG1 keep the original standardization schedule of Part 2 to realizeJPEG2000 facsimile as early as possible. TD-41(1/16) is the liaison from QFax2/16 asking that SC29/WG1retain the announced schedule for Part 2 approval (June 2001).

COLLABORATIVE PROJECTS BETWEEN ISO/IEC JTC1 SC29 AND ITU-T

QFax2/16 decided to have as joint text standards those parts of JPEG2000 that are inherently needed to implementthe JPEG2000 standard in ITU-T systems (Part 2 – Extensions, Part 4 – Compliance and Profiles, Part 5 – SoftwareImplementation). Further parts are for study when they come along. Part 3 (Motion JPEG2000) is to by checkedby SG16.

Due to subdivision of the JPEG-2000 still image coding system, SC 29 approved the following projects forpublication as Common Texts, as a mode of cooperation with ITU-T:• JTC 1.29.10.01 (15444-1): ITU-T Rec.T.800|ISO/IEC 15444-1 “Core System”• JTC 1.29.10.02 (15444-2): ITU-T Rec.T.801|ISO/IEC 15444-2 “Extensions”• JTC 1.29.10.03 (15444-3): ITU-T Rec.T.802|ISO/IEC 15444-3 “Motion JPEG 2000”• JTC 1.29.10.04 (15444-4): ITU-T Rec.T.803|ISO/IEC 15444-4 “Conformance Testing”• JTC 1.29.10.05 (15444-5): ITU-T Rec.T.804|ISO/IEC 15444-5 “Reference Software”

T.870 (JPEG-LS-EXTENSIONS ), FOR CONSENT

TD-16(1/16) is draft Recommendation T.870 | ISO/IEC 14495-2, Information technology – Lossless and near-lossless compression of continuous-tone still images: Extensions. This text was conditionally final, pending ITUreceipt of IPR statements from Hewlett-Packard (USA), Mitsubishi Electric (Japan), Chinese University of HongKong (China), and Canon (Japan). Patent holders were kindly invited to submit their IPR statements using the jointITU/ISO form.

T.82 (JBIG-1), FOR CONSENT

Text of the Corrigendum of this joint text standard agreed at the Arles Meeting of JBIG (July 2000) will besubmitted to the TSB by I. Sebestyen (Siemens), the former Rapporteur.

FUTURE WORK

Future ISO/IEC JTC1 SC29 WG1 (JPEG/JBIG) meetings include:

2000 Dec. 3-8 New Orleans, Louisiana, USA2001 March 5-9 Singapore (co-located with WG11, SC29 Plenary)2001 July Stockholm, Sweden2001 November TBD



SG16 MEETING ROSTER, NOVEMBER 13-17, 2000, G ENEVA, SWITZERLAND

Pierre-Andre Probst, Swisscom SG16 ChairSimao Campos-Neto, LMGT SG16 Vice ChairJohn Magill, Lucent Technologies SG16 Vice ChairMitsuji Matsumoto, NTT SG16 Vice ChairFederico Tosco, CSELT SG16 Vice ChairMahmoud Wriekat, Jordan SG16 Vice Chair

Begium Alcatel Bell Jozef Vandenameele [email protected] Telindus NV Paul Aerts [email protected] Administrations Luiz F. Silva-Ferreira [email protected] Administrations Maximiliano Martinhao [email protected] Administrations Donald Mactaggart [email protected] Administrations Ian McCallum [email protected] Administrations Vesa Ruoppila [email protected] Administrations Redwan Salami [email protected] Administrations Tom Taylor [email protected] Administrations David Walker [email protected] Nortel Networks Bruce Pettitt [email protected] Nortel Networks Peter Tue [email protected] Administrations Jian Min Bao [email protected] Administrations Lin Tao Jiang [email protected] Administrations Xao Ming Li [email protected] Administrations Yu Liu [email protected] Administrations Jian Bin Wang [email protected] Administrations Yuezheng Wen [email protected] Administrations Matti Alkula [email protected] Nokia Corp. Jari Hagqvist [email protected] Nokia Corp. Miska Hannuksela [email protected] Nokia Corp. Ari Heikkinen [email protected] Nokia Corp. Antti Pitkamaki [email protected] Nokia Corp. Jaakko Sunquist [email protected] Nokia Corp. Jouko Tormanen [email protected] Tellabs Oy Jerry Skene [email protected] Administrations Daniel Battu [email protected] Administrations Jean Pierre Blin [email protected] Administrations Yves Robin-Champigneul [email protected] Administrations Claude Lamblin [email protected] France Telecom François Bougant franç[email protected] France Telecom Bruno Chatras [email protected] France Telecom Jean Claude Samou [email protected] Alcatel CIT Abdel Moulehiawy [email protected] Administrations Rolf Rüeggeberg [email protected] Deutsche Telekom Ralf-Rainer Damm [email protected] Siemens Robert Callaghan [email protected] Siemens Martin Euchner [email protected] Siemens Ernst Horvath [email protected] Siemens Karl Klaghofer [email protected] Siemens Manfred Schafer [email protected] TELES Stephen Wenger [email protected] HHI Thomas Wiegand [email protected] OTE Ioannis Stephanakis [email protected] Administrations Dipanjan Dutta [email protected]



India Administrations Ramesh Nagaraju [email protected] Administrations Roni Even [email protected] Administrations Michael Fortinsky [email protected] Administrations Ilana Leibovitch [email protected] Administrations Orit Levin orit.radvision.comIsrael Administrations Boaz Michaely [email protected] Administrations Ran Vinner [email protected] Surf Comm. Solution Yona Sivan [email protected] Administrations Roberto Flaiani [email protected] Administrations Giuseppe Rinaldo [email protected] CSELT Rosario Drogo De Iacovo [email protected] CSELT Federico Tosco [email protected] Administrations Kouichi Iida [email protected] Administrations Sakae Okubo [email protected] DDI Shigeyuki Sakazawa [email protected] NTT DoCoMo Toshiro Kawahara [email protected] NTT DoCoMo Takashi Suzuki [email protected] Canon Toru Maeda [email protected] Canon Yoshio Yoshiura [email protected] CIAJ Keiichi Hibi [email protected] Fujitsu Yasuji Ota [email protected] Matsushita Electric Ind. Yoshinori Aoki [email protected] Matsushita Electric Ind. Hiroyuki Ehara [email protected] Matsushita Electric Ind. Genzo Takagi [email protected] Matsushita Electric Ind. Tadashi YonezakiJapan Mitsubishi Electric Yushi Naito [email protected] NEC Hidenobu Harasaki [email protected] NEC Masahiro Serizawa [email protected] NTT Shinji Hayashi [email protected] NTT Naoki Kobayashi [email protected] NTT Kazunori Mano [email protected] NTT Mitsuji Matsumoto [email protected] NTT Shigeaki Sasaki [email protected] NTT Commware Yuichiro Koda [email protected] Oki Electric Industry Yasubumi Chimura [email protected] Oki Electric Industry Satoshi Minono [email protected] Ricoh Hiroshi Tamura [email protected] Toshiba Ryuji Iwazaki [email protected] Administrations Mahmoud Wriekat [email protected] Administrations Don-Whan Hyun [email protected] Administrations Hyeon-Soo Kim [email protected] Korea Telecom Che Sub Lee [email protected] ETRI Hyoung Jun Kim [email protected] ETRI Yong Soek Kim [email protected] Samsung Electronics Adam Heng Kong Li [email protected] Samsung Electronics Joeng-Hoon Park [email protected] Samsung Electronics Kook-Yeol Yoo [email protected] Administrations Lucio Adame [email protected] Tandberg Telecom Tom-Ivar Johansen [email protected] Administrations Michal Kwiatkowski [email protected] Administrations Janusz Wierzbicki [email protected] Administrations Vladimir Efimouchkine [email protected] Administrations Natalia Dobrovolskaya [email protected]



Russia Rostelecom Igor Movtchan [email protected] Administrations Enrique Berrojalviz [email protected] L.M. Ericsson Peter Bloecher [email protected] L.M. Ericsson Eric Ekudden [email protected] L.M. Ericsson Per Frojdh [email protected] L.M. Ericsson Christian Groves [email protected] L.M. Ericsson Alf Heidermark [email protected] L.M. Ericsson Gunnar Hellström [email protected] L.M. Ericsson Jan Holm [email protected] L.M. Ericsson Espen Sjaeran [email protected] Administrations Nuno Encarnacao [email protected] Swisscom Pierre-Andre Probst [email protected] Siemens Schweiz Peter Goldstein [email protected] Siemens Schweiz Patrick Rihs [email protected] Arab Rep Administrations Nabil KisrawiThailand Administrations Somyot Tanapirunthorn [email protected] Administrations Jitkree Weerapong [email protected] Administrations Tetyana Andrushko [email protected] Administrations Oleksii Savchenko [email protected] Kingdom Administrations Doreen Pechey [email protected] Kingdom Administrations William Pechey [email protected] Kingdom BT Paul Barrett [email protected] Kingdom BT Mike Nilsson [email protected] Kingdom BT Joseph Pointer [email protected] Kingdom BT Morgan Potter [email protected] Kingdom BT George Skorkowski [email protected] Kingdom BT Christopher David Wilmot [email protected] Kingdom Document Tech. Res.

Lab. EuropeAkira Atsuta [email protected]

United Kingdom Lucent Technologies Mike Buckley [email protected] Kingdom Lucent Technologies John Magill [email protected] Kingdom Motorola Simon Kang [email protected] Kingdom Motorola Sunharsana Krishnan [email protected] States Administrations Terry Anderson [email protected] States Administrations Richard Bowen [email protected] States Administrations Louis Fourie [email protected] States Administrations Robert Gilman [email protected] States Administrations Kelly Granger [email protected] States Administrations Paul Jones [email protected] States Administrations Thanos Kipreos [email protected] States Administrations Bernard Ku [email protected] States Administrations David Lindburgh [email protected] States Administrations Patrick Luthi [email protected] States Administrations Mart NurmetUnited States Administrations Stephen Perschau [email protected] States Administrations Radhika Roy [email protected] States Administrations Richard Rubin [email protected] States Administrations John Tardelli [email protected] States Administrations Gary Thom [email protected] States Administrations Vishu Viswanathan [email protected] States LMGT Simao Campos-Neto [email protected] States LMGT Suat Yeldener [email protected] States 3Com Frederick Lucas [email protected] States 3Com Michael Nicholas [email protected]



United States Analog Devices Vlad Bulavsky [email protected] States Avaya Glen Freundlich [email protected] States Brooktrout Technology James Rafferty [email protected] States Cisco Systems Loganathan Modahala [email protected] States Cisco Systems Randall Stewart [email protected] States Cisco Systems Alex Urquizo [email protected] States Compaq Rabah Hamdi [email protected] States Conexant Systems Keith T. Chu [email protected] States Conexant Systems Tom Geary [email protected] States Conexant Systems Huan-Yu Su [email protected] States Conexant Systems Jes Thyssen [email protected] States Conexant Systems Paul Wren [email protected] States ESS Technology Jordan Cookman [email protected] States ESS Technology Ping Dong [email protected] States ESS Technology Hong Yao [email protected] States Hughes Electronics Robert J. Heath [email protected] States Intel Paul K. Reddy [email protected] States Lucent Technologies Rex Coldren [email protected] States Lucent Technologies Kenneth Jones [email protected] States Lucent Technologies Sean Ramprashad [email protected] States Lucent Technologies Greg Ratta [email protected] States Lucent Technologies Clifford Sayre [email protected] States Lucent Technologies Jinguo Yu [email protected] States Microsoft Gary Sullivan [email protected] States Motorola Info. Sys. Les Brown [email protected] States Nokia Jani Lainema [email protected] States Nortel Networks François Audet [email protected] States Nortel Networks Mehul Mehta [email protected] States PC-TEL Yuri Goldstein [email protected] States PictureTel Qunshan Gu [email protected] States PictureTel George Helder [email protected] States Polycom John McCaskill [email protected] States Sonus Networks Dale Skran [email protected] States Texas Instruments Jacek Stachurski [email protected] States VTEL Joon Maeng [email protected] States Xerox Lloyd McIntyre [email protected]

TSB Fabio Bigi [email protected] Masamichi Niiya [email protected]



PARTIAL REPORT OF TR-41, TELECOMMUNICATIONS EQUIPMENTREQUIREMENTS, NOVEMBER 13 – 17, 2000, SAVANNAH, GA

TR-41.1, MULTI-L INE TELECOMMUNICATION SYSTEMS

The TR-41.1 meeting was chaired by D. Frank (Siemens) in the absence of T. Tung (Siemens, TR-41.1 chair). Inaccordance with the TIA intellectual Property Right Policy, the Chair asked if there were any Intellectual PropertyRights (IPR) disclosures; there were none.

TR-41.1/00-11-001 is the August 2000 Vancouver meeting report. TR-41.1/00-11-000D is the TR-41.1document list; it includes the May, August and November meetings.

M. Drennan will replace E. Sorensen as representative from SCC Communications.

LIAISONS

T1E1

T. Bishop (Bell Atlantic) reported that the Ground Start/Loop Start T1.401 Standard has been sent to the ANSI editorfor publication. He mentioned that it has significant changes, e.g., the only ringing frequency is 20 Hz +/- 3 Hz.T1E1.1 has started a project to revise the T1.405 DID (direct inward dialing) standard. The T1.409 E&M standardwill probably just be re-affirmed, with minimum effort spent on it.

T1E1.1 and T1E1.2 will be combined into T1E1.3 to handle all interfaces except DSL, which will be T1E1.4’sresponsibility.

ETSI/STQ/TIPHON

TR-41.1/00-11-011 (R. Hatherill, Mitel) is a report from the ETSI TC STQ #9 meeting, September 25-28,Oxford. R. Hatherill reported he was well received when he presented a proposal for an international half-channelloss plan for IP telephony (see CSR Vol. 11.9, TR-41.4 report). This loss plan had already been submitted to STQby TR-41.4 as a liaison. The proposal now is that TIA TR-41.4 will move forward in generating a North Americanhalf-channel loss standard, and that once this and the STQ standard are released, they will be presented to the ITU-Tas the basis for a proposed international standard.

PN-4505, TSB-32-A, N ORTH AMERICA CONNECTION SCENARIOS ANALYSIS

The Chair described TSB-32-A as having had considerable effort devoted to it before contributor priorities changed.Now, it is “on hold” with about 75% done, but still requiring about three more weeks of work. The chair asked forvolunteers and requested R. Britt (Nortel) to redistribute the document again. R. Britt noted that this might be aproblem because the document may still have embedded Excel links, causing its file size to be about 25 M.

PN-3673, UPDATE/REVISE TIA-464-C

TR-41.1/00-11-007 is the fourth draft of TIA-464-C, Requirements for PBX Switching Equipment.

Using the information prepared by T. Tung (Siemens, presented as Addendum 1 of TR-41.1/00-11-001), theChair reviewed the progress of work on updating of TIA-464. He noted that it is nearing completion and thatproofreading should start. A schedule for proofreading was presented (Addendum 2 of TR-41.1/00-11-001) andattendees, as listed, volunteered to proofread their respective sections. Because section 5.1 (Public access interface –analog) still needs to be updated to consider the revised T1.401 standard, it was decided that reviewing would startwith the next updated TIA-464-C draft. Reviewers also requested that their sections be available in Word so that theycould make corrections.

TR-41.1/00-11-04 is a liaison from T1E1 in response to TR-41’s request for T1E1 support for adding balancedringing to Part 68. T1E1 stated that there is consensus agreement in T1E1 that PBX OPS (Off Premise Station)balanced ringing will not harm the network. There is also consensus agreement that PBX OPS balanced ringing isnot compatible with existing network DLC (Digital Loop Carrier) systems. For this reason, there is not consensusin T1E1 to support the addition of PBX OPS balanced ringing to Part 68 of the FCC Rules. A statement thatbalanced ringing could be used for internal OPS was discussed as a possible addition to TIA-464, but no decisionwas made.

TR-41.1/00-11-08 (R. Hatherill, Mitel) presents updates to TIA-464-C sections on Definitions, Transmission,and Loss Level planning. It proposes to replace DIG with two new port designations (DAL, digital access line and



DGS, digital station [IS-810]), change the loss plan to reflect new ports, and update the loss plan tutorial based oncomments and new material. The recommendations were accepted with no discussion.

TR-41.1/00-11-09 , Update of Requirements for Analog Signaling to the Network (R. Frank, Siemens), proposeschanges to add modern wording and maintain agreement with latest draft of T1.401. D. Frank mentioned theparagraph on prohibiting DTMF sending during the public network call’s call processing state and questionedwhether this requirement is necessary considering the short processing time of modern equipment. There was noconsensus to remove this paragraph. TR-41.1 decided to:

• Eliminate the desirable maximum level of DTMF of 0 dBm and to change the maximum level to 0 dBm.• Delete “(recommended range for DTMF sending is 7 to 10 digits per second).”• Delete the DTMF power versus loop current requirement.

TR-41.1/00-11-10 (J. Pomy, Tenovis) presents editorial comments on TIA-464-C. TR-41.1 decided to:

• Change Fig. 1 to include word “ports” after “telephone,” “Public Switched Network,” and “Private Network.”• Delete “5.1.4.1.2 The PBX is assumed to be FCC-registered equipment. The telephone is assumed to be FCC-

registered and complying with EIA/TIA-470-B (Ref. 2).”• In the first sentence of “6.6 Other Impairments,” delete “with transmission rates up to and including 14,000 bits/s

(V.32 bis).”• In Tables 29 and 30 on Call Progress Signals, change “(dBm)” to “(dB)” in the “Freq. to Freq.” column.• In the figure in B2.3, change “V19 default” to “default values according G.107 (05/2000).”

TR-41.1/00-11-13 is an e-mail discussion between L. Brown (Ameritech) and T. Tung (Siemens, Chair TR-41.1) on absolute delay. Discussion concluded that the absolute delay requirement should be removed from TIA-464-C.

PN-4422, QSIG I NTEROPERABILITY TESTING

TR-41.1/00-11-03 is the ballot summary of PN-4422, to become TSB-123, North American Test Plan forMulti-Vendor QSIG Interoperability Testing. P. Melton (eOn Communications) stated that he voted but is not onthe QSIG voting list in TR-41.1/00-11-03 . TR-41.1/00-11-005 (Avaya Inc.) suggests changes to Section1.2. D. Frank (Siemens) mentioned that TR-41.1/00-11-06 , the final issue of PN-4422/TSB-123, has been sentto TIA for publication.

E911 ISSUES

TR-41.1/00-11-002 is the Project Request and Authorization Form for the revision/update of TIA-689, underPN-3836-RV1. J. Combs (Cisco) volunteered to be editor. He recommended that the NENA information shouldonly be included in TIA-689 as a pointer when it is almost complete because the NENA protocols are changing. B.Chrostowski (Iwatsu America) offered to submit the NENA model legislation and their recommended FCC Part 68changes as contributions.

TR-41.1/00-11-012 (R. Frank, Siemens) offered seven possibilities of how to proceed with this project.

1. Put a Normative pointer to the NENA document in TIA-689.2. Put an Informative pointer to the NENA document in TIA-689.3. Include the NENA 3 record format in TIA-689 (which makes the record format a standard).4. Include the NENA 3 record format in an informative annex of TIA-689 (which does not make the record format a

part of the standard).5. Write a separate TIA standard specifically to address the NENA 3 record format, and possibly include additional

details of how to do the electronic transfer.6. Include information from the NENA document that is specific to MLTS database.7. Encourage NENA to obtain ANSI certification.

In conclusion he recommends that TR-41.1 follow possibilities 2 and 6.

TR-41.1.2, VOICE QUALITY OVER IP

TR-41.1.2/00-11-001 is the TR-41.1.2 meeting agenda. TR-41.1.2/00-11-002 is the report from theAugust meeting in Vancouver. TR-41.1.2 is chaired by R. Britt (Nortel Networks). TR-41.1.2 is currently workingon draft document PN-4689, Voice Quality Recommendations for IP Telephony. PN-4689 will be published asTSB-116. R. Britt is also the editor.



TR-41.1.2/00-11-003 (R. Britt, Nortel) is the finished document, draft 6 of PN-4689 (to become TSB-116,Voice Quality Recommendations for IP Telephony). Section 1.1, Summary of voice quality recommendations forIP telephony, was reviewed in detail. New material had been added to Section 6, IP telephony voice quality analysis,in the Delay, Speech Compression, Packet Loss, Transcoding and New Loss Plan sections.

Consensus was reached to send PN-4689 out for letter ballot.

TR-41.1.2/00-11-004 and TR-41.1.2/00-11-005 are Excel files of Nortel’s NETEM1 and NETEM2(Network Edge Technology E-model Tool, TSB-116, based on ITU-T Rec. G.107), respectively. This program isprovided to the standards community by Nortel Networks to further the understanding of transmission planning. Itprovides a means of creating scenarios and catalogs. These two files contain scenarios for different sections of TSB-116.

TR-41.2, CONFORMITY ASSESSMENT

P. Adornato (Nortel Networks) is the TR-41.2 chair. TR-41.2/00-11-14 is the report of the August meeting inVancouver. No new documents were distributed. A decision was made to reduce the time allotted to TR-41.2 infuture meetings. TR-41.2 will be scheduled right after the end of the TR-41.11 meeting in Costa Mesa, California(February 19-23, 2001).

EUROPEAN UNION - CANADA MRA

Since the last TR-41.2 meeting, no new activities have occurred between Canada and EC as both parties have agreedto extend the confidence building period from June 1, 2000 to January 31, 2001 for all sectors.

EUROPEAN UNION - US MRA

The EU – US MRA (Mutual Recognition Agreement) is scheduled for implementation on December 3, 2000, andindustry is optimistic that this deadline will be met. A meeting between designation authorities took place inBrussels on October 27, 2000, to address each others’ concerns regarding designation.

The FCC is concerned over what it believes are shortcomings in the EU CAB (Conformity Assessment Body)dossiers that the FCC has been receiving for recognition purposes. The competency concerns are relative toaccreditation, CAB knowledge of the technical and administrative requirements, and the ability of the CABs toproperly interpret FCC rules. Nevertheless, the FCC believes that it may be possible to recognize a sufficientnumber of EU CABs by the December 3, 2000 MRA operational deadline.

The EU Member States are concerned about the continuing resistance of OSHA (US Occupational Safety and HealthAdministration) to allow EU Member States and accreditors to initially designate and accredit EU CABs. The EUMember States strongly object to OSHA’s compromise proposal, calling for OSHA inspectors to perform the initialinspection of EU NRTL (Nationally Recognized Testing Laboratory) CABs and allow an as yet to be determined EUaccrediting body to perform subsequent follow-up evaluations, as it violates the spirit of the MRA. However, EUmanufacturers have expressed their desire that the EU Commission implement the MRA under OSHA’s termsinitially in order to have the EMC (ElectroMagnetic Compatibility) and Telecommunications sectors fullyoperational by December 3.

R&TTE DIRECTIVE

The TCAM (ETSI’s Telecommunication Conformity Assessment and Market Surveillance Committee) has reachedconsensus on a number of R&TTE (Radio and Telecommunications Terminal Equipment Directive) implementationissues.

The R&TTE directive requires that the SDoC (Supplier’s Declaration of Conformity) be provided to the user. Thiswas not required by the previous directive, nor is it required by the EMC and safety directives. The statement in theR&TTE directive is somewhat ambiguous. During the latest TCAM meeting, it was agreed to place a shortstatement in the manual (in the language of the Member State in question as required by consumer protection laws),and a web-address indicating a page where SDoCs are stored. This is viewed as sufficient.

It was later informally agreed that the information on the web can be the contact details of a person who can send theSDoC upon request.



APEC MRA STATUS REPORT

The APEC TEL WG met during the week of Oct. 9, 2000, in Indonesia. There were 12 economies present includingAustralia, Canada, People’s Republic of China, Hong Kong China, Indonesia, Japan, Korea, the Philippines,Singapore, Chinese Taipei, Thailand, and the U.S. It was discussed that each economy can have one DesignatingAuthority, maximum two, and that an economy can only designate Conformity Assessment Bodies (CABs) in itsown economy. Finally, with regard to accreditation, it was emphasized that economies can have CABs accredited byentities outside of their own economy, e.g., Asia Pacific Laboratory Accreditation Cooperation (APLAC).

The Implementation Project Team is composed of Australian Telecommunications Industry Association (ATIA),Communications Industry Association of Japan (CIAJ), and TIA. They outlined some of the problems encounteredso far with designation, and all the challenges they present for implementation of the MRA across the region.Standards were addressed, insofar as language barriers, interpretations, and amendments pose problems for effectiveMRA implementation long-term. Further, the subsequent challenges for laboratories were addressed.

The Implementation Project Team also proposed a Designation Workshop, planned for March 12, 2001, in front ofthe next APEC TEL meeting in Canberra, Australia. Subject matter will include content of the Guides (ISO/IEC)on which the MRA is based, and requirements for designation in each economy.

Finally, the Implementation Team also released an MRA Implementation Management Guide. The Guide is asuccinct document developed to outline all the steps an economy needs to take to prepare for and eventually movetoward implementation. A copy of this document will be available on the TIA web site.

The possibility of joint meetings between APEC and the Inter American Commission on Telecommunications(CITEL) was discussed. If possible, the first joint meeting may be held in the spring/early summer of 2001 andcould possibly take place on the west coast of the U.S. More details will come after the CITEL meetings.

The Colony Park Group in Melbourne, Australia is creating the web-based MRA Management Systems (MRAMS).MRAMS will be an electronic collection point for all the information necessary to effectively support MRAimplementation, and has only recently been granted approval by the APEC Secretariat to operate as such. TheColony Park Group will soon be seeking corporate sponsors to fund the site. TIA will check in with its membersto ask about sponsorship.

There was next a brief, economy-by-economy review of Phase I implementation.

Australia – There are some CABs from which they will already accept test reports based on old/already existingarrangements. One CAB has been recognized from Singapore, one from Canada for EMC. Australia has not yetdesignated any CABs of its own.

Canada – Industry Canada has designated labs to test to Australia, Chinese Taipei, Singapore, and U.S.requirements. They have already gotten replies for recognition from Australia and Singapore. A. Kwan (IndustryCanada) foresees problems in the future in that there are regulatory systems in some economies he doesn’t knowwell. He identified a need for further understanding technical regulations, a pool of experts, and a group of expertassessors for Phase I and II. Canada has recognized three CABs from Chinese Taipei, 15 from the U.S., and onefrom Singapore.

Hong Kong – Hong Kong has recognized two labs, one from Chinese Taipei and one from Singapore. There havebeen no requests from HK labs to be designated as CABs.

Japan – There have been no designations yet because there is no legally recognized Designating Authority. Thisproblem should be reconciled by legislation, but not until late 2001 or 2002.

Korea – Korea has not yet recognized or designated any CABs.

Singapore – Singapore has designated one CAB for Australia, Canada, Hong Kong, Chinese Taipei and the U.S.They are not sure how many of these have been recognized by the other side.

Chinese Taipei – Chinese Taipei is accepting test reports under the APLAC (Asian Pacific LaboratoryAccreditation Cooperation) agreement. They will formalize these arrangements by sending a letter with the names ofthese CABs.

United States – NIST designated 103 CABS to BSMI/Chinese Taipei requirements, and 14-15 to Canadianrequirements. The FCC has recognized one or more CABs from Chinese Taipei and Singapore. As discussed abovein the EU-US MRA report, the FCC has several issues with the designation and recognition processes.



There has been very little dialogue between exporting Designating Authorities and importing RegulatoryAuthorities. There is some confusion of the roles of the Designating Authority and the Regulatory Authority. Thetext of the MRA is confusing on this point. Section 5.1 of the MRA implies the Designating Authority acceptsforeign CABs, when in fact it is the domestic Regulatory Authority that does this. This issue requires furtherattention and a possible amendment to the MRA text.

Clarification is also required among economies as to who in each economy is performing the role of the DesignatingAuthority, Regulatory Authority, Accrediting Body, and Conformity Assessment Bodies. This clarification will be apart of the MRAMS system, but would be helpful to economies to have in advance of that system going live.

APEC SCSC WORK PROJECT – 1-1SD O C FOR PCS AND PERIPHERALS: STATUS REPORT

An agreement was reached the week of October 9, 2000 by the member governments of the Asia Pacific EconomicCooperation (APEC) to work toward voluntary implementation of “One Standard-One-Test Supplier’s Declaration ofConformity” (1-1SDoC) on information technology (IT) products, initially for computers and computer peripherals,then later for other categories of information technology equipment. The agreement reached by APEC is a majorstep forward to streamline the layers of regulation that stifle trade, including duplicative national testing andcertification requirements. The program was developed by an APEC subcommittee in collaboration with ITI andLucent Technologies; the group will work with APEC members on its implementation.

CITEL MRA

A workshop highlighting the benefits, problems and experiences of implementing MRAs was held on October 30,2000 in Lima, Peru just prior to the CITEL MRA meeting. The workshop was extremely useful in bringing theexperiences of Canada and the US to CITEL for an in-depth discussion. Benefits to economies were discussed inview of the manufacturing capability of economies, including economies with significant manufacturing, emergingsmall-to-medium sized enterprises (SMEs), and economies with no manufacturing capability at all.

During the subsequent meeting of the committee working on MRAs and certification processes, Canada, ElSalvador, Peru and the US indicated a willingness to implement both phases of the MRAs. Brazil and Mexicoindicated they may wish to implement Phase I of the MRA, but were silent on Phase II. Finally, Argentina, astrong proponent of the CITEL MRA, suddenly discovered that it lacks the political will to proceed withimplementation.

J. Leuck (TIA) and S. Crosby (Lucent) will work with members of CNC (Argentina’s National Commission ofCommunications) to renew Argentina’s enthusiasm and to obtain work with local industry towards achievingBrazilian and Mexican implementation of Phase II.

NAFTA TSSC WORKSHOP

The government-to-government NAFTA Telecommunication Standards Subcommittee (TSSC) held an informativethree day workshop in Mexico City November 8-10, 2000. Most of the talks focused on the MRA experiences ofCanada and the US, including accreditation, designation, recognition, benefits to manufacturers, service providers,consumers, government and test and certification CABs, including Mexican test and certification CABs.

EMA, a rapidly growing accreditor in Mexico that has some experience accrediting to COFETEL standards, put onan impressive presentation, creating optimism among Canadian and US participants with respect to Mexico’s abilityto participate in the APEC and CITEL MRAs in the near term.

Further optimism was gained when COFETEL discussed a soon-to-be-released rule making on Mexicantelecommunications equipment certification and homologation that includes provisions for Phase I and theconformity assessment aspects of certification in Phase II, but not the final equipment authorization procedures.

DOCKET 99-216 ON DEREGULATION OF EQUIPMENT REGISTRATION AND TELEPHONE NETWORKCONNECTION RULES

At an open FCC meeting on Nov. 9, the FCC commissioners unanimously approved the Part 68 streamlining order(Docket 99-216). This culminates about 18 months of activity. TIA sub-committees TR-41.2, TR-41.9, and TR-41.11 had taken an active interest in these proceedings and in preparing comments and reply comments to the FCC.

Among the provisions of this order are the adoption of Supplier’s Declaration of Conformity (SDoC) for wirelineterminal equipment and the turning over of the upkeep and maintenance of most Part 68 terminal attachment rules toindustry Standards Development Organizations.



In the U.S., the order will allow the use of SDoC as an acceptable option to using the services of TCBs (TelecomCertification Bodies) for wireline equipment certification.

The Commission, as expected, will still control the technical rules and requirements relating to HAC (Hearing AidCompatibility) to ensure that access for persons with hearing disabilities is not compromised.

Although the actual text of the order was not immediately available, it was expected to be released by the end ofNovember.

TL9000 STATUS REPORT

No status update was available. TR-41.2 members expressed a lack of interest in future updates on this topic. SeeCSR Vol.11.4, TR-41.2 report for a description of TL9000.

DECLARENET

A number of Information Technology companies are investigating the utility of a database for use by regulators intracking supplier declaration of conformity information. A presentation on HP’s proposal, DeclareNet, had beendiscussed earlier in the week in the TR-41.11 meeting. Although TR-41.2 participants did not have specificopinions on the DeclareNet concept at this time, they were encouraged to discuss the principles within theircompanies in conjunction with approval data base, Evolution concepts.

GPCAS (GLOBAL PRODUCT CONFORMITY ASSESSMENT SYSTEM) UPDATE

GPCAS (Global Product Conformity Assessment System) is an initiative to reduce time to market for globalproducts by simplifying and harmonizing regulations around the world.

The Global Information and Communications Technologies industries, represented by trade associations inUS/Canada, Europe, Japan and Australia, have launched an initiative to promote a Global Product ConformityAssessment System (GPCAS) for the future. A GPCAS green paper defines principles to simplify and harmonizeconformity assessment procedures and requirements. This approach will reduce time to market for new globalproducts such as telecommunications terminal equipment and radio apparatus. GPCAS advocates the use ofSuppliers Declarations of Conformity without mandatory third party involvement. The paper has wide industrysupport and is formally supported by 12 associations worldwide.

Representatives from EICTA, ITI, TIA, CIAJ and EIAJ participated in a workshop October 12-13 hosted by theFederation of Electronic Industries (FEI) in London. The workshop’s aim was to produce a Road Map of changesneeded to achieve GPCAS. A number of individual objectives were identified. Named organizations and individualsagreed to drive these objectives over time frames from months up to five years. It is recognized that to cover allregions of the world, the program could take 10 years. A Communication Plan to promote GPCAS at theinternational level was also agreed. The GPCAS Green Paper was presented in a special session during theworkshop to representatives of EU Members States; the initial feedback from informal discussions is that theprinciples are generally supported by them.

The GPCAS green paper is available from the EICTA (European Information and Communications TechnologyIndustry Association) web site under EICTA Positions: <http://www.eicta.org/Content/Default.asp?PageID=100>

TIA WIRELESS REGULATORY COMMITTEE

It was reported that the last meeting of the TRIC (TIA Regulatory Issues Committee) took place in Maryland onOct. 17, 2000. Topics addressed included the status of standards activities for SAR (Specific Absorption Rate)requirements, changes and streamlining of various parts of the Code of Federal Regulations dealing with Wirelessequipment, and an update on the process for certification for Bluetooth appliances. The next meeting will be heldJan. 17, 2001.

TR-41.3, ANALOG AND DIGITAL WIRELINE TERMINALS

The TR-41.3 report and the report of its working groups (other than TR-41.3.5, below) will be published in January,2001.



TR-41.3.5, REVISION OF TIA-470-B

The Chair of TR-41.3.5 is D. McKinnon (AST Technology Labs). TR-41.3.5/00-11-047 is the meetingagenda. TIA-470-B is titled Telecommunications – telephone terminal equipment – performance and compatibilityrequirements for telephone sets with loop signaling.

TR-41.3.5/00-11-051 (same as T1E1.1/2000-013R3) is the draft proposed revision of the T1E1 interfacestandard for Switched Access Lines with Distinctive Ringing Features (T1.401.02-2000); it contains the text andtables from T1E1.1/2000-013R2 with several editorial changes made as a result of comments associated with T1 LB860.

TR-41.3.5/00-11-052 is Comment Resolution Status Report for Default T1 LB 860, Draft Proposed Revisionto T1.401.02-1995 -Network to Customer Installation Interfaces – Analog Voicegrade Switched Access Lines withDistinctive Ringing Features. Lucent had voted no with comments and Marconi had voted yes with comments. Allletter ballot comments were addressed and no substantive changes were made to the draft standard. T1E1.1/2000-013R3 was recommended for publication by ATIS.

TR-41.3.5/00-11-053 is Comment Resolution Status Report for Default T1 LB 848, Draft Proposed Revisionto T1.401-1993 -Network to Customer Installation Interfaces – Analog Voicegrade Switched Access Lines UsingLoop-Start and Ground-Start Signaling.

Bell Atlantic, Marconi and Siemens provided comments on the default ballot. The editor (F. Fainaru, Nortel) willmake the changes approved by the working group as a result of default letter ballot comments and will issue a finalversion of the document as T1E1.1/2000-007R3.

HANDSET ACOUSTICS

TR-41.3.5/00-11-050 is Draft 01 of PN-4350-110, Handset Acoustic Performance Requirements for AnalogTerminal Equipment Connected to the Public Switched Telephone Network, dated October 30, 2000, to become Partof ANSI/TIA/EIA-470.100-C. The editor of the Handset Acoustics Document is K. Macdonald (Microtronix).

TR-41.3.5/00-11-054 , TX & RX linearity test levels (D. McKinnon, AST Tech Labs), proposes test levels andrequirements for TX (transmit) and RX (Receive) linearity testing. TR-41.3.5 agreed to include it in the next draft,with some changes.

TR-41.3.5/00-11-056 (R. Carey, RadioShack) compares of OLR data to LR (and STMR, Sidetone MaskingRating) data. The TR-41.3.5 working group plans to change acoustic requirements from OLRs to LRs. RadioShackpulled data on twelve products in order to study the correlation between OLR and LR. TR-41.3.5 agreed that it wasnecessary for a few other companies to test products for OLR (Overall Loudness Rating) and LR (Loudness Rating)data to use for the final determination of 0, 2.7, 4.6 km LR limits.

It has already been decided that the revised IEEE 269 and TIA 470.110-C will use ITU-T P.79 loudness ratings. Inthe past the IEEE-661 Objective Loudness Ratings were used. There have been studies on approximate, ‘rule-of-thumb’ conversions between these different loudness ratings. TR-41.3.5/00-11-059 , LR-Calculation Comments(K Macdonald, Microtronix), makes preliminary comments and clarifications on issues in the calculation of P.79loudness ratings and the loudness rating limits specified in TIA-470.110-C.

TR-41.3.5/00-11-057 , Parallel Load Circuit Proposal (K Macdonald, Microtronix; D. Stenner, Advent Inst.),proposes a parallel load circuit for simulating an off-hook telephone with worst case DC loading characteristics, andnominal AC loading characteristics. This circuit would be used to simulate the loading effect of a second phonegoing off hook. It was agreed to include it in the next draft of TIA-470-C.

TR-41.3.5/00-11-058 , Sidetone Frequency Response (R Carey, RadioShack), provides a recommendation forSidetone frequency response, as was requested at the August meeting. After much discussion it was decided that thisrequirements would not be included in the document.

ALERTER RESPONSE AND ACOUSTIC OUTPUT

TR-41.3.5/00-11-048 is Draft 00 of PN-4350-230, Analog Terminals Core Performance Requirements forAlerter Response and Acoustic Output, dated October 25, 2000. The editor of the Alerter Response and AcousticOutput Document is R. Magnuson (Siemens). Draft 00 was reviewed with applicable updates and several actionitem notations recorded by editor.



TR-41.3.5/00-11-055 , Proposal for Distinctive Alerting and Alerting Response (D. McKinnon, AST TechLabs), notes that a few issues need to be looked at for alerter response:

1) Delay from the application of the ringing signal to the ring signal qualification2) Delay from qualification to acoustic alerter output3) The acoustic replication pattern tolerance to the applied ringing signal pattern at T&R

TR-41.3.5/00-11-055 proposes a response to ring signals and reproduction of distinctive ringing patternsrequirements to the application of the ring signal at T&R. D. McKinnon agreed to revise this contribution based ondiscussion.

It was also agreed to send a liaison letter on clarification of Automatic Line testing voltages to T1E1.

RESISTANCE AND IMPEDANCE

TR-41.3.5/00-11-049 is Draft 00 of PN-4350-210, Analog Terminals Core Performance Requirements forResistance and Impedance Requirements, dated October 25, 2000. The editor of the Resistance and ImpedanceDocument is R. Carey (RadioShack). This draft was reviewed, with applicable updates and several action itemnotations recorded by editor.

Don McKinnon, AST Technology Labs Inc.

TR-41.4, VOIP GATEWAYS AND INFRASTRUCTURES

The TR-41.4 report will be published in January, 2001.

TR-41.5, MULTIMEDIA-BUILDING DISTRIBUTION SYSTEMS

TR-41.5 did not meet. The ballot for SP-4657, A Full Duplex Ethernet Physical Layer Specification for 1000 Mb/s(1000 Base-TX) Operating over Category 6 Balanced Twisted Pair Cabling (to become TIA-854), was set to close onOctober 27, 2000; the vote was: 7 approve, 0 no votes, and 2 abstains. Included in the 7 approve were 4 withcomments. T. Cobb (Lucent) sent the comments via e-mail to all who voted, along with a proposed commentresolution. A conference call was held on Thursday November 16. Since the ANSI ballot does not close untilDecember 19, the conference call was unable to resolve all comments.

TR-41.7, ENVIRONMENTAL AND SAFETY CONSIDERATIONS

The TR-41.7 report and the report of its working groups will be published in January, 2001.

TR-41.9, FCC TECHNICAL REGULATORY CONSIDERATIONS

A. Wride (CCL) is the chair of TR-41.9. She asked members to identify if there was knowledge of patents, the useof which might be essential to the standard being considered. None was identified. TR-41.9/00-11-055 , themeeting notes from the August meeting, were approved with minor changes.

S. Roleson (HP) provided a summary of his Web Report, TR-41.9/00-11-061 , which provides web resources andlinks of interest to TR-41.9. It is also available at <http://home.pacbell.net/sroleson>.

T. Caggiano (Lucent) listed and discussed a number of committees that have activity relating to telephony regulatoryissues (see also CSR SG16 Q1 report):

• IETF ENUM proposal for new top level domain: .tel to be used to make telephone numbers into a url• CALEA (Communications Assistance for Law Enforcement Act)• Public Safety Partnership Project (ETSI and TIA)• Location Interoperability Forum new international group• Emerging IETF IEPS (International Emergency Preparedness Scheme)

He noted the merger of MMTA and TIA. The MMTA Government Affairs Committee may evolve into a placewhere these regulatory issues can be considered. He felt that TR-41.9 could be a place to gather additional moretechnical information on these efforts. S. Roleson (HP) will conduct research through the Internet on the variousorganizations.



TR-41.9/00-11-066 , Proposed Amendments to Part 15 Definitions (R. Davis, D. Beckwith, Mitel), proposeschanges to Part 15 definitions to address the differentiation of commercial application of PC Peripherals. CurrentlyPart 15.101 provides:

Equipment authorization of unintentional radiators (a) Except as otherwise exempted in §§ 15.23, 15.103, and15.113, unintentional radiators shall be authorized prior to the initiation of marketing, as follows:Class B personal computers and peripherals - Declaration of Conformity or Certification 1Other Class B digital devices and peripherals - Verification

There were some discussions concerning definition of Peripherals, Class A, Class B, LANs and hubs, differencesbetween Certification, Verification, and DOC. It was agreed that this issue can better be addressed in other forumssuch as the TIA working group on wireless issues; IEEE C63, electromagnetic compatibility, chaired by D.Heirman, can also be contacted.

G. Slingerland (Mitel) reported that TR-41.11 closed out the labeling and database issues. Issues related to IPtelephones were discussed and a meeting is scheduled to continue with the discussion. The Application Guide, Rev.3, will be issued shortly.

TAPAC, TAPAC TTF, TAPAC ATF LIAISON

H. Mar (Industry Canada) report on TAPAC and its Task Forces. They last met October 26-27, 2000 in Ottawa.The letter ballot on SDSL as provisional requirements was approved. The proposed provisional document will bepublished after translation. Another letter ballot for inclusion of HDSL2 by amendment to Part VIII of CS-03 wasalso approved. An amendment 4 to CS-03 will be published after translation.

There have been no activities between Canada and EC since both parties have agreed to extend the confidencebuilding period from June 1, 2000 to January 31, 2001 for all the sectors.

Canada participated in the workshop on conformity assessment process and rules November 8-10, 2000 in MexicoCity.

Industry Canada has been coping with considerable delays in approving the Telecom Regulations, mostly due to theunavailability of IC’s legal counsel. The change in Ministers and the current federal election are expected to add tothese delays. IC’s best guess for the timing for this is the first quarter of 2001.

The APEC MRA task force met three weeks ago. The next meeting will be the week of March 9, 2000 in Canberra,Australia. Participating economies are creating an unofficial list of experts on their economies. They will makethis list available to accreditation bodies if those bodies have difficulty finding expertise on foreign requirements. Atpresent, nine economies, including Canada, are participating in Phase I of the APEC MRA.

Colony Park (an Australian company) is creating an advertising supported database called MRAMS (MRAManagement System) that will collect information on the requirements of the participating APEC economies,products that have been certified, and so on. This database will become operational once enough sponsors have beenfound; it is available at <http://www.mrams.com>.

The next meeting of TAPAC will take place on Feb. 15, 2001. The meeting of its task forces will be held Feb. 14,2000.

TCB COUNCIL ACTIVITIES

A. Wride (CCL) reported on the TCB Council activities. On September 29, 2000, the FCC issued a public noticestating that the FCC will no longer accept equipment authorization applications for class B computers andperipherals. These devices may be approved using either a declaration of conformity or certification by aTelecommunication Certification Body (TCB). See DA 00-2224.

The next meeting of the TCB Council is scheduled for November 29, 2000, in Washington, DC. TR-41.9/00-11-063 is their agenda. Current items of interest to TR-41.9 include:

1. RF Exposure Requirements and the limitations placed on TCBs. The FCC is currently working on proceduresfor testing and approving products subject to RF Exposure requirements. Until these procedures are released,TCBs are excluded from approving equipment subject to these requirements.



2. Cooperation between the TCB Council and the R&TTE CA. The R&TTE CA is an organization primarilyconsisting of European based companies, including European Conformity Assessment Bodies. The US-EU MRAis set to permit the designation of TCBs in Europe starting December 3, 2000.

3. Explore ways to facilitate communication between the FCC and TCBs to assure consistency in the program.

FCC/IC ACTIONS

J. Vu (FCC) left the room for the discussion of FCC/IC actions.

Part 68 Streamlining Report and Order

TR-41.9/00-11-057 is a letter from TIA to the FCC noting TIA’s support of an independent “Council forTerminal Attachment” (CTA), as was stated in TIA’s Comments (June 23, 2000) and reply comments (July 7,2000). If this approach is not acceptable to the FCC, then TIA remains willing to become the gatekeeper SDO.

TR-41.9/00-11-064 is a copy of the November 9, 2000 FCC News Release on P68 Streamlining, “FCCPrivatizes Standards-Setting And Certification Process For Telephone Equipment.”

There was a lengthy discussion concerning these contributions. Two major items were: (1) the privatization of Part68, and (2) the functions of the Standard Development Organization. There will need to be cooperation betweenorganizations; TR-41.9, specifically, will need to combine the committee’s strength with an administrator in aneffort to assist the FCC in the streamlining process. There were suggestions that TR-41.9 must continue with thedevelopment work on the requirements for new technologies. There is a lot of speculation and many memberssuggested waiting for the actual Order from the FCC that is expected to be released at the end of the month. At thattime, TR-41.9 might have to schedule an interim meeting to further discuss this issue.

FCC PN on Multiple Manufacturing Sites

TR-41.9/00-11-058 is an FCC Public Notice dated October 6, 2000, “Network Services Division, CommonCarrier Bureau, Increases Convenience And Lowers Cost For Part 68 Applications.” A. Wride provided a summary.The Commission will henceforth accept applications for Part 68 Certification for multiple factories on a singleForm 730, even if the factories are located in different countries. Information on the quality assurance program(Form 730 exhibits G1 & G2) can be based on the first manufacturer listed on the attachment of Form 730.

Peti t ion on HAC Issues for Wireless Phones

The standard to measure hearing aid immunity and interference of digital wireless telephones from IEEE committeeC63.9 has been balloted. It is a joined document between industry groups and manufacturers. The document is verycomplex and requires a high level of expertise to comprehend. Two main problems were identified: magnetic fieldaround the phones, and microphones sending out bursts which could create interference across the spectrum.

TR-41.9/00-11-059 is a petition on HAC (Hearing Aid Compatibility) issues for wireless phones dated October7, 2000 from multiple organizations that support the hearing impaired.

TR-41.9/00-11-065©, draft document ANSI C6319, Compatibility for wireless products with HA (IEEE), will beadded to C63.9, and the chair will upload this to the web. Draft ANSI C6319 sets forth uniform methods ofmeasurement and parametric requirements for the electromagnetic and operational compatibility and accessibility ofhearing aids used with wireless communications devices (WD), operating in the range of 800 MHz to 3 GHz.However, the current version is focused on existing services, which are in common use. Accordingly, in thisversion tests are provided for services in the 800 - 950 MHz and 1.6 - 2.0 GHz frequency bands. Future versionsmay add tests for the 2.4 GHz or other frequency bands, as they come into more common use.

FCC RULE CHANGES

FCC Part 2 Changes

i) ET Docket No. 99–255; PR Docket No. 92– 235; FCC 00–211 - (Wireless Medical Telemetry Service)Changes to Part 2, Subpart BChanges to Part 2, Subpart J

ii) ET Docket No. 95–18; FCC 00–233 - (Allocation of Spectrum at 2 GHz for Use by the Mobile-SatelliteService)Changes to Part 2, Subpart B



iii) IB Docket No. 98–172; FCC–00–212 – (Redesignation of the 18 GHz Frequency Band, Blanket Licensing ofSatellite Earth Stations in the Ka-band, and the Allocation of Additional Spectrum for Broadcast Satellite-Service Use)Changes to Part 2, Subpart B

iv) DA 00-2204 – (Change of Address for Federal Communications Commission’s Headquarters)Changes to Part 2, Subpart J

FCC New Part 7

TR-41.9/00-11-056 is the FCC Public notice on disabilities (DA-002162). Reminder to manufacturers andproviders of voice mail and interactive menu products and services of their accessibility obligations under new part 7of the commission’s rules. S. Roleson (HP) provided a summary. Part 6 deals with CPE and Part 7 deals withnetwork equipment.

FCC Part 15 Changes

i) DA 00-2204 – (Change of Address for Federal Communications Commission’s Headquarters)Changes to Part 15, Subpart A

ii) ET Docket No. 99–255; PR Docket No. 92– 235; FCC 00–211 – (Wireless Medical Telemetry Service)Changes to Part 15, Subpart A

iii) ET Docket 99–231; FCC 00–312 – (Spread Spectrum Devices)Changes to Part 15, Subpart C

iv) ET Docket 99–254; FCC 00–259 – (Closed Captioning Requirements for Digital Television Receivers)Changes to Part 15, Subpart B

FCC Part 24 Changes

i) WT Docket No. 95–157, RM–8643; FCC 00– 123 – (Amendment of the Commission’s Rules Regarding aPlan for Sharing the Costs of Microwave Relocation; Petitions for Reconsideration)Changes to Part 24, Subpart E

ii) WT Docket No. 97–82; FCC 00–313 – (Installment Payment Financing for Personal CommunicationsServices (PCS) Licensees)Changes to Part 24, Subpart EChanges to Part 24, Subpart HChanges to Part 24, Subpart I

Part 68 Changes

TR-41.9 will continue to monitor Part 68 activities.

FCC PART 68 ISSUES

In a contribution to the August TR-41.9 meeting, TR-41.9/00-08-038 (C. Chamney, Sprint) discussed on-hookimpedance issues with cordless phones. At that meeting, it was agreed to place this contribution as an FAQ; A.Wride (CCL) noted that the FAQ on issues for cordless phones has now been uploaded to TIA FAQ site.

There are no changes in the TSB-31-B Errata list since the last meeting.

B. Corey (Industry Canada) indicated that there are no additional items under the “Part 68 Obsolete Requirements”ongoing agenda item.

TR-41.9/00-11-060 (Mitel) is a surge proposal. It proposes change to the continuing compliance requirementsin the Part 68 Guide to exempt PBX interfaces designed and registered prior to June 1998 from Part 68.302 (c) TypeB surge requirements during continuing compliance testing. G. Slingerland (Mitel) provided a brief summary, asthis issue was covered in TR-41.11. The issue here focuses on PBX, key systems, and the requirements, testing, andre-testing of these products. There will be revisions to the Application Guide shortly.

DSL WORKING GROUPS

P. Walsh (Paradyne) reported on WG1. WG1’s mission is to develop test methods for xDSL consistent with theAlcatel Order. It is anticipated that there will be other xDSL products coming to the market in the near future and



TR-41.9’s work will help all parties involved. The group is gathering test procedures and will develop astandardized procedure to assist members in applying consistent methods.

J. Carlo (Texas Instruments) reported on WG2; C. Wellborn (Adtran) reported on WG3. WG2 will focus on how therequirements can be folded into Part 68 and WG3 will focus on Waivers Process applying to other xDSL products.It was mentioned that this process may change under the privatization of Part 68.

TR-41.9/00-11-062 , xDSL Matrix for Streamlined Waiver Process (C. Wellborn, Adtran; P. Walsh, Paradyne; J.Carlo, Texas Instruments), is designed to be a tool for the FCC when evaluating DSL equipment waiver requests.This matrix contains specific clause requirements, which will assist in the streamlined waiver process for DSLequipment.

The Commission wants to create a roadmap to establish requirements for xDSL and has requested TR-41.9’sassistance. Many manufacturers supported this since the Waiver Process takes months before products can beapproved to be marketed. (It took Paradyne nine months, and Nortel six months going through the process forwaiver for their DSL equipment.) The matrix is intended to be a high level roadmap, and its objective is to identifyapplicable tests in place of Section 68.308 and to point to other existing referenced standards. J. Carlo (TexasInstruments) presented the main points on the matrix. Discussion of various aspects followed at length.

The issue of TR-41.9 taking the lead in the development of test diagrams and incorporating xDSL test methods intoTSB-31 revision C was discussed. The present T1E1 standard only includes simple diagrams. There is a need tohave consistent, detailed test methods and diagrams. TR-41.9 is the most appropriate group to take on this tasksince its members possess a depth testing knowledge and it has support from many test labs.

It was also noted that Industry Canada has already established test procedures for ADSL, HDSL2, SDSL; WorkingGroups were requested to review and incorporate some of the requirements into US requirements.

Members of TR-41. 9 met with T1E1.4, presented the information in TR-41.9/00-11-062 , and informed T1E1.4of the upcoming FCC Order on Part 68 Streamlining and the aspect of privatization of Part 68. The questions raisedin TR-41.9/00-11-062 were discussed but there was no clear conclusion. There were differing opinionsconcerning the application of the SM (Spectrum Management) Standard. Some members felt that if SM masks arerequired, then SM should be the main referenced standard; however, if issues concerning network harm andinteroperability are involved, then the application of other referenced standards might be more appropriate. Othersfelt that the SM document should also cover network harm requirements. The SM document’s Method B and looplength restrictions were also discussed. If a manufacturer does not meet a specified mask or class, he can conduct aseries of calculations based on Method B, and assess the spectrum to see how his equipment affects other systems. Itwas noted that this is a very involved process and should be scrutinized by industry experts since the results couldaffect other network equipment. Consideration of an analysis from an independent Third Party and working with theTCB was mentioned.

P. Walsh (Paradyne) reported on the DSL test method WG. This WG is gathering test methods and will share thesewith members once they become available. The main idea here is to develop consistent test procedures and topresent them in a similar format as in TSB-31-B. The option to place the procedures in the Application Guide wasalso suggested. It was noted that the EUT should be able to transmit continuously without its companion device.

ANSI PART 68 WORKING GROUP

P. Adornato (Nortel Networks) reported on the ANSI (privatized) Part 68 Working Group. There are 19 participantsin the ANSI Part 68 Working Group. Preliminary work in the ANSI Part 68 Working Group was discussed,pending the release of the FCC Report and Order on CC Docket 99-216 (streamlining Part 68).

The WG had a lengthy discussion on its role and deliverables. The Chair of this working group will be P. Havens(Teccor). An editorial group was formed, consisting of J. Shinn, S. Bipes and C. Chamney. (Chair’s note: theeditorial group was formed after the meeting; the chair of the working group was also designated after the meeting.)The group anticipated having a first draft by January 15, 2001. For this draft, the WG will review ANSI guidelinesand conduct editorial revisions only. No substantive changes are to be made in the first draft.

Anh T. Wride, Director of Engineering, CCL



TR-41.10, PRIVATE ISDN ISSUES

The TR-41.10 chair is M. Zonoun (Nortel Networks). TR-41.10 did not meet. They are conducting their work viaemail and meet only when required to resolve issues.

TR-41.11, FCC REGULATORY ADMINISTRATIVE CONSIDERATIONS

The TR-41.11 report will be published in January, 2000.

TR-41 PARTIAL MEETING ROSTER, NOVEMBER 13 – 17, 2000, S AVANNAH, GA

Steve Whitesell, VTech Innovations Chair, TR-41Tailey Tung, Siemens Chair TR-41.1Pierre Adornato, Nortel Chair TR-41.2Jim Bress, AST Technology Chair TR-41.3Bob Bell, Cisco Chair TR-41.4Jim Romlein, MIS Labs Chair TR-41.5Steven Bipes, Mobile Engineering Chair TR-41.7Anh Wride, CCL Chair TR-41.9Mo Zonoun, Nortel Chair TR-41.10Greg Slingerland, Mitel Chair TR-41.11

ADC Juha Junkkarinen [email protected] Larry Bell [email protected] Chris Wellborn, [email protected] Canada Tuan La [email protected] USA, Inc. Clint Pinkham [email protected] Anh Wride [email protected] Systems Tim Lawler [email protected] Walter Overcash [email protected] Ajmer Bal [email protected] Telecom William Buckleyeon Communications Corp. Peter Melton [email protected] Inc. Berndt Martenson [email protected] Inc. Roger Liu [email protected] Inc. Per Dofnas [email protected] John Vu [email protected] Scott Roleson [email protected] Canada Gerry Briggs [email protected] Canada Henry Mar [email protected] Canada Robert Corey [email protected] Debra Jackson Shannon [email protected] John Roman [email protected] Gary Flom [email protected] Technologies Steve Crosby [email protected] Greg Slingerland [email protected] Engineering John Bipes [email protected] Engineering Steve Bipes [email protected] America Patricia Von Preysing [email protected] John Shinn [email protected] Networks Pierre Adornato [email protected] Peter Walsh [email protected] Al Martin [email protected] ICN-CD William Kammer [email protected] Richard Frank [email protected] Ron Magnuson [email protected] Cliff Chamney [email protected]



Teccor Electronics Phillip Havens [email protected] Jon Balinski [email protected] Instruments, Inc Jim Carlo [email protected] Anh Nguyen [email protected] Innovations Steve Whitesell [email protected]

REPORT OF ETSI TM6 #20, ACCESS TRANSMISSION SYSTEMS ONMETALLIC CABLES, NOVEMBER 27 – DECEMBER 1, 2000,

MONTEREY, CA USAH. Frizlen (ETSI) chaired his final TM6 meeting; M. Gindel (Telekom Austria) will succeed as Chair. TD-00contains the document list and abstracts. TD-01 is the meeting agenda.

The following delegates were appointed to serve TM6:

• S. Schmoll (Alcatel), Rapporteur for work item TM-06011 (SDSL parts 1 and 2), with M. Kimpe (Adtran) asEditorial Assistant.

• L. Magnone (CSELT, Telecom Italia group), the present Rapporteur for work item TM-06006 (ADSL), will stepdown at the end of this year. R. Jonsson (Conexant) was appointed Rapporteur for ADSL. (Reporter’s note:Some attendees would have preferred an operator in that position.)

• B. Waring (a consultant for Lucent Technologies EMEA BV), Rapporteur for work item DTS/TM-06003-2(VDSL Transceiver requirements), with N. Quarmby (Texas Instruments) as Editorial Assistant.

• A. Profumo (Italtel S.P.A.), Rapporteur for RTS/TM-06012 (B-ISDN Access), and also responsible for thecoordination of the ANAI group. G. Philpott (Marconi Communications) acts as Editor for the SDSL TC sub-layer work for this work item.

• R. van den Brink (KPN) Rapporteur for DTR/TM-06016, a Technical Report on Spectral Management.• I. Volkening (Infineon), Rapporteur for DTR/TM-06021, Requirements for the support of Voice over DSL. This

work item will be managed by A. Profumo in the ANAI group.• K. Starnberger (Infineon), Rapporteur for DTR/TM-06024, Report on additional band plan(s) for VDSL.• B. Dugerdil (Motorola) serves as liaison officer between TM6 and the DSL Forum.• It was agreed that liaisons to ITU-T SG15 will be made in the name of ETSI by delegates nominated on an ad hoc

basis; J. Boström (Ericsson) will be responsible for TM6 liaisons at the next Q4/15 meeting.• M. Gindel (Telekom Austria) cannot continue as liaison officer to TC AT now that he is Chair of TM-6. A.

Ehre (CETECOM) will arrange liaison through his company for the next meeting; P. Golden (LEA) will takeover as liaison officer to TC AT after that.

• J. Quillici (Level One Communications, now Intel), the previous liaison officer from TM6 to ANSI T1E1.4, isno longer able to attend TM6; J. Osude (Cisco) will no longer serve as liaison officer between ERM EMC andTM6.

• BT delegates will act as liaison between TM6 and FSAN.• B Mattsson is the ETSI Technical Support Officer; V. Gray is Support Assistant for TM6.

The Chair asked if anyone had any essential IPR to declare; no responses were received.

TD-15 (B. Mattsson, ETSI TB Officer), lists the TM6 work items that have the status 0 – 11 (work items that are ina drafting status). TD-28 (B. Mattsson, ETSI TB Officer) lists the TM6 work items that have the status 0 – 12(published work items).

TD-12 (H. Frizlen, TB Chair) contains a historical summary of the work of TM6 and TM3/RG12. At the close ofhis chairmanship, the departing Chair offers this view of more than eleven years of TM6 work.

At the meeting’s end, the symbolic flame of the TM6 chairmanship was passed from H. Frizlen to M. Gindel(Telekom Austria).

ETSI ISSUES

A TM meeting (including TMCC) was held October 5-6, 2000 in Sophia Antipolis, France. There were no issuesof interest to TM6 at the TMCC, other than the handling of vote on VDSL part 2 transceiver requirements, which isnow complete with 82% of the votes in favor of approving the draft TS 101 270-2 (DTS/TM-06003-2, VDSLTransceiver requirements). As a result, TS 101 270-2 will be published; TM6 will add editorial amendments to thetext before final publishing, based on the received comments.



TD-27 (B. Mattsson, ETSI TB Officer) clarifies ETSI’s position on unbundling of the local loop. In the Septembermeeting, TM6 discussed the issue of metallic testing at the DSLAM (TD-29; R. Williamson, Nortel Networks);various scenarios for the unbundling of the local loop were discussed, and the question of ETSI’s position on thiswas raised. The answer is that ETSI has no specific position on this issue. The unbundling of the local loop is aregulatory matter, and ETSI usually does not take a position in such matters.

TD-29 (B. Mattsson, ETSI TB Officer) is a proposal submitted to the General Assembly (GA) by UK DTI for theestablishment of a Regulatory Competence Center to provide support for regulatory activities within ETSI. Theformation of a dedicated resource to support the regulatory activities would demonstrate ETSI’s support for the publicpolicy aspects of its work and provide a valuable interface between ETSI and the EC and EFTA. ETSI GA hasdiscussed the matter but has not reached any conclusion.

REPORT FROM ETSI TC ERM AND THE CENELEC/ETSI JWG

The 12th meeting of ETSI TC Electromagnetic compatibility and radio spectrum matters (ERM) took place in ETSIheadquarters, Sophia Antipolis, France, November 6-10, 2000. To fully address EMC issues related to conductedtransmission networks, a third task group (TG 3) was established to develop an EMC specification fortelecommunication networks and installations. It was agreed that this EMC specification should contain as aminimum a European-wide agreed method of measurement for disturbing emissions from such installations formeasurements under in situ conditions. Proposals were put forward that the EMC specification should also include aset of European-wide agreeable limits for unwanted radiation from telecommunication networks and installations, butno consensus on this was reached. The subject remains open for further discussion in TG 3. The next meeting ofCENELEC/ETSI JWG on EMC for conducted transmission networks is scheduled for February 16, 2001, inBrussels.

REPORT FROM ETSI TC SPAN

TC SPAN has been reorganized: WG 13, Peer-to-peer control protocols (PTPCP), is being temporarily chaired by I.Spiers (Marconi). Its work program is the merger of all the work from SPAN 1, SPAN 5, and SPAN 9, plusDynamic Synchronous Transfer Mode related work from the former SPAN 8. Work item DEG/SPAN-130111(Mixed bearer services over SDSL) has been kept alive by the liaison received from ETSI TM6 (CSR Vol. 11.6TM6, SDSL, Narrow band services ). The SPAN13 Chair will contact the TM6 Chair to discuss the possibility of ajoint meeting of the two groups. WG 15, Access terminals, is reserved for the possible future integration of TCAT.

T1E1.4 REPORT

There was no official, written liaison from T1E1.4 to TM6. Various delegates made oral presentations of the currentwork in T1E1.4. The VDSL trial standards have been sent to letter ballot on schedule, and T1E1.4 has started workon HDSL4, an extension of HDSL2 supporting T1 over two pairs. The next T1E1.4 interim meeting is planned forJanuary 18, 2001 in Dallas-Fort Worth, Texas, USA. A full meeting of T1E1 and Working Groups is planned forFebruary 19-23 in Costa Mesa, California, USA.

In the future, Committee T1 will publish standards, not ANSI, which will still approve the documents. New andfuture revised standards will say “Committee T1 Standard” on the document rather than the former format with“ANSI Standard T1.xxx.”

ITU-T Q4/15 L IAISONS

TD-48 is a communication (not a formal liaison) from ITU-T Q4/15 on the use of G.994.1 for VDSL. In its recentmeeting in Bangalore (Goa), India, Q4/15 discussed the use of G.994.1 by the various VDSL specifications beingdeveloped within Q4/15, TM6, and ANSI T1E1.4. It was brought to the attention of Q4/15 that the multi-carriermode within ETSI TS 101 270-2 ( VDSL Transceiver requirements, currently out for ballot) already uses elements ofthe G.994.1 protocol, but that the signaling (tone sets) are still to be determined. Q4/15 concludes that interworkingbetween variants of VDSL that use G.994.1 should rely on the G.994.1 protocol (code points), not on G.994.1signaling (tone sets). Specifically, it was felt that a separate SPar(1) bit should be assigned to each variant ofVDSL.

Q4/15 has tentatively reserved two SPar(1) bits in Table 11.0.1/G.994.1 to be defined by ETSI TM6. Q4/15encourages TM6 to define these code points for their VDSL specifications, and to make a formal request to the ITU-T for these code point assignments according to the procedure detailed in G.994.1 Appendix IV. Q4/15 alsoencourages correspondence and cooperation between TM6 and Q4/15 on the definition of signaling (tone sets) within



G.994.1 to support VDSL. If the two groups work quickly, it may be possible to include appropriate tone sets inthe revision of G.994.1 that is up for final approval at the February 2001 SG15 meeting.

Some debate was held concerning the procedures for cooperation between Q4/15 and TM6, in the light of the recentlyagreed MoU between ITU-T and ETSI. It was agreed that, in producing liaisons to Q4/15, statements should belimited to those concerning the progress on ETSI TS and those aspects of ITU-T work where TM6 has a legitimatecase for seeking to influence Q4/15, e.g., text proposals or corrections for any European regional annex. Any otherissue should be dealt with as a company (or multi-company) contribution to Q4/15 from ITU delegates, and notunder the auspices of TM6. It should be clear that TM6 liaisons present the consensus position of TM6, and theappointed liaison officer speaks on behalf of this consensus.

The next Q4/15 meeting is planned for January 8-12, 2001 in Clearwater Beach, Florida, USA. The next ITU-TSG15 Plenary is planned for February 5-9, 2001 in Geneva, Switzerland.

REPORT FROM FSAN

FSAN has initiated FSAN Full Service-VDSL Committee (FS-VDSL); its major objective is to acceleratestandardization and implementation of an end-to-end network capability based on fiber plus VDSL (Plan 998), todeliver multiple services including video to the consumer market. Four working groups have convened to progressthe key technical areas of System Architecture, CPE, OAM, and VDSL Specification. The Rapporteur for VDSL isS. Blackwell (Centillium). The aim is to achieve significant progress toward a complete end-to-end specification in12 months, taking as a starting point the work of TM6, DSL Forum, and other key bodies. FSAN asks TM6 toconsider establishing a formal communication channel between the two groups.

ANAI

The ANAI (Access Networks Architecture and Interfaces) Rapporteur and coordinator is A. Profumo (Italtel S.p.A.).WD-15 is the report of the ANAI session. The ANAI group worked in parallel on ISDN-BA star bus and VoDSLissues, but joined the main meeting for the SDSL agenda items.

ISDN-BA S TAR CONNECTION

TD-19 (Z. Pikhart, Czech Technical University of Prague) contains supplementary information (to TD-20, Analysisof noise immunity of ISDN S-bus [M. Meninger, CTU of Prague], from the September TM6 meeting) on noiseimmunity measurements on ISDN S interface of bus and star topology for different types of NT. TD-20 confirmedresults shown in previous contributions indicating a degradation of the performances for S-bus star configurationwith respect to the proper bus configuration.

TD-21 (I. Volkening, Infineon; A. Tannhäuser, Siemens) proposes text to replace the current reference in TS 101524-2 regarding SDSL PMS-TC and TPS-TC sub-layer definitions. In the current version of SDSL (ETSI TS-101524-1 v.1.1.1, April 2000), the reference to PMS-TC and TPS-TC sublayers refers to ATM transport over DSL(ETSI TS 101 272 v.1.1.1). It was discovered in the ANAI subgroup that more services are applicable for SDSL.The transport of ATM over SDSL and Dual Bearer Mode is defined in the TM6 Living List for DTS/TM-06015,Broadband access digital section and NT functional requirements (September 2000), ETSI RTS/TM-06012,Broadband access digital section and NT functional requirements (November 1999), and G.991.2, SHDSLtransceivers (August 2000). Some applications may require a simultaneous transport of STM and ATM traffic. Inthis case, the total SDSL payload is split into nSTM B-channels for STM transport and nATM B-channels for ATMtransport. To avoid referring to a general document, the reference should point to SDSL-specific definitions.

TD-22 (I. Volkening, Infineon) contains the result of testing the noise immunity of the star configuration of theISDN S interface. In previous meetings, several results were presented (TD-20, Analysis of noise immunity ofISDN S-bus [Vienna, September 2000] and TD-34, Preliminary results on compatibility between ISDN BasicAccess equipment and the S-bus star configuration [Helsinki, May 2000]). For the measurements cables of typeDIN VDE 0815/0816, 0.6 mm diameter, Category 3 were used. These cables are used for ordinary installation.Category 5 cables were not used because the configuration should be downward compatible with existing ISDNinstallations.

The result of the basic configuration is that with the cable length of 100 m, it was impossible to activate. After thisfailure, the length was reduced to 40 m. In this configuration, the activation lasts for approximately 60 seconds.Only TE with 5 m cable length could be activated. The activation was performed from both sides. Due to thesefailures, measurements of noise immunity were not performed. TD-22 concludes that the star bus configuration is



not compliant to the described configuration; the measurements of the Czech Technical University of Prague couldnot be reproduced.

TD-39 (K. Foster, BT) presents BT’s supportive position on ISDN star configuration. CENELEC TC 215 proposesto amend EN 50098-1: 1998 (Customer premises cabling for information technology, ISDN basic access) to includea star-wired S-bus configuration. BT carried out a test program during 1999 to determine parameters for reliableoperation of a 4-port s bus hub. These tests established a set of parameters suitable for up to four terminalsconnected to the hub, and formed the basis of the BT submission to CENELEC in Autumn 1999 in their work toamend EN 50098-1: 1998. TD-39 seeks TM6 support for CENELEC TC 215, to enable TC 215 to conclude theirUnified Accelerated Procedure to amend EN 50098-1: 1998.

TD-46 (F. Cucchietti, CSELT) contains the results of the compatibility verifications made by CSELT andAETHRA, between ISDN basic access equipment currently available on the market and the S-bus star configuration;it integrates the preliminary considerations given in TD-34 from Helsinki. It concludes that the Category 3 cable isunsuitable for the proposed application, while the Category 5 cables seems to show an acceptable behavior. Theexpected reduction of the noise immunity was found, but fell well inside the minimum margins requested by thespecifications. This contribution proposes that TM6 liase back to CENELEC TC215 in a proactive way, giving notonly a verdict but also proposing amendments to the points that did show to be critical. Areas that could be amendedare: type of cable, number and length of branches, and number of terminals.

It was agreed to prepare a liaison statement to CENELEC TC 215, including the indications and the agreed TM6position. The liaison is given in Annex H to the meeting report. It indicates that it is conditionally possible toinclude the ISDN star configuration between the S-configurations, provided that:

• The cable used to implement it is of Category 5• The maximum number of branches is four• The maximum length of each branch is 100 m• The maximum number of terminals (TEs) is four• The maximum number of outlets is 12

DTS/TM-06021 (VOICE OVER DSL)

TD-30 (D. Daecke, Infineon) gives a first proposal for the scope and reference model for Access network requirementsfor the in-band support of voice and narrow band (NB) data communications over DSL (DTS/TM-06021). This waspresented for information, and as a basis for further study.

WD-07 gives the living list for the Voice over DSL work item under the ANAI group. It contains only one studypoint, which is the Table of Contents of DTS/TM-06021, Access network requirements for the support of Voiceover DSL. It was briefly reviewed; the following sub-editors were appointed:

• I. Volkening (Infineon) for ATM support• N. King (Infineon) for STM support• A. Profumo (Italtel S.p.A) for IP support

The Editor will prepare the DTS/TM-06021 living list by the end of this year and will distribute it through the TM6exploder. Study point 1, Reference configuration, was created for this meeting.

SDSL ATM TC ISSUES AND COMPLETION OF DTS/TM-06015

TD-18 (Czech Telecom) proposes a control procedure and relevant messages for dynamic time slot assignment toPSTN/ISDN channels over the SDSL frame. It was agreed to move this study point (2-4) from the DTS/TM-06015to the DTS/TM-06021 living list, as the issue is relevant to the voice and NB services support over DSL. It wasagreed not to incorporate any specific text for SDSL ATM TPS-TC in the revised document DTS/TM-06015, butsimply to include a reference to the main SDSL document. All the SDSL-relevant study points (2-1 to 2-3) will beremoved from the DTS/TM-06015 living list. The relevant text will be provided to the editor of the SDSLdocument, and incorporated into it.

Concerning the DTS/TM-06015 living list, the following was also decided:

• Study Point 1-1 was considered provisionally deleted• Study Point 1-3 (NT loopback functions at ATM layer) will be completed by the next meeting• Study Points 1-2 and 1-4 will be moved to DTS/TM-06021 living list

DTS/TM-06015 is targeted for finalization at the next meeting (TM6 #21, February 16, 2001).



TD-10 is a liaison from ITU-T Q4/15 (BI-109) in response to the TM6 liaison from the September meeting onSDSL ATM-TC EOC messages. Commenting on two of the issues raised in the TM6 liaison, it notes first that thevalues of the alpha and delta parameters currently in G.shdsl are recommended and not mandatory values. It was notclear to Q4/15 whether this is also the case in SDSL; Q4/15 proposes they be kept as recommended values. Second,it includes the latest text for EOC messages dealing with cell delineation, with changes adopted at the October Q4/15meeting in Bangalore. TM6 agreed to accept the ITU-T proposals for rationalizing ATM-TC EOC messages, ascontained in this liaison.

SDSL

The Rapporteur, S. Schmoll (Alcatel) chaired the meeting, assisted by the Editorial Assistant, M. Kimpe (Adtran).The SDSL session was held jointly with WG ANAI.

DTS/TM-06018, SDSL: MERGER OF TS 101 524 PARTS 1 AND 2

The purpose of this work item is to tidy and combine Parts 1 and 2 into one document (version 2). The scope willcombine the two parts of TS 101 524 v.1.1.1 into one document, and issues of test sequence, test loop length,number of test cases, regenerator, power back-off, RFI Ingress, and definition of TC-layer application-dependentannexes will be clarified. The draft merged document had been made available some time before this meeting aspermanent document TM6(00)10. The following TDs address further aspects of the merger.

TD-02 (M. Kimpe, Adtran) lists the proposed changes between the content of SDSL Part 1 and Part 2 and the newrevision. The complete revision is available in permanent document m00p10a2. These changes are accepted by TM6.

WD-17 gives the living list for the SDSL merged edition. The remaining study points are as follows (missingnumbers are study points agreed or deleted):

2 Definition of impulsive noise test impulse3 AM broadcast ingress RF noise generator5 Combined constellation shaping and PAR reduction6 Lifeline operation9 Warm start11 Additional optional asymmetric PSDs12 Methods for evaluating the factor for power back off14 Activation and bit rate regenerators16 Extension of test loops17 Change of requirement for return loss20 Transport of POTS over SDSL21 Power feeding values22 Investigation of common noise floor23 Network timing reference transport24 RFI Ingress modeling and testing

WD-18 gives the living list for the SDSL Edition 2. The following study points are under study:

1 Definition of impulsive noise test pulse2 AM broadcast ingress RF noise generator and general RFI issues3 Combined constellation shaping and PAR reduction4 Warm start and deactivation5 Additional optional asymmetric PSDs6 Extension of test loops7 Change of requirements for return loss8 Investigation of common noise floor9 Network timing reference transport10 Two pair transmission mode11 Microinterruptions12 Transmit power testing

POWER FEEDING

TD-45 (F. Cucchietti, CSELT) analyzes power feeding issues related to the remote power feeding of the SDSL NTU.It contains an extension to the analysis provided in TD-33 (Power feeding issues and life-line support on the SDSL



NTU [F. Cucchietti, L. Magnone, M. Infantino, CSELT; M. Giammarchi, AETHRA], Helsinki, May 200). Itevaluates the power budget available at the NTU for the life-line and SDSL transceiver operation support. It pro-vides a guideline to the specification of voice-band analog interfaces (a/b interfaces) offered to the final user by meansof adapter devices terminating various types of digital networks, such as ISDN or xDSL, taking into particular ac-count the power budget implied by the individual requirements. TD-45 references ETSI EG 201 185 (1999-02), theETSI EG 201 188 (2000-01) and one specification for the NT1+ (or intelligent NT) widely used for the ISDN net-work. It analyzes the current ETSI documents and compares them to an equivalent interface developed for an applica-tion where the power consumption is critical, e.g., the life-line service with SDSL. Although this document is ref-erencing SDSL, its results could be of interest to any xDSL equipment where life-line service is an issue.

It was proposed that a small ad hoc convene to draft text for the power feeding part; it was also agreed to create aninformative Annex which would contain most of the text of this contribution.

WD-09 is the output of this ad hoc. It contains both the proposed text to be inserted in clause 13 (Power feeding) ofthe draft, and an informative Annex. This annex provides a guideline to the specification of voice-band analoginterfaces (a/b interfaces) offered to the final user by means of adapter devices terminating various types of digitalnetworks, such as ISDN or xDSL, taking into particular account the power budget implied by the individualrequirements. It is based on TD-45 and TD-33 from the May, Helsinki meeting. Reporter’s comment: this text isto be taken with some caution; it bases the choice of parameters on approval requirements and not on actualoperating conditions.

DIFFERENCES BETWEEN SDSL AND G.S H D S L

TD-31 (M. Kimpe, Adtran) proposes resolutions to some of the differences between the ETSI SDSL and ITUG.shdsl documents. Detailed discussion of this document, as well as several resolutions led to proposed new text inthe merged edition of TS 101 524. The following “irreconcilable” differences remain between the Determinedversion of ITU-T G.shdsl and ETSI SDSL:

• 4-wire mode• Longitudinal balance lower frequency limit• Longitudinal output voltage frequency limits• Microinterruptions• Repeater operation (will appear in edition 2)

REGENERATOR-RELATED ISSUES

TD-32 (M. Kimpe, Adtran) proposes to adopt the text of Annex D and Appendix III of G.shdsl (with the propereditorial modifications) to define the operation of signal regenerators in SDSL. To achieve data transmission overgreater distances than are achievable over a single SHDSL segment, one or more SRUs may be employed. In theoptional two-pair mode, two-pair regenerators may be used when this reach extension is required. Annex D specifiesoperational characteristics of SRUs and the startup sequence for SHDSL spans containing SRUs. It was agreed toaccept the regenerator-related issues (with the four-wire option deleted).

START-UP TIME

TD-47 (M. Kimpe, Adtran) contains a future Q4/15 contribution (Unnumbered, R. Goodson, Adtran; D. Daecke,Infineon; proposed for Clearwater, January 2001). It proposes modified activation times for the lower bit rates ofG.shdsl; it seeks TM6 consensus for these proposed activation times. This was studied in an ad hoc group; theoutput text proposal is contained in WD-14r1, Pre-activation and activation timers (M. Kimpe, Adtran; Infineon).This was provisionally agreed after some editorial corrections.

TPS-TC ISSUES

TD-33 (M. Kimpe, Adtran) reproduces Annex E of G.shdsl from HC-R15R3© (Draft Rec. G.991.2 [G.shdsl]; S.Blackwell, Centillium, Editor). This Annex provides implementation details for the various types of TPS-TCframing that may be supported by SHDSL transceivers. The TPS-TC framing mode is selected during preactivation,but the criteria for selecting a particular TPS-TC mode are application-specific and are beyond the scope of thisRecommendation. It was agreed to take this contribution as the basis for the TPS-TC annex. Two applications notrelevant for ETSI were deleted; the previously agreed ETSI text was added; the remaining applications were adapted toETSI requirements.

TD-04 (J. Besseyre, GlobeSpan) asks TM6 to evaluate a proposed change in the text of Recommendation G.shdslaffecting the operation of SNMP over one port of EOC. It includes BI-028 (S. Blackwell, Centillium) from the



Q4/15 Rapporteurs October meeting in Bangalore, India, which proposes a text clarification to the RecommendationG.shdsl for SNMP support using the EOC. Q4/15 agreed to this change. After some discussion, TM6 agreed thatthey need take no action on this.

TPS TC NARROWBAND SERVICES

TD-14 (D. Decke, Infineon; A. Tannhäuser, Siemens) proposes editorial corrections to the text of the annex, TPS-TC for synchronous ISDN BRA; it resolves ambiguities and adds clarifying notes. This annex was agreed at the lastTM6 meeting (TD-27, Vienna, September 2000). In the October Q4/15 meeting, the same changes were proposedfor G.991.2 Annex E.8 - TPS-TC for synchronous ISDN BRA (BI-055, D. Daecke, Infineon; Siemens), and Q4/15agreed to them. In this meeting, TM6 accepted these changes.

TD-23 (K. Daecke, Infineon; A. Tannhäuser, Siemens) discusses TPS-TC for POTS. At the Helsinki meeting inMay, TM6 provisionally agreed on the study point: Application Annex for transporting digitized POTS channels, asallocated to the merger work item RTS/TM-06018. TD-23 revises and summarizes an earlier proposal of mappingdigitized POTS channels onto the SDSL frame (TD-16, Transport of digitized POTS voice signals over SDSLFrames [D. Daecke, Infineon; Siemens], Helsinki, May 2000), and contains a text proposal for an application-specific annex on a TPS-TC for POTS. Signaling format and protocol are TBD. It is expected that they will bebased on EN-300 324-1 and G.964.

TD-38 (A. Carrick, Ascom) describes a voice signaling alternative covering POTS, ISDN-BA and ISDN-PRAservices more comprehensive than those described in TD-14 and TD-33 (Annex E), which describe a simple mappingscheme well suited for line card extension type applications. The proposal contained in TD-38 makes use of the wellestablished V5 protocols (ETSI EN 300 324-1, EN 300 347-1, and ITU-T G.964, G.965). It is a straightforwardsolution for the typical situation where the SDSL line is terminated in a V5 access network (multi-service DSLAM);it proposes using a single 64 kbit/s communication channel to transport the relevant V5 protocols for signaling andport control/maintenance. The same principle has been used in the CCS signaling option of the ATM Forum LESstandard AF-VMOA-0145.000.

It was agreed to base the TPS-TC annex on a combination of TD-23 and TD-38, with two options:

• Z-bit signaling for small numbers of POTS channels, as proposed in TD-23• A 64 kbit/s communication channel transporting the relevant V5 protocols for larger numbers of POTS or ISDN

channels, as proposed in TD-38

Alignment of clock specifications in SDSL with ITU-T (32 PPM instead of 100 PPM), as proposed in TD-38, wasprovisionally agreed.

TD-18 (M. Meninger, Czech Telecom) presents a new idea of managing dynamic narrowband channel assignment inSDSL frame via a special configuration channel realized by Z1 bits (8kbit/s); the configuration managementcommands use approximately half of this capacity. In September, TM6 agreed to include a new study point in theDTS/TM-06015 living list to address dynamic time slot assignment to PSTN/ISDN channels in the SDSL frame.TM6 also discussed a proposal for layer management of this process via EOC messages (TD-13, Czech Telecom),and concluded with a call for increased reliability and speed of the handshake procedure. At this meeting, TD-18 wasaccepted for further study; M. Meninger was appointed champion of this study point.

VOICE OVER DSL

DTS/TM-06022 (SDSL REVISION OF TS 101 524)

TD-13 (R. Franco, Tioga) addresses the impact of temperature variation in warm start. TD-41 (S. Krause, Infineon,Vienna, September 2000) proposed a warm start activation procedure; such a procedure, it claimed, would be feasibledue to a priori stored information on the transmission environment. TD-13 presents the results of an examination ofthe impact of temperature changes on performance using the a priori information. It shows that the performance ofan SDSL modem might degrade severely after warm start due to temperature variation if the echo canceler is notretrained. The simulations examined only echo characteristics due to changes in the temperature of the loop;temperature changes in the equipment will further degrade the modem performance.

TD-17 (L. Frenkel, Tioga) proposes a complementary mechanism to improve the warm start procedure proposed inTD-41. As shown in TD-13, if changes in the characteristics of the channel are not tracked during reduced powermode, performance can be degraded by up to 14 dB (for a temperature change of 10 degrees). The result will be afailure of the warm startup for a large range of margin-sensitive cases. To solve this problem, TD-17 proposes thatthe two sides will send probing signals for the training of their echo cancelers during reduced power mode. It



proposes that the already defined probing signals Pri and Pci be used, to also allow optional tracking of timing andequalizer changes, and leave only the timing phase to be acquired during warm startup.

TD-24 (W. Jones, Conexant) proposes that m-sequences be used as the wake-up signals for SDSL warm start. TD-42 (Warm start wake up tones [S. Krause, Infineon], Vienna, September 2000) proposed to use tones at the G.hsfrequencies of the 4 kHz signaling family for the wake up signal. TD-24 proposes a slight modification to thewakeup procedure proposed in TD-42 to distinguish between short tones (warm start) and long tones (G.hs coldstart). M-sequences offer a number of advantages over single tones, and are easily generated with the currentscrambler. This proposal consists of two parts: the warm start wake-up signals themselves and the warm start wake-up procedure.

TD-25 (R. Jonsson, Conexant) proposes refinements to the warm start activation sequence proposed in TD-41. TD-41 used only full-duplex transmission; TD-25 proposes inclusion of half-duplex segments to allow faster and morerobust warm-start.

It was agreed to take these documents (including the study of temperature effects described in TD-13) into the formerstudy point 2-11 on warm start.

RFI

TD-08 and TD-09 are correspondence from Q4/15 (G.test.bis) to the ADSL and SDSL Rapporteurs, respectively,regarding RFI ingress on access lines carrying xDSL signals. It informs that G.test.bis (G.996.1 Issue II) wasDetermined at the last SG15 meeting and is scheduled for Decision at the next ITU SG15 meeting in February 2001.The Determined version of G.test.bis contains RFI test procedures and RFI models for North America. It does notcontain RFI models for Europe but Q4/15 has agreed to include the European RFI models from BA-059 (L.Humphrey, Nortel, Antwerp, June 2000) in a future version of G.test. It requests an update on the status of theEuropean RFI models in ETSI. It includes the testing procedure from the Determined G.test.bis for TM6 review.Acknowledging ETSI’s plan to consider the use of modulated carriers, it informs that the Determined G.test.biscontains RFI models and test procedures that do not use modulated carriers.

TD-26 (K. Foster, BT) presents data on RF ingress test levels from a small sample and proposes methodology forSDSL and ADSL testing. Ingress of broadcast AM transmission is found on underground (substantially lower) aswell as overhead telephone lines. On the overhead lines, peaks of - 40 dBm to -50 dBm were observed. Measureddiurnal ingress levels on overhead lines varied from 2.2 to 4.4 dB on average. BT recommends an allowance for thisvariation in the lab test requirement. In the UK, significant ingress in the LW as well as the MW band can beexpected. BT recommends the use of an ingress test frequency around 198 kHz. In the plots, the effects of multipletransmitters can be identified.

Recently there has been considerable debate on this. In particular, the work in TM6 on SDSL has raised questionsabout the validity of the 10-disturber model and the test levels. TD-26 provides examples of common mode ingresslevels on overhead and underground telephony wire-pairs. BT recommends keeping the multi-disturber ingress noisemodel. The author acknowledges that the information it contains is not an exhaustive treatment of the behavior ofthe UK network; but the limited measurement data does illustrate certain features that are relevant to the currentdebate. TD-26 was offered for information.

TD-41 (D. Daecke, Infineon) describes experiments that prove the correctness of RFI ingress and egress formulaepresented at the TM6 September meeting in Vienna. In addition, it compares the results of an electromagnetic fieldsimulator to both the simulation and the theoretical results: the theory correctly describes the electromagneticcoupling. Another result shown is that the current distribution assumed by the theory is the worst case. This meansthat, in practice, RFI levels will usually be much smaller than calculated.

TD-42 (D. Daecke, Infineon) summarizes the results of several studies on RF disturbances on telephony wire-pairs.Measurements have been made at telephone subscriber and exchange sites in Germany. Voltages on the line, as wellas the electric field strength (which induces these voltages) have been measured. A demographic analysis of theelectric field strength helps to assess the percentage of affected subscribers. Although measurements presented inthese two contributions indicate reasonable agreement with theory, it was agreed that more work needs to be done.

TD-43 (D. Daecke, Infineon; A. Tannhäuser, Siemens) describes the RFI noise model, the test procedure and the testloop lengths, for SDSL. The authors revised the RFI ingress test proposed in TD-35 (D. Daecke, A. Tannhäuser),from the September meeting, after several discussions with telecom operators. TD-43 proposes levels for the RFIingress tests, differential- and common-mode tests, differential- and common-mode signals in dBµV, single and dualinterferer tests, tests on ETSI loop #2 with FSAN A and FSAN B noise, and reduced test loop lengths for RFI



ingress tests (length TBD). In discussion, TM6 agreed that the phase relationships between test interferers should beunpredictable.

TD-44 (D. Daecke, Infineon; A. Tannhäuser, Siemens) proposes text to enhance the description of the test proceduresin Part 1 of the SDSL TS, which describes the functionality of the tests without prescribing a specific test set up.The additions proposed in this contribution allow RFI ingress testing and probing of the RFI noise signals. TM6provisionally agreed to incorporate this text in the merged document (TM-06018), but with an Editor’s noteindicating the status of this proposal and further work to be done. Nortel will also add a note to indicate that adetailed circuit diagram is to be provided in an Annex.

TD-55 (P. Reusens, Alcatel) proposes realistic models for RFI caused by AM on ADSL and SDSL in Europe. Aproposed test signal to model RFI on ADSL and SDSL contains one LW and three MW AM stations, all with anequally strong level; this is not realistic for Europe. The proponents could not find a location in Europe where morethan two strong stations are collocated. Moreover, for RFI reasons, LW stations are mostly single, except for wherea LW and a MW station share a single location, e.g., a British station in Droitwich. The proposed test signal alsoseems unrealistic on other frequencies outside the MW broadcast band. To model the RFI for a realistic, reasonablebad case, TD-55 proposes:

• To limit the number of strong AM stations in the RFI test for xDSL to two• To revisit the power levels outside the AM broadcast band• To use a field-strength of 3V/m, common for immunity tests of electronic equipment• To use a realistic cable model and to define a “worst case” cable geometry

It was agreed that an ad hoc group will discuss this and the other relevant contributions.

Annex J to the meeting report provides a liaison informing ITU-T Q4/15 that the number of separate test-models andthe number of simultaneous interferers and their common mode and differential mode amplitudes are not yet agreed.TM6 is currently studying interferer models that are modulated, but the method of simulating the modulated carrier isnot yet identified. It has been provisionally agreed that ETSI will define a functional description of a test method forSDSL. This liaison led to an animated discussion. The proposed addition of a common mode test set up, whilejudged as needed by most delegates, was found to be incomplete by other delegates who would like to contribute moredetails on the actual implementations of the test diagrams.

WD-02 (R. van den Brink, KPN) proposes text to modulate the ingress noise generator to prevent the faking of a testby subtracting a reconstructed test signal. There was some debate on this, as to whether or not the test issufficiently realistic. This contribution came too late to be approved by TM6 at this meeting; it was accepted as aninput to the next meeting. It will be kept under study, and discussed via email in the interim.

VDSL

B. Waring (consultant for Lucent) is the VDSL Rapporteur. WD-03 is the work plan for the VDSL session.

TS 101 270-2, VDSL Transceiver requirements, was approved for publication by TM voting procedures. The votingresults are shown in TD-16 (B. Mattsson, ETSI TB Officer). All the editorial and technical comments from the voteare in TD-58 (B. Mattsson, ETSI TB Officer).

An ad hoc group met to discuss TD-58 and TD-48 (G.994.1 issues), to resolve editorial problems and produce thefinal draft for publication; WD-10 provides the results of this meeting. Most of the editorial comments wereaccepted. The comments relating to G.hs were considered separately. Comments dealing with the flexible bandallocation plan, so-called “Fx”, were not accepted.

TD-36 (J. Boström, Ericsson) discusses an incompatibility between TS 101 270-2 and G.994.1 (G.hs), that wasidentified by Q4/15, in their October meeting. In the start up section of the Multicarrier specification, a handshakeprotocol is used which uses functionality described in G.994.1 (G.hs); this could lead to problems if a G.hs-capablemodem was to be connected to a line with an ETSI DMT VDSL modem at the other end. While G.hs is designed tobe future proof and backward compatible, the G.hs modem will identify the information sent from the other side thatit recognizes, and ignore the information it can’t decode, assuming that it is information from a later, more advancedrevision of G.hs. However, the G.hs compatible modem will identify some parts of the message sent by an ETSIDMT VDSL modem and try to act on the little information it can identify. In this situation, the G.hs modem willbe utterly confused. To further complicate things, it can be conceived that ETSI “stole” a top level code point fromG.994.1 to identify this ETSI DMT VDSL mode of operation. TD-36 outlines a proposed solution to this problem,



which can be resolved with only editorial changes to TS 101 270-2. This same problem was identified for theCommittee T1 (former ANSI T1), part 3 (DMT VDSL) document.

TD-37 (J. Boström, Ericsson) proposes a code point to support DMT VDSL. At the Q4/15 October meeting, it wasagreed that two SPar(1) bits of the standard information field in ITU-T Recommendation G.994.1 should be reservedfor ETSI VDSL use. TD-37 proposes that one of the two reserved SPar(1) bits for ETSI be assigned as “ETSI DMTVDSL” mode. It also proposes the drafting of a liaison to Q4/15 requesting the inclusion of the new code point inG.994.1. Background information on this issue can be found in TD-36.

TD-40 (J. Boström, Ericsson) discusses a long-term goal for the ETSI VDSL hs information. Moving the SPar(1)bit table out of TS 101 270-2 and including that information in G.994.1 instead, to resolve the incompatibilitybetween TS 101 270-2 and G.994.1, will not complicate the Approval process for the ETSI specification, and willresolve this issue for the current document. However, for the long-term it is preferable that all the appropriateinformation required for the ETSI VDSL handshake be available in G.994.1. For other standards using G.hs, allcode point tables are included in G.994.1; in this current, proposed solution, the top level codepoints (the SPar(1)bits) will be available in G.994.1 but the other codepoints will remain in TS 101 270-2. TD-40 proposes that theremaining codepoint information be transferred to G.994.1 for the next revision of the TM6 VDSL specification,which could then reference the appropriate section in G.994.1. This proposal was generally approved by TM6.

TM6 considered the technical comments given in TD-58; most of them will be taken to the next revision. It wasagreed to align the multi-carrier handshake with G.994, with the text related to the G.994 handshake issues to bemoved to an informative annex prior to inclusion in G.994.1. Two new code points were created: “ETSI MCMVDSL” for multi-carrier, and “ETSI SCM VDSL” for single carrier. The revised text for the VDSL G.hs is in WD-13.

It was agreed to send a liaison to Q4/15 to request that the two new code points be included in G.994.1, to inform onthe merger of the SDSL Parts 1 and 2 and the status of the differences between ITU-T G.shdsl and ETSI SDSL, andon the results contained in WD-14r1 providing changes to the initialization timers and the addition of a Tact Globaldefinition of the maximum time from the start of the initial handshake of 30 sec.

PRESENTATION ON UNBUNDLED DSL EVOLUTION

J. Cioffi (Stanford University), an invited speaker, presented the following contributions:

TD-05, Unbundled DSL evolution (J. Cioffi, Stanford University), reviews cable and wireless competitors toadvanced DSL service in terms of broadband access practice and service competition allowed through theirarchitecture. It shows how these services evolve into unbundling at a packet level, not a physical-layer level. Itthen follows the DSL architecture to project its possible unbundled evolution. It concludes that evolution of a DSLalternative to collocation at remote terminals is near-inevitable. The most likely alternative is seen to be packetunbundling, which is the resale of the digital bandwidth available on the twisted pairs, rather than the direct physical-layer lease of the line itself. Consequently, this possible evolutionary path deserves attention by standards groups intheir development of advanced DSL standards.

Spectrum management for Line Terminal (remote terminal in North American terminology) based services,particularly newer, higher-speed asymmetric and higher-speed symmetric DSL services, depends on regulatorydecisions not yet made to allow collocation at the LT. Presumption of only one particular type of unbundling at theLT is therefore unwise, because the consequent spectrum decisions may not correspond to or be close to the best thatDSL can do if that presumed regulatory decision is not made. In contrast, spectrum management and advanced DSLdescriptions still need to study and encompass the possibilities that regulatory policy may provide. TD-05 proposesthat TM6 consider a study point on “spectrum issues for packet unbundling” in its study of all advanced DSLs.

TD-06 (J. Cioffi, Stanford University) discusses spectrum management with advancing DSLs. Spectrummanagement studies have to date tended to specify some typical and worst-case loop situations, and then proceed todefine fixed spectra for each type of DSL to compromise the mutual degradation between services. Consequently,such a fixed spectrum assignment may not produce the desired level of compromise in situations different from thosepresumed in the studies.

TD-06 attempts to expose the performance loss incurred because of the fixed spectrum assignment. It defines thecurrent practice of fixed spectrum management as “static spectrum management,” in contrast to a system withadaptive determination of DSL spectra, which it calls “dynamic spectrum management.” Necessarily, static SM is aspecial case of dynamic spectrum management, so static can never outperform dynamic spectrum management. Thequestion then arises as to the level of improvement that dynamic SM can provide. This level of improvement varies



with loop, crosstalk coupling function, and data rates/symmetries offered, but can be quite large (double, in oneexample provided). The level of relative improvement increases as loop lengths get shorter and data rates get moresymmetric, as is likely to be the case as DSL evolves. Importantly, dynamic spectrum management allows a greatermix of high-performance asymmetric and symmetric service in the same binder.

TD-06 notes two unbundled situations of interest within the context of dynamic SM: line unbundling and packetunbundling, and defines two types of dynamic SM it will consider in these two cases: “spectrum balancing,” and“vectoring.” It reviews the basic vectoring LT for advanced DSL services, and then projects performanceimprovements with respect to static SM. The level of data rate and symmetry improvement is dramatic for this case,especially as line lengths get shorter and crosstalk is increasingly a factor. TD-06 also discusses spectrum balancing,which is the method used in the case of dynamic SM for line unbundling.

TD-06 concludes that dynamic spectrum management merits further study. In addition to very large improvementsin data rate, it allows a much wider range of symmetric transmission for short DSL lines served by line terminalscloser to the customer. Even with a fixed single spectrum, vectoring by itself can add substantial improvements; itindependently deserves consideration for packet unbundling. Both techniques together may provide an enormousboost to DSL’s evolving future with respect to cable and other broadband access alternatives.

TM6 welcomed these contributions with interest and as providing provocative thought for future TM6 work. J.Cioffi encouraged TM6 to consider these alternatives for spectral unbundling in its work.

STUDY POINTS FOR THE REVISION OF TS 101 270-2 (TM-06023)

TD-35 (S. Schelstraete, Alcatel) evaluates the upstream capacity in the three network topologies that were proposedin BI-079, G.vdsl: Network topologies for VDSL upstream power back-off (PBO) analysis (Bell Canada, BT,France Telecom, Korea Telecom, SBC, Swisscom, Telecom Italia, Telia) at the Q4/15 October meeting. It foundthat these capacities can differ substantially. This means that the ability to estimate reaches for a certain servicerequires having a clear idea of which network topology corresponds to the actual network situation. If the networktopology does not closely resemble the topology used for PBO studies, the reaches can be miscalculated.

TD-35 proposes the results of using an upper bound for FEXT noise in a distributed environment. When this upperbound is used, the reaches in a worst case scenario can be determined. Even if these values would be pessimistic insome network topologies, the actual reach should never be less than the calculated value. This at least would allowfor an accurate planning for the roll-out of a service, since minimum reaches can be guaranteed, independent of theactual network topology. TD-35 compares the upstream capacities for each of the proposed network topologies withthe results that are obtained when worst-case FEXT is assumed. It shows that the worst-case FEXT gives a rathertight lower bound for the capacities that are obtained in each of the proposed topologies. This contribution waspresented for information; it was agreed that it will be associated with SP 2-1.

TD-11 (B. Waring, Lucent, Rapporteur) is the issues list for VDSL; it contains issues raised at recent TM6 meetingswhich need to be addressed in the next revision to the VDSL Requirements Specification (TS 101 270-1). It alsoacts as a temporary place-holder for outstanding Part 2 Issues.

The study points for the revision of TS 101 270-2 (TM-06023) are as follow:

2-1 Study of single power back off algorithm2-2 Behavior of option dynamic power savings mode

The study points for the potential revision of Part 1 are:

1-1 What reach values shall be included in Tables 7 and 8 of the specification1-2 Additional PSD mask for FTTCab1-3 What should the power dissipation be for remotely located VDSL transceivers1-4 What are the power dissipation and volume requirements for exchange based VDSL transceivers1-5 Is there a need to specify an allowed ripple in the transmit PSD mask1-6 Is there a need for a notch at 10.7 MHz

ETSI has completed a significant step in the VDSL history by publishing part 2 of the VDSL specificationincluding two line codes.

VDSL SERVICE DEPLOYMENT REQUIREMENTS (TM-06024)

K. Starnberger (Infineon, Rapporteur) introduced this new project; he emphasized the importance of moving thiswork forward as quickly as possible to support the revision of TS 101 270-2. The scope of this work item is to



study the service deployment requirements and the applications for the VDSL to determine the need for any additionalband plans. An ETSI TR will be produced; by end of 2001 the revision to Part 2 must be completed. A Table ofContents was presented; the Rapporteur encouraged discussion via email to finalize it.

ADSL

L. Magnone (CSELT, Telecom Italia group) is the ADSL Rapporteur. The work plan is contained in WD-12.

TD-03 (A. Thöny, Swisscom AG; supported by British Telecom, France Télécom, KPN, Telecom Italia, Telia,Belgacom, Czech Telecom) contains two proposals to align the transmission performance requirements in RTS/TM-06006 (future TS 101 388 v.1.2.1), Transmission and multiplexing (TM); Access networks; Asymmetric digitalsubscriber line (ADSL) – European specific requirements. These proposals are made for all four ADSL types (up-and down-stream): ADSL over POTS (FDD), ADSL over ISDN (FDD), ADSL over POTS (EC), and ADSL overISDN (EC).

Proposal 1 proposes that the transmission performance requirements for all four ADSL types be included inRTS/TM-06006 (ADSL). Proposal 2 proposes that the transmission performance tests shall consider the four typesof ADSL systems and the eight ETSI ADSL loops and the four FSAN noise models (A, B, C, and D). Only threepayload rates shall be made normative, namely a low, a medium, and a high bit rate. All the other requested, usefulperformance data should be included in an informative annex of RTS/TM-06006. These two proposals were dis-cussed among the European operators during the FSAN meeting in Toronto in October 2000. This was accepted,with the addition of a further sentence to indicate that the other transmission direction should also be taken into ac-count.

TD-34 (O. Neulander, Tioga) addresses SP 1 of the ADSL living list, namely performance objectives for ADSL overISDN. An adequate set of transmission tests for ADSL over ISDN has not yet been provided in the framework ofRTS/TM-06006. TD-34 presents performance objectives for ADSL over ISDN operating under FSAN noise modelsA, B, and C, which are realistic noise models for testing ADSL over ISDN. It gives results for all the standard ETSIADSL test loops. TM6 agreed to keep this revised data, plus loops 5 - 8, for study.

TD-54 (P. Reusens, Alcatel) discusses issues related to the performance figures of ADSL over ISDN. It is difficultto check the performance requirements of FDD equipment with bands differing from the reference. Similarly it isdifficult to check the performance of EC equipment when carrier masking is applied in the zone with spectral overlapof upstream and downstream. TD-54 presents a method to derive exact performance requirements for ADSLequipment that is using carrier sets that differ from the reference sets. In this way, vendors can show that theperformance of their equipment, although different from the reference value, is equivalent to or better than theminimal performance requirement of the reference design. This proposed method also could be applied to ADSL overPOTS. This was considered, and a new study point, SP-24, was generated to study these issues.

TD-53 (P. Reusens, M. Beck, Alcatel) discusses selective reduction of ADSL RFI in the AM broadcast band. Tofight the possible leakage of ADSL from poorly balanced wiring, it is not necessary to reduce the ADSL TX PSDover the full AM radio band. It is possible to protect all local AM stations, and to apply selective protection by areshaping of the ADSL transmit spectrum. TD-53 shows that it is possible to reduce the ADSL emission in theAM band by 10 to 20 dB by simple masking, i.e., removing a number of carriers. It shows the results ofcalculations carried out assuming a protected bandwidth of 9 kHz around a given central AM frequency, and a desiredADSL attenuation of –10dB to –20dB in this band. The deactivation of at most 4, 7, or 18 DMT tones decreases theRFI by 10, 15 or 20 dB. TD-53 proposes that TM6 consider sending a liaison to the mixed ETSI/CENELEC groupon this. TM6 did not agree because of the possible negative impact it might have on ADSL deployment and the riskthat CENELEC might ask for other tone masking. TM6 agreed to not take this any further at this time.

TD-56 (P. Reusens, Alcatel) shows detailed measurements of ADSL emission in balanced conditions. TD-47 (P.Reusens, Alcatel) in Grenoble May, 1999 (CSR Vol. 10.5) discussed ADSL RFI leaking from the in-house wiring.The tests it described, which were done with a magnetic antenna, measured the egress on different wiring, includingUTP-5 and flat cables. TD-56 gives details of these measurements. Radiation possibly caused by conditions ofunbalance was minimized. Symmetrical wires were used, and a high common mode impedance to ground waspresent. TD-56 concludes that balanced wires will generate no relevant ADSL RFI on local AM stations, even forflat cables, and even when they are mounted consistently untwisted. It also concludes that only cable unbalance cancause ADSL to generate a significant RFI. This conclusion is in line with other contributions, where theoreticalmodels of xDSL RFI were derived. (See TD-39 from the September, 2000 meeting: RFI ingress – Coupling of anelectromagnetic field into a twisted pair cable [R. Stolle, Infineon]). TD-56 was accepted for information; this topicis for further study.



TD-57 (P. Reusens, Alcatel) discusses the spectral compatibility of ADSL deployed from the cabinet with ADSLdeployed from the CO. This spectral compatibility can be achieved by spectral shaping. ADSL from the cabinet isa major source of crosstalk, blocking ADSL from the CO signals, unless the TX PSD at the cabinet is shaped withthe average attenuation of the line between CO and cabinet. However, on carriers where ADSL from the CO carriesno data beyond the cabinet, the ADSL from the cabinet can put data, and use a higher PSD. It must only avoidbecoming an out-of-band crosstalk source to the ADSL from the CO. Thus, when mixing ADSL from both CO andcabinet, spectral shaping and masking is needed. This is available in DMT, where individual carriers can be tunedand deleted. More work is needed to accomplish an acceptable spectral compatibility. TM6 considered this, andcreated SP-26 to study it and similar issues.

RTS/TM-06006 was not yet stable enough for approval at this meeting, mainly due to a lack of contributionsaddressing performance requirement (SP-1) and FDD architecture issues (SP-16). It was agreed that completeperformance requirements are needed for at least one system before approval can be sought. It was agreed to changethe target date for WG approval to the May 2001 meeting (TM6 #22).

DSL TESTING AND INTEROPERABILITY ISSUES

At the September meeting, A. Ehre (CETECOM) was appointed to lead email discussions on the TM6 emailexploder, and to develop draft plans for ongoing cooperation with the DSL Forum and associated development of theETSI work plan. WD-16 (A. Ehre, CETECOM) summarizes the email discussions on interoperability issues thatwere held in the interim.

ETSI BAKE-OFF SERVICE

B. Mattsson (ETSI TB Officer) presented an overview of the ETSI bake off services. More information can be foundon the ETSI web-site: <http://www.etsi.org/bake-off/>.

TD-59 (R. Scholl, ETSI) informs that after the trial period in 2000 of the ETSI Bake-off Service, the ETSI GA hasapproved its continuation as a permanent service (bake-off = plugfest in xDSL-parlance). ETSI bake-offs continue toreceive high marks by the participants. Their usefulness is unquestioned, as they allow engineers to debug theirimplementations and specifications. A prospective xDSL Plugfest, hosted by the ETSI Bake-off Service inconjunction with the DSL Forum, is being planned for 2001; a final decision, together with the details, is expectedin December.

TM6 considered the need for a work item related to bake-off events; it was agreed that it is first necessary todetermine what the real interest within TM6 is before committing to what could be considerable work. Concern wasexpressed about the effectiveness of single bake-off events. It was felt that a permanent facility might be required.After an animated debate, TM6 agreed to work on a European test plan for SDSL (based on the DSL Forum G.shdsltest plan); ETSI bake-off services are not necessarily appropriate to the interoperability testing, which requires largerinvestments and more stable infrastructures. The need for a European test laboratory “approved” by the DSL Forumwas also considered.

WD-19 is a liaison to DSL Forum concerning interoperability. It indicates that ETSI will build up a test plan forEurope, based on the DSL forum G.shdsl test plan, and that ETSI is also considering the possible qualification of aEuropean test lab.

SPECTRAL MANAGEMENT

R. van den Brink (KPN) is the Spectral Management Rapporteur. WD-01 is the work plan for this meeting.

TR 101 830-1, PART 1: DEFINITION OF SIGNALS

TD-07 (R. Jonsson, Conexant) proposes refinements to DTS/TM-06016, the proposed spectral management text forSDSL, Spectral management on metallic access networks; Part 1: Definitions and signal library. TD-07 is based onthe earlier proposal in TD-15 (R. Jonsson, Conexant) from the September meeting. These refinements were acceptedfor inclusion in the draft. The increase in peak voltage (to 16V in section 9.6.2) for 2048 SDSL was noted; it wasprovisionally agreed, and will be studied in more detail. There is a study point on peak level, but no contributionshave been submitted on that topic.

TD-20 (R. Trevland, Norwegian Regulatory Authority) points out some inconsistencies and ambiguities on theinformation under Power Feeding clauses in TR 101 830-1, and proposes modifications of the information. A newstudy point was created to consider how to resolve the power feeding part of the spectral management. It was not



obvious what DC feeding has to do with spectral management. Reporter’s comment: the text on power feedingshould go in either an Annex to the spectral management document or in a separate technical report.

WD-05 (B. Pechey, Paradyne) describes a transcription error in the section “Proprietary SymDSL.CAP/QAM” inv.1.2.0 of draft TR 101 830-1, and gives the correct information for inclusion. This was agreed for inclusion in therevision of the TR.

WD-06 (P. Kyees, Paradyne) describes an additional sub-category for Spectral Management Specification:“Proprietary.SymDSL CAP/QAM::Fn” signals, and proposes them for inclusion in DTS/TM-06016. This categorycovers signals generated by proprietary DSL transmission equipment on a single wire pair. The description of these“Proprietary.SymDSL.CAP/QAM::Fn” signals is line code independent, but derived from CAP/QAM based signalssimilar to those defined in “Proprietary.SymDSL.CAP.A::Fn” and “Proprietary.SymDSL.CAP.B::Fn” in DTS/TM-06016. This category covers CAP/QAM implementation other than that covered by those signals. This was agreed,except for the longitudinal balance.

PART 1 LIVING LIST

1-1 Complete signal description of ADSL FDD over POTS1-2 Complete signal description of ADSL FDD over ISDN1-3 Complete the DTAG/Telia primary signal description1-4 Complete the scope and legal status of document1-5 Review of peak amplitudes for the signal library1-6 Complete signal description for SDSL

FURTHER WORK AND POSSIBLE PART 2

WD-04 (R. Kirby, BTExact) contains a text proposal for the Scope of Part 2 of the spectral management document.Different European countries will have different spectrum management rules. Their networks are physically differentand have different populations of existing xDSL systems, each with differing planning rules; constructing anefficient set of rules for a country appears difficult. WD-04 proposes that Part 2 should contain general principles forthis; it gives guidance on constructing network-specific spectral management specifications. The TM6 Chairindicated that it was a bit early to do this.

It was agreed that, until sufficient background preparation is made for the creation of a work item for Part 2, the openissues will be maintained as an informal living list. The following informal living list contains issues for study ina possible Part 2:2-1 Spectral management for non stationary signals2-2 Limits for noise that may leak into loop wiring

The following new study point was created at this meeting:2-3 Scope, objective, and Table of Contents of TR 101 830-2

Jacques Besseyre, Ph. D. Telecomsult SARL



ROSTER OF TM6 MEETING #20, NOV. 27 – DEC.1, 2000, MONTEREY, CALIFORNIA

Hans-Jörg Frizlen (ETSI) TM6 Chair (Outgoing)Manfred Gindel (Telekom Austria) TM6 Chair-electHosts: Texas Instruments, Intel and Cisco

Austria Telekom Austria AG Manfred GindelBelgium Alcatel Bell Peter ReusensBelgium Alcatel Bell Sigurd SchelstraeteBelgium Element 14 (Broadcom) Olivier Van De WielCanada PMC-Sierra Inc. Edward JonesFinland Finnet Group Pasi JuhavaFinland Nokia Corporation Jari LindholmFinland Nokia Corporation Jouko TörmänenFinland Tellabs Oy Janne VäänänenFrance Conexant Systems SAS Rammy BahalulFrance Conexant Systems SAS George EislerFrance Conexant Systems SAS William JonesFrance DLS Testworks Ltd. Michael GirouxFrance ETSI Hans-Jörg FrizlenFrance ETSI Bernt MattssonFrance France Telecom Jean-Marc CorolleurFrance GlobeSpan Jacques BesseyreFrance LEA Laboratoire Européan ADSL Philip GoldenFrance Level One Com. Europe Berna AdalierFrance Level One Com. Europe Anil AgrawalFrance Level One Com. Europe Amod DandawateFrance Level One Com. Europe Jim GirardeauFrance Motorola S.A Bernard DugerdilFrance Paradyne International Bill PecheyFrance Sagem Group Roger SamyFrance ST Microelectronics S.A. Mario Diaz NavaFrance Texas Instruments Krista JacobsenFrance Texas Instruments SA Konrad KratochwilFrance Texas Instruments SA Neil QuarmbyGermany Alcatel Kommunikations Elektronik Ludger DreierGermany Alcatel Sel AG Siegfried SchmollGermany Cetecom ICT Services Gmbh Andreas EhreGermany Deutsche Telekom Ag Ronald HoffmannGermany Fraunhofer ESK Sven KeuneckeGermany Infineon Technologies Dirk DaeckeGermany Infineon Technologies Neal King InfineonGermany Infineon Technologies Sascha LindeckeGermany Infineon Technologies Klaus StarnbergerGermany Infineon Technologies Reinhard StolleGermany Infineon Technologies Ingo VolkeningGermany Marconi Communications Gmbh Reinhold FeigelGermany Siemens AG Wilfried KubingerGermany Siemens AG Hagen HennigerGermany Vacuumschmelze Gmbh Stefan LehmannIsrael Tioga Technologies Ilan SharferItaly Elecom Italia SPA Alessandro Tosti TItaly Italtel S.P.A. Alberto ProfumoItaly Telecom Italia SPA Flavio Cucchietti



Italy Telecom Italia SPA Manrizio GiammarchiItaly Telecom Italia SPA Lorenzo MagnoneNorway NPT (Norway) Rasmus TrevlandNorway Telenor R+D Svein A. SkyttemyrPortugal PT Inovacao (Portugal Telecom) Paulo Mao-CheiaSweden AB LM Ericsson Jan Boström TelefonSweden Telia AB Marcus JonnsonSweden Telia AB Tomas StefanssonSwitzerland Adtran AG Marc KimpeSwitzerland Adtran AG Kevin SchneiderSwitzerland Ascom AG Angus CarrickSwitzerland Bakom / Ofcom Kurt BartschiSwitzerland Swisscom AG Switzerland Andreas ThönyThe Netherlands KPN Rob Van Den BrinkThe Netherlands Lucent Technologies EMEA B.V: Carl PostumaThe Netherlands Lucent Technologies EMEA B.V: Brian WaringUK BT PLC Kevin FosterUK BT PLC John MacdonaldUK Harris Communication GB Kamran KhadaviUK Consultronics (Europe) Thomas NagelUK Globespan Inc Massimo SorbaraUK LSI Logic Europe PLC Shirish AltekarUK Lucent Technolgies (Uk) Ltd. (M) Harry MildonianUK Marconi Communications Ltd. Peter DixonUK Marconi Communications Ltd. Graham PhillpottUK NEC Europe Ltd. Georgi PetkovUK Nortel Networks (Europe) Les HumphreyUSA - None - Mark PedenUSA ANSI T1e1.4 Tom StarrUSA Broadcom Corporation Vladimir OksmanUSA Cisco Systems Inc. Jan HobbelUSA Cisco Systems Inc Justus OsudeUSA Cisco Systems Inc Marcus MaranhaoUSA Copper Mountain Networks Inc. Jack YangUSA Intel (Formally Level One) Shawn HolidayUSA Invited Guest Ken KrechmerUSA QI Intel Corporation Xiao-FengUSA Stanford University (Invited Guest) John CioffiUSA Worldcom Paul DonaldsonUSA Worldcom Daryl C. Tannis



REPORT OF TR-30, DATA TRANSMISSION SYSTEMS AND EQUIPMENT,DECEMBER 4 – 8, 2000, SCOTTSDALE, AZ

Note: The TR-30.3 report will be published in January, 2000.

TR-30.1, MODEMS

ITU-T S TUDY GROUP 16

L. Brown (Conexant, Chair TR-30.1) presented a brief review of the results of the November 13-17, 2000 meetingof ITU-T Study Group 16 (see also the SG16 report in this issue of CSR). He noted that new RecommendationsV.44, V.59 and V.92 were approved at the closing plenary session. In addition, revisions of V.8 and V.8bis werealso approved. Work remains to complete an Appendix to V.92 which describes the Modem on Hold function.

LIAISON

TR-30.1/00-12-108 , Liaison from T1E1, informs TR-30 and its subcommittees that T1E1.3 is developing anannex to T1.403.02 which will explain the nature of difficulties in V.90 modems caused by robbed-bit signaling.The annex will offer suggestions on mitigation but is not expected to make significant changes in the assignmentsof signaling states to robbed bits because of the possibility of creating significant incompatibilities with the existingnetwork. They expect to ballot the annex after their February, 2001 meeting.

MODEM OVER IP (MO IP)

At the November 2000 meeting of ITU-T Study Group 16, Question 11 (formerly Q4, 10 and 23) took on a newwork item to develop a new recommendation for Modem over IP (V.moip). TR-30.1 agreed at this meeting to opena project to support this work and to work with Q11/16. It was agreed to work in a manner similar to that used,most recently, for V.92. Interim Q11/16 Rapporteurs meetings will alternate with TR-30.1 meetings to progressthe work. The goal is to Determine the work in late 2001.

TR-30.1/00-12-110 , Terms of Reference for modem over IP (MoIP) (same as TD-14(GEN)), came from theStudy Group 16 meeting. During the Study Group 16 meeting, an ad hoc discussion split the work on MoIPbetween Working Party 1 (modem experts) and Working Party 2 (H.323 experts). This paper is the result of thatdiscussion and was agreed by both WP1/16 and WP2/16.

TR-30.1/00-12-111 , Issues list for the work on V.moip (First Draft, same as TD-60(WP1/16)), was createdduring the discussion of V.moip in Working Party 1/16. This issues list will collect all agreements reached duringthe development of the V.moip Recommendation.

TR-30.1/00-12-106 , Proposed Project For Modem Operating over IP Networks (K. Chu, Conexant Systems),proposes that a work item be created in TR-30.1 to work in conjunction with the experts from ITU-T (new) Q11/16in the development of V.moip. It takes the stance that ALL modems, including proprietary modems, be included.

TR-30.1/00-12-107 , Modem Relay Overview (H. Wildfeuer, M. Garakani, Cisco Systems), proposes thatModem Relay (Modem over IP) work be initiated by TIA TR-30, driving an ITU-T recommendation. The documentindicates that they see two different approaches which can be taken: Physical layer transport and Protocol transport.

TR-30.1/00-12-104, Procedures for Real-Time Voice Band Modem Communication Over Packet Networks (ModemRelay) (Surf Communications Solutions), was seen by TR-30.1 earlier at the Columbia meeting without formalpresentation (TR-30.1/00-10-103). Editor’s note: It was first presented as APC-1496 at the Q13/16 meetingin Portland, OR, August 21-25, 2000 (CSR Vol. 11.8). Surf Communications presented it in detail at thismeeting. This paper jumps ahead of the basic understanding of the work and will be considered as a proposal duringfuture deliberations on V.moip. It presents two possible procedures for real-time voice band modem communicationover packet networks: MoIP I and MoIP II. MoIP I involves having a complete modem (data pump, error controland data compression) in each gateway. MoIP II involves having a partial modem (data pump only) in each gateway;it has more complex procedures but much shorter delay (several hundred milliseconds in the system round-trip-delay)and reduces modem processor requirements by about 25%.

TR-30.1/00-12-109 , Comparison Between Possible Procedures For Real-Time Voice Band ModemCommunication Over Packet Networks (MoIP) (A. Fisher, Surf Communications Solutions), compares the twoproposed procedures of APC-1496 . In addition, it considers several related issues as performance and theinteroperability of the modem data-pump with the Error Correction/Data compression (ECDC) layer. MoIP II isslightly more complex to implement as it requires hooks to the data-pump layer, which enable the controller to



perform spoofing, standard equalization and rate equalization between the two PSTN loops. Surf feels MoIP II is farsuperior and suggests that both procedures be optional to support different manufacturer requirements.

DCE - DCE COMMUNICATIONS

During the Question 8/16 session at the recent Study Group 16 meeting, it was recognized that there is a need forDCE - DCE communications to retrieve V.59 data from the remote modem. This subject had been avoided duringthe era of private line modems. At that time there were many proprietary systems making use of secondary channelsto perform modem diagnostics. Today, the need to standardize on a method for dial-up modems is recognized.

TR-30.1/00-12-105 , Remote Modem Management Information Exchange Proposal (M. Nichols, 3Com; USRobotics), suggests that TR-30.1 initiate work in support of DCE to DCE Communications, and makes apreliminary proposal as to one possible approach to take. TR-30.1 agreed to open a project which broadly coversthis area of work.

Fred Lucas, 3Com

TR-30.2, DATA TRANSMISSION

The TR-30.2 Chair is F. Lucas (3Com). TR-30.2/00-12-034 is the report of the October 2000 meeting.

ITU-T S TUDY GROUP 16

TR-30.2/00-12-035 (same as TD-69(WP1/16)) is the report of the Q7/16 sessions that took place during theNovember ITU-T Study Group 16 meeting in Geneva, Switzerland. F. Lucas reported that Q7/16 had completedwork on the Implementer’s Guide for V.250. TR-30.2/00-12-036 is the final, approved text for the V.250Implementer’s Guide. This Guide makes various corrections and additions to Recommendation V.250. Mostimportant of those are the addition of commands in support of new Recommendations V.44, V.59 and V.92.

F. Lucas also reported that the work of Questions 6 and 7 in Study Group 16 have now been combined in the newQuestion 13. Future work from the former Question 7 might involve a revision of V.250 to include theImplementer’s Guide, update of the Supplement to V.250 to add the new commands in the Implementer’s Guide andcommands to support the new Modem over IP work just started in Study Group 16.

PN-4647, ADDENDUM 1 TO TIA/EIA-678

F. Lucas reported that the Addendum to TIA/EIA-678, Data Transmission Systems and Equipment - SerialAsynchronous Automatic Dialing and Control for Character Mode DCE on Wireless Data Services, has beenpublished. This document is now available for purchase through TIA or Global Engineering Documents<http://global.ihs.com>.

PN-4584, TIA/EIA-644 R EVISION

J. Goldie, the editor for TIA/EIA-644-A, Electrical Characteristics of Low Voltage Differential Signaling (LVDS)Interface Circuits, indicated that he had made the editorial corrections agreed at the October meeting of TR-30.2 andhad forwarded the final text to the Chair. F. Lucas observed a few minor formatting problems which he will correctbefore sending the document to TIA for publication. This revised standard should be available through TIA withinthe next two months.

PN-4828, ELECTRICAL CHARACTERISTIC OF M-LVDS

J. Goldie, TR-30.2.1 ad hoc chairman, reported that the ad hoc committee was making good progress on the draft ofPN-4828, Electrical Characteristics of Multipoint Low Voltage Differential Signaling (M-LVDS) Interface. The adhoc committee will have the draft of the new standard ready for TR-30.2 review and industry ballot at the March,2001 meeting.

Fred Lucas, 3Com

TR-30.3, DATA COMMUNICATIONS EQUIPMENT EVALUATION AND NETWORK INTERFACES

The TR-30.3 report will be published in January 2001.



TR-30.1 AND TR-30.2 MEETING ROSTER, DECEMBER 4 – 8, 2000, SCOTTSDALE, AZ

Fred Lucas, 3Com TR-30 ChairLes Brown, Conexant TR-30.1 ChairFred Lucas, 3Com TR-30.2 ChairJack Douglass, Conexant TR-30.3 ChairHost: National Semiconductor

3Com Corp. Fred Lucas3Com Corp. Mike NicholasADI Haim PrimoBroadcom Henry LiCisco Systems Herb WildfeuerCisco Systems Mehryar GarakaniConexant Systems Les BrownConexant Systems Keith ChuESS Technologies Jordan CookmanFairchild Semiconductor Oscar FreitasFairchild Semiconductor Ron MorneaultIntel Bo ZhangLucent Technologies Ken JonesLucent Technologies John MagillLucent Technologies Ed SchultzLucent Technologies Jay YuNational Semiconductor Mike BristolNational Semiconductor John GoldiePC Tel Yuri GoldsteinSurf Comm. Solutions Nadav KatsirSurf Comm. Solutions Eldor ReifTexas Instruments Kevin GingerichTexas Instruments Sagir HasnainTexas Instruments Mark MorganTexas Instruments Adrian ZakrzewskiUS Robotics Cliff WallachVoCAL Technologies Ltd. Alberto Torres



ACRONYM DEFINITIONS

1-1SDoC One Standard-One-Test Supplier’s Declaration of Conformity3GPP Third Generation Partnership Project (ETSI)AAP Alternative Approval ProceduresABNF Augmented Backus-Naur FormACM Address Complete MessatgeADSL Asymmetric Digital Subscriber LineAM Amplitude ModulationAMR Adaptive MultiRateANAI Access Network Architecture and InterfacesANS Answer ToneANSam Answer Tone, amplitude modulated (V.8)ANSI American National Standards InstituteAPEC Asia Pacific Economic Cooperation ForumARQ Automatic Repeat RequestASN Abstract Symbol NotationATF Administrative Task ForceATIS Alliance for Telecommunications Industry SolutionsATM Asynchronous Transfer ModeB-ISDN Broadband-ISDNBES Back-End ServicesBICC Bearer Independent Call ControlBRA Basic Rate AccessBSMI Bureau of Standards, Metrology and InspectionCA Conformity AssessmentCAB Conformity Assessment BodyCCS Common Channel SignalingCENELEC Commission Europeenne de Normalisation Electrotechnique (European Electrotechnical Standards

Committee)CITEL Comision Internamericana de TelecomunicacionesCM Call MenuCME Circuit Multiplication EquipmentCO Central OfficeCOFETEL Comisión Federal de Telecomunicaciones de MexicoCPE Customer Premise EquipmentCPL Call Processing LanguageCS Canadian StandardCS-ACELP Conjugate Structure ACELPDC Direct CurrentDCE Data Circuit terminating EquipmentDCME Digital Circuit Multiplication EquipmentDEG Draft ETSI GuideDIG ISDN compatible Digital Station and tie trunk (TIA-646-B)DMT Discrete MultiToneDOC Department of CommerceDSL Digital Subscriber LineDSLAM DSL Access MultiplexerDSS1 Digital Subscriber Signaling 1DTE Data Terminal EquipmentDTMF Dual Tone Multi FrequencyDTS Draft Technical Standard (ETSI)DTX Discontinuous TransmissionE&M Ear and Mouth: Separate signaling linesEC Echo CanceledEC European CommissionEDH Electronic Document HandlingEFTA European Free Trade Area



EG ETSI GuideEIA Electronic Industry AssociationEIAJ EIA JapanEMC ElectroMagnetic CompatibilityENUM tElephone NUmbering Mapping (IETF)EOC Embedded Operations ChannelERM ETSI committee on EMC and Radio spectrum MattersES Elementary StreamETSI European Telecommunications Standards InstituteEUT Equipment Under TestFAQ Frequently Asked QuestionFCC Federal Communications Commission (U.S.)FCF Facsimile Control Field (T.30)FDAM Final Draft AMendmentFDD Frequency Division DuplexingFER Frame Error RateFEXT Far End Cross TalkFFPIM Full Mode Fax Profile for Internet MailFIR Finite Impulse ResponseFPDAM Final Proposed Draft AmendmentFSA Framework Study AreasFSAN Full Service Access NetworksFSK Frequency Shift KeyingGA General Assembly (ETSI)GEF Generic Extensibility FrameworkGETS Government Emergency Telecommunications Service (US)GK GateKeeperGPCAS Global Product Conformity Assessment SystemGSM Global System for Mobile CommunicationsGW GateWayHAC Hearing Aid CompatibleHDSL High-rate Digital Subscriber LineHE-LPC Harmonic Excitator Linear Predictive CoderHLF Home Location FunctionHTTP HyperText Transport ProtocolIAF Internet Aware Fax (T.38)IDCT Inverted Discrete Cosine TransformIE protocol discriminator Information ElementIEMS International Emergency Multimedia ServicesIEPS International Emergency Preparedness SchemeIETF Internet Engineering Task ForceIFA Informal FTP AreaIG Implementer’s GuideIG Interoperability GroupIMT International Mobile Telecommunications (IMT-2000)IMTC International Multimedia Teleconferencing ConsortiumIP Internet ProtocolIPP Internet Printing ProtocolIPR Intellectual Property RightsIPTEL Internet Protocol Telephony (IETF Working Group)IRS Intermediate Reference SystemISDN Integrated Services Digital NetworkISDN-BA ISDN Basic AccessISO International Organization for StandardizationISTO Industry Standards and Technology OrganizationISUP ISDN User PartITI Information Technology Industry Council (formerly CBEMA)ITU-T ITU Telecommunications Sector



IVR Interactive Voice ResponseJBIG Joint Binary Image GroupJPEG Joint Photographics Expert GroupJWG Joint Working GroupLAN Local Area NetworkLB Letter BallotLCF Location ConfirmLDCELP Low Delay CELPLES Loop Emulation ServiceLRQ Location RequestLW Long WaveMAP Mobile Application PartMBE Multi-Byte ExtensionMCM Multi-Carrier ModeMCU Multi-point Control UnitMELP Mixed Excitation Linear PredictionMG Management GroupMG Media GatewayMGC Media Gateway ControllerMoIP Modem over Internet ProtocolMoU Memorandum of UnderstandingMPEG Motion Picture Experts GroupMRA Mutual Recognition AgreementsMRAMS MRA Management SystemsMSLT Minimum Scan Line TimeMW Medium WaveNAFTA North American Free Trade AgreementNB narrow bandNENA National Emergency Number AssociationNIST National Institute of Standards and TechnologyNLP Non-Linear ProcessorNT Network TerminationNTU Network Terminating UnitOAM Operations, Administration, and MaintenancePAR Peak to Average RatioPBX Private Branch ExchangePC Personal ComputerPER Parameter Error RatePMS-TC Physical media Specific - Transmission ConvergencePN Public NoticePOTS Plain Old Telephone ServicePPM Parts Per MillionPRA Primary Rate AccessPSD Power Spectral DensityPSTN Public Switched Telephone NetworkPWG Printer Work GroupQoS Quality of ServiceQSIG The signaling protocol used at the Q-interface between two switches in a private network.

ECMA/ISO have defined a set of QSIG standards.R&TTE Radio and TTE (Telecommunications Terminal Equipment) DirectiveRAS Registration, Admission, and StatusRBER Residual Bit Error RateRCF RegistrationConfirmRF Radio FrequencyRFC Designation for an IETF StandardRFI Radio Frequency InterferenceROM Read Only MemoryRSVP Resource Reservation Setup Protocol (IETF)



RTP Real Time Transport Protocol (IETF)RTS Request to SendSCM Single Carrier ModeSCN Switched Circuit NetworkSCTP Simple Control Transmission ProtocolSDL Structure Description LanguageSDO Standards Development OrganizationSDoC Supplier’s Declaration of ConformitySDP Session Description ProtocolSDSL Symmetrical high bit rate Digital Subscriber LineSET Simple Endpoint TypesSG Study Group (ITU)SHDSL Single-line High Speed DSLSIP Session Initiation Protocol (IETF)SM Spectrum ManagementSMPTE Society of Motion Picture and Television EngineersSMV Selectable Mode VocoderSNMP Simple Network Management Protocol (IETF)SNR Signal to Noise RatioSPAN Services and Protocols for Advanced Networks (ETSI)SQEG Speech Quality Expert GroupSRU Signal Regenerator UnitSSG Special Study Group (ITU)STL Software Tool LibrarySTQ Speech Transmission QualityT&R Tip and RingTAPAC Terminal Attachment Program Advisory CommitteeTB Technical BodyTBD To be DeterminedTC Transmission Convergence LayerTC-AT Technical Committee Access and Terminals (ETSI)TCB Telecommunications Certification BodiesTCP Transmission Control ProtocolTDM Time Division MultiplexTE Terminal Equipment (ETSI Committee)TEL Telephony (APEC WG)TIA Telecommunications Industry AssociationTIFF Tagged Image File FormatTIGIN Transport Network Equipment for Interconnecting GSTN and IP NetworksTIPHON Telecommunications and Internet Protocol Harmonization Over Networks (ETSI Project)TM Transmission and Multiplexing (ETSI Committee)TMCC TM Chairman’s Coordination committeeToR Terms of ReferenceTPKT Transport Packet (T.123)TR Technical ReportTR Technical Requirements (TIA committee)TRIP Telephony Routing Information ProtocolTSAG Telecommunication Standardization Advisory Group (ITU)TSB Telecommunications Standardization Board (ITU)TSB Telecommunications Systems Bulletin (TIA)TTF Technical Task ForceTX TransmitUDP User Datagram Protocol (IETF)UMTS Universal Mobile Telecommunications SystemUN/ECE United Nations Economic Commission for EuropeUNI User-Network InterfaceUTP Unshielded Twisted PairVAME Voice on ATM Multiplication Equipment



VDSL Very high speed DSLVLF Visitor Location FunctionVoDSL Voice over DSLVoIP Voice Over Internet ProtocolWB Wide BandWP Working Party (ITU)WTSA World Telecommunications Standardization Assembly (ITU)xDSL all the different Digital Subscriber Line technologyXID eXchange IDentification

THE CSR LIBRARY

Subscribers may order copies of documents shown in boldface type from Communications StandardsReview, where not controlled. $50.00 for the first document in any order, $40.00 for the second, and$25.00 for each additional document in any order. Volume discounts available. Please contact CSR.

Documents listed with © are controlled documents. These documents are not for sale, but we can provideyou with the author’s contact information. ETSI meeting documents are also not for sale, but we canprovide you with the author’s contact information.

We have a large library of standards work in process and can help you locate other information you mayneed.

CSR recommends that you obtain published standards from Global Engineering Documents.Tel: 800 854-7179, +1 303 792-2181, Fax : +1 303 397-7935, http://global.ihs.com



YEAR 2001 STANDARDS COMMITTEE MEETING SCHEDULESAS OF DECEMBER 20, 2000

Subject to Change without Notice

Committee Date(s) Locat ionQ6/16 Adv. Video Cod. Jan 8 - 12 Eibsee, GermanyQ4/15 Rapp. Jan 8 - 12 Clearwater, FLAT Features-SMS Jan 16 - 18 S. Antipolis, FRT1E1.4 Jan 18 Dallas, TXQ11/16 (V.moip) Jan 22 - 26 CaliforniaTIPHON WG2-WG3 Jan 24 – 26 Burlingame, CAQ6, 7, 21/15 Jan 31-Feb 2 GenevaSG15 Feb 5 - 9 GenevaTIPHON WG6 Interim Feb 12 – 14 S. Antipolis, FRTM6 #21 Feb 12 - 16 S. Antipolis, FRT1E1 Feb 19 - 23 Costa Mesa, CATR-41 Feb 19 - 23 Costa Mesa, CAQ3, D, F, G/16 Mar 5 - 9 Melbourne, AUTR-30 Mar 5 - 9 ---TR42 Mar 5 - 9 Palm Springs or

PhoenixDSL Forum Mar 12 - 16 Vancouver, BCETSI AT #3 Mar 26 - 30 S. Antipolis, FRTIPHON #22 Mar 26 - 30 Bethesda, MDQ6/16 Adv. Video Cod. April ---Q4/15 Rapp (prop.) Apr 9 - 13 Cairo, EgyptQ11/16 (V.moip),Q12/16, Q13/16

Apr30-May4 TBD

T1E1 May 7 - 11 Orlando, FLTR-41 May 7 - 11 Orlando, FLTM6 #22 May 14 - 18 Ghent, Belgium

Committee Date(s) Locat ionSG16 May28-Jun8,

or Jun 4-15Brazil, or Geneva

Q4/15 Rapp (prop.) Jun 11 - 15 Southern CATR-30 Jun 11 - 13 Southern CATR-42 Jun 11 - 15 Montreal or NiagaraDSL Forum Jun 18 - 22 Oslo, NorwayQ6/16 Adv. VideoCod.

July ---

TIPHON #23 July 9 - 13 S. Antipolis, FRQ7/16 WB Speech Jul 23 - 27 ---Q4/15 Rapp (prop.) Aug 6 - 10 ItalyT1E1 Aug 20 - 24 Toronto or MontrealTR-41 Aug 20 - 24 Toronto or MontrealTR-42 Aug 20 - 24 Bar Harbor, ME or

Park City, UTDSL Forum Aug 27 - 31 New Orleans, LATM6 #23 Sep 10 - 14 S. Antipolis, FRETSI AT #4 Sep 24 - 28 S. Antipolis, FRTR-30 Sep 24 - 28 ---Q4/15 Rapp (prop.) Oct 8 - 12 MaineT1E1 Nov 5 - 9 San Antonio, TXTR-41 Nov 5 - 9 San Antonio, TXTR-42 Nov 5 - 9 New Orleans, LATIPHON #24 Nov 12 - 16 Cape Town, SATM6 #24 Nov 12 - 16 S. Antipolis, FRTR-30 Dec 3 - 7 ---DSL Forum Dec 3 - 7 Munich, Germany

Visit the CSR Web Pages: http://www.csrstds.comThe Web Pages include an on-line store (order subscriptions and reports), an updated Telecom AcronymDefinitions list, updated meeting schedules, a list of web sites and ftp sites as listed in all issues of CSRjournals, background material on telecom standards and CSR (the company), data sheets on both CSRtechnical journals, and more.

Communications Standards Review (ISSN 1064-3907) reports are published within days after the relatedstandards meetings. Editor: Elaine J. Baskin, Ph.D. Technical Editor: Ken Krechmer. Copyright © 2000,Communications Standards Review. All rights reserved. Copying of individual articles for distribution within asubscriber organization is permitted. Subscriptions: $795.00 per year worldwide, electronic format; $995.00 paperformat. Corporate Intranet subscriptions (Corporate license for multiple copies) are available. Submit articles forconsideration to: Communications Standards Review, 757 Greer Road, Palo Alto, CA 94303-3024 USA. Tel: +1-650-856-9018. Fax: +1-650-856-6591. e-mail: [email protected]. Web: http://www.csrstds.com .



COMMUNICATIONS STANDARDS

REVIEW

757 Greer RoadPalo Alto, CA USA 94303-3024

Voice: +1-650-856-9018Fax: [email protected]

http://www.csrstds.com

December 20, 2000

Communications Standards Review Electronic Format Policy

The distribution restrictions on the electronic versions of Communications Standards Review(CSR) are similar to the restrictions on the hard copy versions. Copying of individualarticles/reports for distribution within an organization is permitted. The electronic version may bemounted on a server whose accesss is restricted to a single organization provided that onlyindividual articles/reports are downloaded/accessed, not a complete issue of CSR. However, youare welcome to forward your copy (deleting it on your system) to others in your oganization. Theintent here is that the electronic version of CSR has the same restraints as the hardcopy version butis easier/quicker to distribute within the organization in electronic form. Each issue is identifiedwith a customer-specific identification number.

There is no additional charge for this service. If you wish to receive both hard copy and electroniccopy, the cost is $150.00 additional per subscription.

CSR also offers an Intranet subscription which permits unlimited copies to the subscribingorganization ($2150.00).

Any questions? Please contact us.

Elaine J. Baskin, Ph.D.Publisher